Re: [Tiki-devel] Anchors are screwed up

Hi Volker and all

I left this unread until i had time to reply, but now i've lost what the issue was - i think it was a lack of, or incorrect url encoding of non-ascii characters in anchors, but now i'm looking back at the thread i've sort of lost the plot...

I see on https://volker-wysk.de/tiki/Anchors%20in%20Tiki.html your suggestion is to add a new anchor with properly encoded characters in the url (but only if that would be different, i presume).

Can you send a patch or even better a merge request of what you have in mind, then we can help check it and merge it into tiki... the instructions are here: https://dev.tiki.org/Git-Workflow

Thanks, sorry for the slow response :p

jonny





> On 21 Jan 2023, at 16:46, Volker Wysk <[email protected]> wrote:
> 
> Am Freitag, dem 20.01.2023 um 23:05 -0500 schrieb Brendan Ferguson:
>>> 
>>> It's also an issue for European languages other than English, which use
>>> accented letters. It works, most of the time, but you have to botch
>>> links
>>> that use such anchors, by hand. And you get ugly URLs...
>>> 
>>>> Even still I do remember having some minor issues with this when
>>>> working
>>>> with german. In any case this issue is not a deal breaker with many
>>>> installs. Old tiki’s continuing to work the same way, while new tiki’s
>>>> moving forward with a universal solution would be preferable in my
>>>> books.
>>> 
>>>> But I don’t like the idea of dual anchors. When people look at the
>>>> code
>>>> its not going to be obvious what is going on. If I am looking for an
>>>> anchor to use, then will see two and pick one. Better to decide whats
>>>> best
>>>> and move forward with that.
>>> 
>>> You won't be looking a the HTML code, will you? It's unreadable (before
>>> you
>>> send it through htmltidy).
>> 
>> 
>> I do all the time. If I want to see style something on a page, I just pull
>> up the inspector butyl into my browser and zoom right into what the css-
>> html looks like to write the correct css. Or likewise, if I am looking to
>> link to somewhere on the page, just open open up the inspector again to
>> see what there is lying around with something I am use as a anchor (like
>> an anchor or a name) Or often just open the HTML to find a unique sequence
>> I can search for to find the Smarty Template if I need to create custom
>> smarty templates, or modify an existing one.
> 
> Okay, so for someone like you it will be non-obvious. But how many people
> look in the HTML code to find something out, like the name of an anchor?
> When the transition to clean anchor names in the HTML has been made, like
> discussed, then the anchor name will be obvious. For explicit anchors, it
> will be what has been set with the ANAME plugin. For anchors generated from
> headings, the anchor name will be the heading. No looking at the HTML code
> necessary and the new anchor names will be used.
> 
>> You have to remember that code sticks around for a long time sometimes.
>> Its best to make things obvious about what they are doing and why they are
>> there. 
> 
> I'm always in favor of good and complete documentation. (Alas the Tiki code
> I've read until now was almost undocumented.)
> 
>> Leads to less errors down the line when someone modifies something and
>> does not fully realize what it is doing. Although it’s not a deal breaker
>> and I have been both guilty of breaking non-obvious code and also writing
>> it for it only to be broken later :( Unit tests and lots of documentation!
>> Ok, that was a bit of a rant.
> 
> 
> Cheers,
> Volker
> 
>>> 
>>> Cheers,
>>> Volker
>>> 
>>>> 
>>>> Just my 2 cants.
>>>> 
>>>>> 
>>>>> This way, compatibility with old Tiki pages is ensured.
>>>>> 
>>>>> 4. Encode the subsection part of internal Tiki links with the new
>>>>> function,
>>>>> when generating HTML. Old links, which have the manual underscore
>>>>> replacement in it, won't get changed by the new encoding. They will
>>>>> match
>>>>> the old anchors (3.). New links, which don't have an encoding in the
>>>>> subsection part, will match the new anchors (2.).
>>>>> 
>>>>> Doing it this way wouldn't require any transformation of old Tiki
>>>>> pages'
>>>>> source code. 
>>>>> 
>>>>> 
>>>>> So I'm creating a wish now...
>>>>> 
>>>>> Cheers,
>>>>> Volker
>>>>> 
>>>>>>>> On 15 Jan 2023, at 11:18, Volker Wysk <[email protected]>
>>>>>>>> wrote:
>>>>>>> 
>>>>>>> Hi.
>>>>>>> 
>>>>>>> In wikiplugin_aname.php and wikiplugin_alink.php, there's the
>>>>>>> following:
>>>>>>> 
>>>>>>>   // the following replace is necessary to maintain compliance
>>>>>>> with
>>>>>>> XHTML
>>>>>>>   // 1.0 Transitional and the same behavior as tikilib.php. This
>>>>>>> will 
>>>>>>>   // change when the world arrives at XHTML 1.0 Strict.
>>>>>>>   $aname = preg_replace('/[^a-zA-Z0-9]+/', '_', $aname);
>>>>>>> 
>>>>>>> This means, only latin letters and digits are allowed in anchor
>>>>>>> names.
>>>>>>> Everything else is replaced by an underscore when rendering the
>>>>>>> HTML
>>>>>>> page.
>>>>>>> 
>>>>>>> This (sometimes) works, as long as only the AName and ALink
>>>>>>> plugins
>>>>>>> are
>>>>>>> used. But it doesn't, when the subsection part in an internal
>>>>>>> link
>>>>>>> is used -
>>>>>>> ((Page|#Subsection|...)). I've tried it with
>>>>>>> "((Ankertest|#Überschrift-
>>>>>>> Anker))" and got a subsection part of "#%C3%9Cberschrift-Anker"
>>>>>>> in
>>>>>>> the
>>>>>>> generated HTML.
>>>>>>> 
>>>>>>> The subsection part needs to undergo the same treatment as the
>>>>>>> anchor name,
>>>>>>> which the AName plugin does, when this is supposed to work.
>>>>>>> 
>>>>>>> Anchors which are generated from headings are different as well.
>>>>>>> I've tried
>>>>>>> it with a heading called "Überschrift dazwischen", and the
>>>>>>> resulting
>>>>>>> anchor
>>>>>>> name in the HTML page is "berschrift_dazwischen".
>>>>>>> 
>>>>>>> And what about languages that don't use a latin alphabet, such
>>>>>>> as
>>>>>>> many Asian
>>>>>>> languages? The complete anchor names will be replaced by an
>>>>>>> underscore.
>>>>>>> 
>>>>>>> Anchor handling is really screwed up.
>>>>>>> 
>>>>>>> The world has "arrived at XHTML 1.0 Strict" long ago - in 2002,
>>>>>>> it
>>>>>>> says in
>>>>>>> the https://www.w3.org/TR/xhtml1/ page. So it's time that "this
>>>>>>> will
>>>>>>> change".
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Volker
>>>>>>> _______________________________________________
>>>>>>> TikiWiki-devel mailing list
>>>>>>> [email protected]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> TikiWiki-devel mailing list
>>>>>> [email protected]
>>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>> 
>>>>> _______________________________________________
>>>>> TikiWiki-devel mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>> 
>>>> 
>>>> _______________________________________________
>>>> TikiWiki-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>> 
>>> _______________________________________________
>>> TikiWiki-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>> 
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> 
> _______________________________________________
> TikiWiki-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel




_______________________________________________
TikiWiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel