Reliable setting of $s

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

Re: Reliable setting of $s

Post by cmb » Sun Jun 23, 2013 12:35 pm

cmb wrote:But this would require to treat special calls (e.g. sitemap, images, xhpages and the plugins) as "implicit" pages, so no page with the same name (case sensitive) may exist on the same site.
Actually, this is already the case. Just name a page "pagemanager" and request http://example.com/?pagemanager while you are logged in :o; or name a page "print" and request http://example.com/?print :shock: This may not seem an issue, as one can have "Pagemanager" and "Print", and it is customary to capitalize the first character in an (English) heading. But consider transliteration (which is often very reasonable)...

So I am refining my original suggestion in the following.

The core of CMSimple_XH reserves some of these "special" page names, which cannot be used for user created pages; probably that's not too much of a problem (even if we should consider reducing the number; for instance now there are "images", "downloads", "media" and "userfiles" as special pages). But the most unpredictable special pages are introduced by plugins to call their back-end functionality. We should consider to streamline this, by using something like "plugin-admin" as <h1> special page name (so one does not request http://example.com/?pagemanager, but http://example.com/?xh_plugin/pagemanager). If such URLs would be used by plugins, this might even pave the way to a more effecient processing of the plugins (if it is determined which plugin is to be requested, other plugins wouldn't even be have to be loaded for this request).

So, my suggestion: there should be a small, determined and well documented number of special pages, whose heading cannot be used for normal pages. The following set already may suffice: "login", "mailform", "search", "sitemap", "xhcore" and "xhplugin" If an extension introduces special pages, they should be subpages of the plugins admin page (xhplugin:plugin_name:subpage), or the headings of those special pages should be made configurable. In the latter case, the plugin should give a page created by the user priority, ignore its special output and emit a warning instead that there is a clash. Furthermore the core should deny creating pages with the special names listed above.

Obviously this change would be incompatible with existing plugins; to alleviate the burdon of the transition and to stay compatible with existing CMSimple versions, there could be made an API function available, which should cater for the URL building transparently and which can later be replaced. I have already suggested such an API, and latter I'll post a concrete suggestion in this thread.

For CMSimple_XH 1.6 we should stick with the current URL handling, but plugin authors may be encouraged to rewrite their plugins to use the new API.

Christoph
Christoph M. Becker – Plugins for CMSimple_XH

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Reliable setting of $s

Post by cmb » Sun Jun 23, 2013 3:07 pm

I have just posted the draft of the API function; see http://cmsimpleforum.com/viewtopic.php? ... 874#p35874.

I may elaborate a bit more about the actual benefits of changing the URL handling as suggested above. Currently it's not possible for the core to reliably detect what functionality is requested. Only after the processing of all plugins, the core has a clue about that. The suggested change will enable the core to be able to reliably set $s before any plugin is loaded (what's very important; currently several plugins are using some kind of hack to work around this issue). Furthermore the core actually knows in advance, if a plugin back-end is requested, and if so which one, so it won't be necessary anymore to load the admin.php files of other plugins for this very request. Additionally the handling of special functionality of the core can be simplified and streamlined; currently that's a bit ad-hoc. Eventually CMSimple_XH may be able to only load those parts of the PHP code which are actually needed; most of this could be automated by usings PHP's autoloader (requires the switch to PHP 5 and plugins that are written in an OOP style; other plugins can still be used, but these have to be completely loaded as it's now), but for some requests (the back-end of plugins) further information would be necessary.

However, probably the most important advantage: the user is able to give pages nearly any name he wishes (only "login", "mailform", "search", "sitemap", "xhcore" and "xhplugin" will be forbidden for <h1> page headings).
Christoph M. Becker – Plugins for CMSimple_XH

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Reliable setting of $s

Post by cmb » Tue Mar 31, 2015 1:40 pm

Hi everybody!

I want to revive this old thread, because I do not want to claim the misbehavior of $s would be a feature:
das ist nur so, wenn Du eingeloggt bist, dann soll es auch so sein, damit man sich bewusst eine Seite aussucht zum bearbeiten.
However, I still don't have a solution; my former suggestions regarding a link builder API don't appear to be appropriate. Perhaps an OO-API (URLBuilder?) might be more suitable?

Thoughts?
Christoph M. Becker – Plugins for CMSimple_XH

Post Reply