Improve CMSimple_XH's routing

Discussions and requests related to new CMSimple features, plugins, templates etc. and how to develop.
Please don't ask for support at this forums!
Post Reply
cmb
Posts: 12776
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Improve CMSimple_XH's routing

Post by cmb » Sat Sep 30, 2017 10:12 pm

Hi everybody!

A rough summary on CMSimple_XH's present routing mechanism:
  1. Check if the first parameter of the query string, if only given as name without equals sign and value, (let's call that page URL) points to a user defined page; if so, set $s to the respective page index, otherwise set $s to -1.
  2. Load the plugins, which may or may not produce output (i.e. write to $o) on arbitrary query strings.
  3. If $s == -1 && $o == '', adjust $s to point to the first published page (let's call it start page).
This causes the infamous $s issue, namely that $s is not reliable during plugin loading, and that any output written if no known page is given, causes the content of the start page to be suppressed. Item (2) is furthermore responsible for potential name clashes; for instance, if a user creates a page with a name of one of the installed plugins, in the back-end the page editor and the plugin administration are both displayed. Therefore such page names (e.g. "pagemanager") should be avoided.

In my opinion, this routing mechanism is one of the biggest issues of CMSimple_XH, because the resulting problems are so subtle. I guess that most plugins don't have any issues in this regard, and that most users never had encountered any such name clashes. However, some have, and that is unfortunate.

Actually, it seems to me that this routing mechanism is putting the cart before the horse, and it would be much cleaner to register plugin defined (aka. "implicit") pages upfront, so that the core could reliably detect the requested page before actually running plugin code: if a page URL is given it is checked to match either a user or a plugin defined page (and triggers a 404 if not); otherwise the request refers to the start page. Period.

Of course, we can't simply change the routing behavior due to the BC break; even if we would do this for CMSimple_XH 2.0.0 (what is allowed according to SemVer), it is quite likely that lots of plugins would not be ready for this version even months after its release (considering the situation with CMSimple_XH 1.7.0). Thus, a migration path for plugins seems to be in order. Firstly, CMSimple_XH would have to offer some way to register plugin defined pages before the actual plugin initialization is run (may be introduced in CMSimple_XH 1.8.0). Secondly, if an unknown page is requested, but $o != '' after plugin loading a deprecation notice should be triggered (may be done as of CMSimple_XH 1.9.0).

The alert reader may have noticed that this would still leave some isses, because not only plugins but also the core exhibits special behavior for some requests, for instance, sitemap and mailform, and the complete plugin administration. This would have to be fixed as well by turning all these special requests into using implicit pages (which would require to register them upfront, but would leave the option to internationalize these requests; consider ?mailform vs. ?Kontaktformular).

Thoughts?
Christoph M. Becker –Plugins for CMSimple_XH, but not for CMSimple 4+

Post Reply