Re: [Tiki-devel] Anchors are screwed up
Volker Wysk <post-hhF2Jplw28UoZk/[email protected]>
| Newsgroups | gmane.comp.cms.tiki.devel |
|---|---|
| Message-ID | <[email protected]> |
Am Sonntag, dem 15.01.2023 um 14:37 +0000 schrieb Jonny Bradley via TikiWiki-devel: > Hi Volker > > That sounds possible, odd that no one's noticed before - i suggest you > create a wish on https://dev.tiki.org/Make-a-wish and maybe a junior dev > can be found to look at it :) > > Meanwhile i guess you have to do the underscore replacement yourself... The underscore replacement is the problem. It allows only ASCII alphanumeric characters. For Asian or other languages, which don't use latin letters, the anchors generated from headings are the empty string! See here for more details: https://volker-wysk.de/tiki/Anchors%20in%20Tiki.html I've got a plan of how the situation could be resolved. Only limited effort is required. 1. Write a function which does a proper "URL-fragment string" encoding. (That's a term from the URL standard.) 2. For ANAME/ALINK plugins and for anchors generated from headings, encode the anchor name with this function, in the generated HTML. All characters are allowed and get encoded. 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. 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 <post-hhF2Jplw28UoZk/[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
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6QXGh82Ov3+2nrxp+K4ydFOsHoUFAmPGlugACgkQ+K4ydFOs HoWP5A//YS989Kq+RYAbFG9D66gDKX2Nn7zHqupW79J0Jwr9Xlc/SzE+Vq88LdXg nQKWw05gj0IRFz3zn4eMdrxZ2bCF/WxApvBlCdWQsyMujjdTKQlsc1n18S9HpctS CLI+vNJA/HBr8d8ZRzidPw7kxd4DpcCtApGBafAJvSodtqrl6/jnERW+H3u3Sp+4 HjSfKpazqNXe5LDJk3wPPJcY81pG9+jU5RCW+cYUghlM88lvCcyMs8153dMf6Cq+ JoN0VivREh6Ph1SplwpR/0ZkU8/lVpCRgfJRmO7ra9HCltk6vipx/Khc0xyq4YKg s8tp+Y/uZSJ0Fu0ylk8UeKObeZupWWg2homHtqSabxZxRp+JbUXRqGsxJl7dDios Zh4AJBIeE5/vuDdtiX2GLR28+6TdPXgsSXsbvIzy3iR0ZF3LWRyB1md7FHpBlpAz Pg03r9SoedlJOWYZ2Q9Rk6xgP2GjUqhGApNEsHPtUePvR4Nup2PijwlzUkf5GLq8 EdWGShHMSiyU+4xxnQcBickvbtfZNLQ1CpIwYkSSWU/t+8jUBOKOa5BOomAuG3Xj 8zctjBpPOHJcArIuXZqJ9CcFXP96JN7Bsyjy4j8YXkH85U68VjTx2O4OHYeH8hvh YtCCXNjvDVydMiW5VmYZ6UbbG1wLa6JCSARZEUyt5t318eCNx+U= =Ryde -----END PGP SIGNATURE-----