Re: [Tiki-devel] Anchors are screwed up

"Dr. Sassafras" <[email protected]>
Newsgroups gmane.comp.cms.tiki.devel
Message-ID <[email protected]>
> 
> 3. Use the old method, which throws away non-ASCII characters, as well. This
> means that *two* anchors are generated for each occurrence of an anchor in
> the Tiki page.

Instead, perhaps a preference be made to “enable compatibility with pre-tiki 25 anchors” which is disabled by default for new installs and enabled by default for upgrades. Then we move forward with clean anchors into the future and have a preference that can keep compatibility with a bit of a hack moving forward.

Or perhaps just have an option for which one will be used, with the new version enabled by default and upgrades keeping the same style. Seems like this is just an issue for non-latin languages, so many tiki’s may work fine the old way. 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.

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.