Reliable setting of $s

[cmb]

Hello Community,

I've just had a problem with $s regarding the start page of the CMSimple installation, if this is called without the page name, e.g. http://www.example.com/. In this case $s == -1 while the plugins are loaded, and will be set only after this step in adm.php. IMO that's too late. Any plugin should have access to a reliable $s even in the loading stage (i.e. in the global scope of index.php and admin.php).

A simple workaround that shouldn't interfere with existing plugins, addons or customizations would be to treat an emtpy query string as calling the start page, if $selected is not set. That would require only some additional lines in rfc(), but it won't handle all cases.

A clean solution is probably not possible without causing many existing plugins and perhaps some websites to break. But IMO it's necessary in the long run to fix this issue.

One solution might be, to declare the first query parameter as name of the page, that should be called (as it's now). If the first parameter is empty, then the start page is meant (i.e. $s == 0). 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. Some examples of the resulting URLs (please note the "?" vs. "?&"):
http://www.example.com/
http://www.example.com/?sitemap
http://www.example.com/?&print
http://www.example.com/?downloads
http://www.example.com/?&download=file.pdf
http://www.example.com/?&logout
http://www.example.com/?pagemanager&adm ... lugin_text

Any comments, ideas, suggestions and questions are welcome.

Christoph

[svasti]

I've just had a problem with $s regarding the start page of the CMSimple installation, if this is called without the page name, e.g. http://www.example.com/. In this case $s == -1

Really? Please go to CMSimple-xh.com -- there is a small change -- and, do you see the flags for other languages?

The text before the flgs used to be "select other languages". I changed it to: "Links to CMSimple_XH sites in other languages:". It shows only when $s==0.
Seems to work.

svasti

[cmb]

Really?

Not quite, but the following is correct:

I've just had a problem with $s regarding the start page of the CMSimple installation, if this is called without the page name, e.g. http://www.example.com/. In this case $s == -1 while the plugins are loaded

The important point: $s == -1 during loading of the plugins. It's fixed afterwards, so it's fine to rely on a correctly set $s in the template. But it doesn't work for plugins and in userfuncs.php. Proof: add the following userfuncs.php:

Code: Select all

<?php

var_dump($s); 

I changed it to: "Links to CMSimple_XH sites in other languages:". It shows only when $s==0.

That's probably a good idea as the flags on every single page are misleading (cf. http://cmsimpleforum.com/viewtopic.php? ... 282#p30282).

[svasti]

$s == -1 during loading of the plugins

var_dump confirms it

[cmb]

var_dump confirms it

And it's not only a theoretical problem. The Templateswitch_XH has the same problem (see http://cmsimpleforum.com/viewtopic.php? ... 38&p=29468, which contains some additional explanation what's happening in adm.php to fix $s). Yesterday I had the problem with the cart preview of the Wellrad shop (doesn't show up, when the domain is called directly). And basically the problem exists for every plugin, that (temporarily) alters the content of the current page ($c[$s]) or the output ($o) directly when the plugin is loaded.

It's hard to fix this in the plugin reliably (checking for an empty query string doesn't cater for all possibilities). The only way for plugins to circumvent potential problems is to avoid such automatic content manipulation, and require the user to manually put in a call from the content or template to a plugin function. But this isn't the most convenient solution for users, and it isn't an option in some cases (e.g. Templateswitch would require the user to modify all the templates).

[Gert]

And it's not only a theoretical problem. The Templateswitch_XH has the same problem

TemplateSwitch_XH works fine, even if the blank domain is called:

http://www.ge-webdesign.de/plugindemo/

Gert

[cmb]

Hi Gert,

just set show_always_selectbox=='true', activate the mailform and send a mail. Below the information that the mail was successfully sent, you'll see the content of the start page.

Christoph

[Gert]

Below the information that the mail was successfully sent, you'll see the content of the start page.

I have activated the mailform now: http://www.ge-webdesign.de/plugindemo/

Please test it (send me a mail),

Gert

PS: TemplateSwitch_XH 2.1 is available since 2012-08-10

[cmb]

Hi Gert,

I've just tested it, and it works fine with the new version (2.1) But IMO a workaround in any plugin isn't the best solution. One one hand it's more than hard to fix all cases (e.g. a plugin on the start page that has some kind of "pagination"); on the other that might cause all kinds of interference between plugins.

For example: I've installed CMSimpleRealblog 2.1, and put the WebLog page as first page. Then I've installed Templateswitch_XH 2.1. When I call the start page without any parameter, everything is fine. But when I click on "read more", the article isn't shown. It works fine, though, if I call ?WebLog in the first place.

So I still suggest that we find some solution to set $s correctly before the plugins are loaded.

Additionally I found another minor issue: on http://www.ge-webdesign.de/plugindemo/?_Registrieren the template selectbox is displayed below the registration form. I assume it would be the other way round, when the plugins were loaded in reverse order.

Christoph

[cmb]

AISB it's probably not possible to set $s reliably without breaking existing plugins. So I suggest for XH 1.6 we settle on a convention, how the URLs should be constructed, so that it would be possible to reliably set $s before the plugins are loaded, but don't actually change the handling as it's now. In a later version we can then change the detection of the currently selected page. This would give plugin authors hopefully sufficient time to adapt their plugins.

For this convention, we have to consider POST requests too, which might use $selected. And we might think about simplifying/unifying different ways to trigger some special behavior: $su, $selected, $function, $action.