included or not

detecting how a file is called

[lucy24]

Bearing in mind that I know just enough php to hurt myself, but probably not enough to be a danger to others:

I've got a file that is called in two different ways. If it's included within an existing html document

<!--#include virtual="/paintings/critters/critterlinks.php?subdir=mice&page=${DOCUMENT_NAME}" -->

it creates a navigation footer specific to that page. If it's created "cold"

RewriteRule ^paintings/mice/([a-jw]\w+)\.html /paintings/critters/critterlinks.php?subdir=mice&page=$1 [L]

it builds the entire page, including the footer. (It's the same php file because the page-building process uses some of the same data as the footer-building process, and there's not enough information to merit mucking about with a separate database. Yes, it returns a 404 if it turns out to be a bum request. Different thread.)

Right now I filter them like this

$realpage = 0;
$tester = explode(".",$page);
if(!is_null($tester[1]))
 {
 $page = $tester[0];
 $realpage = 1;
 }

Question: Should I instead be looking for a predefined function that checks whether the present file is included within some other file?

[rainborick]

I'm a brute force programmer, so it seems to me that the simplest answer would be to add a query string parameter to the call to critterlinks.php in your RewriteRule to distinguish the origin of the call. But then I try to avoid parsing URLs at all costs.

[lucy24]

Heh. Well, as long as I don't get

#1 Agonized scream of Noooo! You can't do that! followed by list of dire potential consequences

or

#2 "You doofus, what you need is the built-in function {incomprehensible name}* which you could find by searching php dot net for {some word it would never in a million years have occurred to me to look for}"

But then I try to avoid parsing URLs at all costs.

In theory I don't need to look at the URL at all, since any page that uses ${DOCUMENT_NAME} is by definition a hand-rolled html page and I could perfectly well edit the text to say something else. But, hey, what's the point of an include file if you still have to hand-edit the line that does the including? :)


* But then, my brain slows down every time it meets the words "preg_something-or-other" even though I know perfectly well the p is for Perl.

[swa66]

I'd look at php includes instead of going round and about via SSI to create a second hit and have to interpret yet another page.

The php include will have access to the original request parameters, including the URL, pagename etc without anything more.

It's going to be much prettier, simpler and much more straightforward.

[lucy24]

I may have mis-worded the original question. It's only one php file. Depending on context, it's EITHER included within an html file, OR it builds the whole page by itself. If the page contains text, the html is hand-rolled aside from the php footer. If the page is just a picture plus footer, the page is auto-generated in php. Either way, the php is only called once.

The second version-- the auto-generated pages-- is new. The php footer has been around for a while. Well, a few months at least. I added the textless pages so each large jpg would "belong" to an isolated page instead of to a gallery page requiring download of up to a few dozen thumbnails. The original form was image alone, target _blank. So the user experience is a little better but not substantively changed.

[Key_Master]

I'm not sure I fully understand your question, but I'll throw a couple of different options at you. On most servers, you can get the redirected document_name (or any other server variable) by prepending the variable with "REDIRECT_". E.g., REDIRECT_DOCUMENT_NAME. If that's not present, you can try setting (and reading) a unique environmental variable in your PHP script. That would be a little safer and easier to code for than using a query string parameter.

[lucy24]

I'm not sure I fully understand your question

"What is the safest and/or most efficient way to detect whether the present file is acting as a document in its own right, or is included in something else?"

The query string exists in any case. If either of the two parameters has gone missing entirely, the page won't get drawn and the 404 page will be shown instead. This is fine if the php file was supposed to be creating a complete page. But if the php file was only supposed to make the navigation footer, the full content of the 404 page would then be shown in the location allocated to the footer.

Now, I don't know if it's physically possible for a server to locate and include a php file but still misplace its parameters-- but I kinda think I ought to code for the possibility.

[penders]

If the page that is including the PHP file is just a plain vanilla (S)HTML document (and not .php) and you are stuck with including the file using SSI then you can pass a URL parameter (as rainborick suggests) in order to identify how the file is called (whether it is included or not). You seem to be doing something like this already, although it could perhaps be simplified or made more explicit:

<!--#include virtual="/paintings/critters/critterlinks.php?subdir=mice&page=${DOCUMENT_NAME}&inc=1" -->

if (isset($_GET['inc'])) {
/* File is included */
}

However, mixing PHP and SSI is best avoided, and usually unnecessary.

As swa66 suggests, PHP includes are far more preferable here. In which case it is usual to define a constant before you include the file (eg. define('INCLUDED',1)) and then inside the included file you can simply check to see whether this constant has been defined: if (defined('INCLUDED')) {...}

if(!is_null($tester[1]))

This will be throwing an E_NOTICE (probably quietly in the background) when $tester[1] is not set. This is best written as:

if(isset($tester[1]))

[lucy24]

This will be throwing an E_NOTICE (probably quietly in the background)

Ah, you mean the things that pile up in MAMP's "php errors" log and give me momentary heart failure until I look over the list and find they're all labeled "notice" rather than "error". (In some cases for things I'm surprised don't count as bona fide errors, as when I accidentally checked one too many iterations of array values, winding up with a set that hadn't been defined. Whew.)

I thought the point of "is_null" is that it encompasses both "value is zero or empty string" and "is undefined" so I can cover both options in a single condition. Drat.

[penders]

Yeah, PHP can be a bit too lenient at times (certainly compared to other languages). Some "notices" might be as a result of a more serious runtime error. Certainly whilst developing, it is a good idea to enable full error reporting at the top of your script:
error_reporting(E_ALL)

And to even include the strict reporting (of deprecated usage):
error_reporting(E_ALL | E_STRICT)

is_null() specifically checks for the value null, and is equivalent to:
if ($var === null)

isset() returns true if the variable is defined and is not null. No "notice" is generated if the variable is not defined.

empty() returns true if the variable is not defined or is any one of null, false, empty string, 0 (zero), '0' or empty array. No "notice" is generated if the variable is not defined.

[lucy24]

In that case I guess I want "empty()". The function should behave the same regardless of what reason it's got for not having a value. (It already deals with existing but non-matching values, as would be created if the googlebot comes by and asks for /paintings/mice/abcdef.html. It has been known to do this, although so far not in this directory.)

[penders]

Quite possibly, although empty() is essentially the opposite of isset(), so your logic is reversed.

if (isset(...))

/or/

if (!empty(...)) // not empty

(Using a non-negated expression is always preferable.)