Actually, this is already the case. Just name a page "pagemanager" and request http://example.com/?pagemanager while you are logged in ; or name a page "print" and request http://example.com/?print 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)...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.
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