Re: [Tiki-devel] Anchors are screwed up

Volker Wysk <post-hhF2Jplw28UoZk/[email protected]> Tue, 21 Feb 2023 13:55:31 +0100
Newsgroups	gmane.comp.cms.tiki.devel
Message-ID	<[email protected]>
Am Dienstag, dem 21.02.2023 um 11:31 +0000 schrieb Jonny Bradley via
TikiWiki-devel:
> 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...

It was about how anchor names are transformed for including them in the HTML
page. This affects the ANAME/ALINK plugins, the anchors generated from
headings, {maketoc} (and autotoc?) and internal links with a subsection
(=anchor) part.

At present, anchors are "mutilated" by replacing non ascii letters and
digits with underscores. One problem is, that this is done differently for
automatically generated anchors from headings and for explicit anchors
(generated by {ANAME}).

Especially for languages with no latin alphabet, it doesn't work at all.

> 
> 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).

And in the HTML code generated from headings and from explicit anchors.

> 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

Hmm... I can try.


Cheers, Volker

> 
> Thanks, sorry for the slow response :p
> 
> jonny
> 
> 
> 
> 
> 
> > On 21 Jan 2023, at 16:46, Volker Wysk <post-hhF2Jplw28UoZk/[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

_______________________________________________
TikiWiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
signature.asc (application/pgp-signature, 833 B)