$sanitizer->pagePathName() inconsistent with $sanitizer->pageName()

[Toutouwai]

Short description of the issue

The description in the documentation for $sanitizer->pagePathName() is minimal:

Returned path is not guaranteed to be valid or match a page, just sanitized.

This could do with fleshing out a bit about what kind of sanitization is done, but the documentation for $sanitizer->path() gives some more information that is relevant.

Path is validated per ProcessWire "name" convention of ascii only [-_./a-z0-9] As a result, this function is primarily useful for validating ProcessWire paths, and won't always work with paths outside ProcessWire.

This method validates only and does not sanitize. See $sanitizer->pagePathName() for a similar method that does sanitiation.

(Sidenote: typo above in "sanitiation")

I understand this to mean that $sanitizer->pagePathName() should sanitize path segments according to PW's page name convention. But it doesn't...

Setup/Environment

• ProcessWire version: 3.0.153

[adrianbj]

I went through this again the other day until I looked at one of my modules that deals with this and discovered that the key is to use this:

Note that I've added ... to your example string which is connected to my issue posted the other day:
#1305

So this is also a problem, because using the Sanitizer::translate option actually does remove the ... so it's not even matching the behavior of the core when creating a page name from a title.

Maybe this doesn't seem like a big deal, but the other day I was importing content from an old site and I need to match page names (in PW) to the data from the old site - it's these sorts of situations where having consistency becomes so important.

[ryancramerdesign]

@Toutouwai Thanks, I've refactored this method so that it is consistent with the pageName() sanitizer. Please let me know if you spot any other inconsistencies.

[matjazpotocnik]

@Toutouwai I've tested, and it looks like it works now. Can you double-check and close?