XH 1.6: $sn

[cmb]

Hello Community,

I've always thought $sn is an abbreviation of "site name", but yesterday I found out for what it really stands for: "script name"

In CMSimple 2 this is defined as:

Code: Select all

if(strpos(sv('SERVER_SOFTWARE'),"IIS"))$sn=preg_replace('/([^\?]*)\?.*/','\1',sv('SCRIPT_NAME'));else $sn=preg_replace('/([^\?]*)\?.*/','\1',sv('REQUEST_URI')); 

(this was only slightly modified in future versions and variants).

This looks quite complicated, and I guess, it's is an historical "accident". I assume in the first versions of CMSimple (unfortunately I can't confirm that, as the oldest version that's still available for download is CMSimple 2) it was:

Code: Select all

$sn=preg_replace('/([^\?]*)\?.*/','\1',sv('REQUEST_URI')); 

This assignment strips off the query string from REQUEST_URI and assigns the rest to $sn. But this doesn't work on (older?) IIS, as REQUEST_URI is not defined there, so it was extended to the solution given above.

But actually the following had been sufficient as SCRIPT_NAME is part of the CGI specification, and so is available everywhere:

Code: Select all

$sn=sv('SCRIPT_NAME'); 

This has a slightly different result for non IIS webservers: normally "index.php" isn't included in the request, so instead of "/index.php" it assigns "/". And exactly the latter is, what is really wanted: the absolute URL of the folder which contains the requested index.php.

So I suggest to change this for CMSimple_XH 1.6 to:

Code: Select all

$sn = preg_replace('/index\.php$/', '', $_SERVER['SCRIPT_NAME']); 

That's simple to understand, and has the particular benefit, that the result is independ on how the index.php was requested.

Christoph

[cmb]

After yesterday's support request I'm not sure, if always using SCRIPT_NAME is the best.

[cmb]

Well, I have been thinking quite much about this (and related) issues. Now it seems to me that using REQUEST_URI where it is available is a good thing. There have been several support requests during the last months, where the use of SCRIPT_NAME prohibited the admin login. Making any changes to $sn without gaining more knowledge about all the gory details first may bring up similar issues.

So I strongly suggest to stick with the current definition of $sn for now. After all, it seems to work "everywhere".

[cmb]

I just learned that REQUEST_URI is now also available on IIS (at least since 7.5). We might consider to change the definition of $sn:

Code: Select all

$sn = preg_replace('/([^\?]*)\?.*/', '\1', sv((isset($_SERVER['REQUEST_URI']) ? 'REQUEST_URI' : 'SCRIPT_NAME)));

[cmb]

Related to $sn is the global variable $iis, which is somewhat related to $cgi. It is totally unclear to me, whether these variables are still needed nowadays. They are used to send HTTP resp. CGI response code headers in function shead().

Formerly, the PHP header() manual had an example with a similar dispatch, but that has been simplified quite a while ago. Can anybody make sense of this commit?

[cmb]

Formerly, the PHP header() manual had an example with a similar dispatch, but that has been simplified quite a while ago. Can anybody make sense of this commit?

Ah, just had a closer look at the mentioned commit. It is about the ini setting cgi.rfc2616_headers. It occurs to me that we should cater to that setting. As its changebility is PHP_INI_ALL, we have full control – we just have to make sure that we don't misuse that. Comprehensive testing under different environments seems to be in order. If we succeed we can get rid of $cgi (it's only used in shead()), what would be great (did I mention, that I consider global variables a bad idea?)

[svasti]

$sn is an abbreviation of "site name", but yesterday I found out for what it really stands for: "script name"

I guess the naming is historical. An in the process of naming also mistakes happen like $cf['uri']['seperator'], we are now stuck with. To continue calling $sn script name makes no sense my view. Nobody who doesn't dive deep into the CMSimple history will understand this.

Therefore I propose to accept it as "site name"
and change in the code all
* @global string The script name.
to
* @global string The site name.

[cmb]

To continue calling $sn script name makes no sense my view. Nobody who doesn't dive deep into the CMSimple history will understand this.

This is not so much an issue of CMSimple history, but rather of the CGI specification. SCRIPT_NAME is well defined, and even though in practice mostly REQUEST_URI is used, the result is basically the same (only on some kind of multi-domain webspaces there seem to be relevant differences). Furthermore CMSimple_XH has the function sitename() which is something completely different.

Finally, rather than slightly improving the documentation, I would prefer to get rid of this global variable altogether. Did I mention, that I consider global variables a bad idea?