homepage Welcome to WebmasterWorld Guest from 50.17.66.61
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum

    
the case of the vanishing variable
lucy24

WebmasterWorld Senior Member lucy24 us a WebmasterWorld Top Contributor of All Time Top Contributors Of The Month



 
Msg#: 4628689 posted 1:14 am on Dec 8, 2013 (gmt 0)

Looking for insight here. Keep in mind that I only speak three words of php, i.e. just enough to hurt myself.

Background:
-- both .html and .php support SSIs (as distinct from php includes)
-- .html by that name is not parsed as php

Structure: file with .html extension
{html header blahblah}
<body>
<!--#include {ssi blahblah ending in .php?query=something}
more-stuff-here
<!--#include {ssi blahblah ending in .php?query=something}
</body>
</html>

This works as intended. "query=something" happens to be the same both times, but they are wholly independent php files, so no issues here. The two includes come immediately after <body> and immediately before </body>.

But then...
Same configuration, only this time the mother document is php, with a query of its own. (It took me a while to identify php vs. html as the significant variable.) Different parameter names.

With this configuration, the final include still works as intended but the first one doesn't. That is: the content is included, but the query is not recognized.*

Now, I would understand this if neither include worked as intended in a php file. But I can't for the life of me figure out what happens between <body> and </body> that allows the included file to read its own query at the end but not at the beginning.

The plot thickens:
Everything works as intended if I attach the parameter to the mother file. So instead of
something.php?this=that
{include} something-else.php?other=tother

it's
something.php?this=that&other=tother
{include} something-else.php


If it's written as an SSI, the code doesn't care whether the first included file-- the one at the top of the <body> -- comes with its own query (other=some-value-here) or not. Either way, the value from the mother document is used. (I tested by setting a different value. Normally they would be the same.) But the second include file-- the one at the end of the body --has to have a query.

If either one is configured as a php include, I can't give a parameter, or the content won't be included at all. But both variables are read from the mother document.

What's happening here?


* I've got a fallback that says if the variable in question is empty for any reason, set its value to "xyz". A quick test with "echo" confirms that this is the line that executes.

 

mack

WebmasterWorld Administrator mack us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4628689 posted 4:43 am on Dec 8, 2013 (gmt 0)

Sometimes these problems bug the life out of me, then the next day with a fresh head the problem stands out like a sore thumb and is fixed in seconds :-)

I notice you are including the file with the query string. This is not something that should be done, now and again I have done it and got away with it, what you could do (as a debug attempt) is set the variable and then do the include...

$something = "this";
Include "file.php";

Then within file.php use the value of $something.

My understanding is that a variable can't be sent via an include, but it can access included that had already been set in any previous code. You may find that your first include is failing for this reason, yet the 2nd include is getting a value because by trying to send the variable, you have set it for further use within the script.

Mack.

lucy24

WebmasterWorld Senior Member lucy24 us a WebmasterWorld Top Contributor of All Time Top Contributors Of The Month



 
Msg#: 4628689 posted 10:48 pm on Dec 8, 2013 (gmt 0)

$something = "this";
Include "file.php";

Yup, I remember being advised to do that in a slightly different situation: when the include comes inside a function.

The adventure continues...
I got the Panda Page to behave itself by converting all the SSIs into php includes, even though this means stepping into php in the middle of long stretches of html. (On my setup, this in turn means that errors won't be logged: SSI errors show up in the error log but php errors don't. This naturally makes me uneasy.)

So now the gremlins have moved to a different subdirectory, where they are amusing themselves by jumping straight from Chapter 1 to Chapter 8 of Alonzo and Melissa. That is: the counter itself, which is supposed to increment from 1 up to 22, simply skips nos. 2 through 7. There is nothing inside the loop that could possibly affect the value of $count; I even checked for any occurences of the string "count" in the included pure html! I strongly suspect there is some significance to the number 8, but it isn't anything blatant like a leading zero. Grr.

JD_Toims

WebmasterWorld Senior Member Top Contributors Of The Month



 
Msg#: 4628689 posted 7:29 am on Dec 9, 2013 (gmt 0)

Well, since I have a collection of PHP "been there, done that" cards I'd be happy to give you a hand, but I need to see more of the code to even have a guess where the issue is -- If you haven't got it going by the time you make it back by here, feel free to dump some code and I'll try to remember to take a look at it.

penders

WebmasterWorld Senior Member penders us a WebmasterWorld Top Contributor of All Time 5+ Year Member Top Contributors Of The Month



 
Msg#: 4628689 posted 12:20 pm on Dec 9, 2013 (gmt 0)

Same configuration, only this time the mother document is php


In this case, are you using PHP includes, or still using SSI? file or virtual?


I notice you are including the file with the query string. This is not something that should be done, now and again I have done it and got away with it...


Yes, you can't (normally) do this with PHP. However, it should be OK with SSI. SSI includes issue an additional HTTP GET request, so query string parameters are passed and processed. PHP includes take a file system path, not a URL (normally). In fact, the query string in this case will just make for an invalid filename and the file won't be found (E_WARNING). (The exception to this is if you have URL include wrappers enabled and you include an absolute URL - but this is quite different.)


-- both .html and .php support SSIs (as distinct from php includes)


Trying to combine PHP and SSI includes can be problematic. I can certainly say I have had problems in the past trying to parse PHP files for SSI includes, which basically ended up being an illogical mess. I think there is a bit of a chicken/egg scenario. Unless you are trying to shoehorn PHP into an existing SSI system, then there is never a need to use SSI when you have PHP.

lucy24

WebmasterWorld Senior Member lucy24 us a WebmasterWorld Top Contributor of All Time Top Contributors Of The Month



 
Msg#: 4628689 posted 5:07 am on Dec 19, 2013 (gmt 0)

Postscript:

In the final chapter, the Panda Page behaved as intended on MAMP but not on the live site. It couldn't have anything to do with php version or similar arcana, because Alonzo and Melissa-- a more complex set of files-- behaved properly in both places. Or at least they did, after I figured out that I can't keep recycling $pagename[blahblah] as the name of all variables everywhere, including two different globals. Oops. Very picturesque navigation footer at one point.

Drove me bonkers. I fine-tooth-combed both files. No difference; in fact they couldn't be different, since they had identical timestamps. Finally it occurred to me to look at the respective htaccess files, where the html-to-php rewrite takes place.

Local file: ?animal=robot&page=panda
Live file: ?animal=robot ... and that's all.

###.

Just thought I'd share.

penders

WebmasterWorld Senior Member penders us a WebmasterWorld Top Contributor of All Time 5+ Year Member Top Contributors Of The Month



 
Msg#: 4628689 posted 8:08 am on Dec 19, 2013 (gmt 0)

the Panda Page behaved as intended on MAMP but not on the live site. It couldn't have anything to do with php version or similar arcana, because Alonzo and Melissa-- a more complex set of files-- behaved properly in both places.


But they are different files(?), so I would have thought PHP version could still have been a possibility?

Did you have errors/warnings on the live site? A difference in the error_reporting level between servers could also have been a factor in this case. Or did it just simply not "behave as intended"?

lucy24

WebmasterWorld Senior Member lucy24 us a WebmasterWorld Top Contributor of All Time Top Contributors Of The Month



 
Msg#: 4628689 posted 9:06 am on Dec 19, 2013 (gmt 0)

On my live site I don't have access to php errors. I can check in MAMP but never got around to it.

The live site and MAMP may use marginally different php versions-- but they'd certainly use the same version throughout, rather than different versions for different files in the same directory!

"Behave as intended" = the included file reads the value of a variable, leading to visible display. (In this particular case, it's concerned with suppressing the link for the menu item that corresponds to your current page, because it drives me ### when pages link to themselves.) So if a particular menu item is visibly linked when it shouldn't be, it means that the php can't see the variable. This is the part that I eventually fixed by shifting all parameters to the outer file.

And then A&M got creative because a completely different part of a different menu started going haywire, not just highlighting the wrong things but displaying the wrong text. That's the one that turned out to be an idiot-level mistake involving using the same variable name for two different globals. (I also call all counters $count unless the computer starts spitting smoke and forces me to make up a second name.)

:: detour to MAMP logs, which I've been systematically forgetting to look at for, hm, going on for two weeks now ::

Sample:
[06-Dec-2013 08:57:19 Europe/Berlin] PHP Warning: include(): Failed opening '/Users/myname/Documents/www_example/directories/fun/funbanner.php?page=panda' for inclusion (include_path='.:/Applications/MAMP/bin/php/php5.4.10/lib/php') in /Users/myname/Documents/www_example/directories/fun/panda.php on line 123
...
[06-Dec-2013 08:57:59 Europe/Berlin] PHP Notice: Undefined variable: thispage in /Users/myname/Documents/www_example/directories/fun/funbanner.php on line 20
...
[07-Dec-2013 06:45:41 Europe/Berlin] PHP Fatal error: Cannot redeclare linkbanner() in /Users/myname/Documents/www_example/directories/fun/funbanner.php on line 16

Uh-oh, that sounds like something I would have benefited from looking at 11 days ago. And here's another good one:

[07-Dec-2013 06:51:35 Europe/Berlin] PHP Notice: Array to string conversion in /Users/myname/Documents/www_example/directories/fun/AlonzoMelissa/amlinks.php on line 91

I think that's where the recycled name came in. Both were arrays, but they're different shapes with different content.

I don't actually know what all those words in the error messages mean, but I can see where I should have been able to extract information from them. Overall, at least 90% of the php errors are "Undefined index" which, as I understand it, doesn't necessarily mean anything in particular. Here I think it's because I have an "if empty" condition and obviously the only way to find out if something is empty is to ask, which then yields a low-grade error.

Other than "undefined index", MAMP doesn't show any php errors later than the 10th, which is when I got Alonzo & Melissa* sorted out.

On the plus side, I've just learned that if I twiddle the config file I can run multiple sites on free MAMP without having to cough up for Pro. Tralala.

And no, I don't know why MAMP thinks I live in Berlin. Maybe it's where MAMP came from.


* Gloriously cheesy novel, published serially in 1804, pirated in 1811 and republished zillions of times over the next 60-plus years until dislodged in cheesiness by East Lynne. Did I explain that already?

penders

WebmasterWorld Senior Member penders us a WebmasterWorld Top Contributor of All Time 5+ Year Member Top Contributors Of The Month



 
Msg#: 4628689 posted 1:23 pm on Dec 19, 2013 (gmt 0)

PHP Fatal error: Cannot redeclare linkbanner()...


As you would expect, and probably experienced, this would have terminated your script. If this occurred later in your script then you might have seen some output (or even a reasonably complete page). However, if it occurred early in your code then you might have seen just a blank page!

PHP Notice: Array to string conversion


If you try to use an array where a string is expected. For example, trying to echo/print an array directly to the page. You'll end up with the literal string "Array" being output, or used in your expression (and an E_NOTICE is triggered).

"Undefined index" which, as I understand it, doesn't necessarily mean anything in particular.


The same as when you use an undefined variable. This could, however, be a very real error if you were expecting this variable (or array element) to have a value (it could be a typo in your code). It also has security implications... if a malicious script was able to initialise these variables to something unexpected then who knows what might happen! (This is very easy to do if register_globals is enabled - which is one reason why this is/was such a bad idea.)

Note that an undefined variable (or index in an array) is likely to be implicitly converted to an empty string (in a string context). However, conversion to a numeric value is undefined and should not be relied on.

Here I think it's because I have an "if empty" condition and obviously the only way to find out if something is empty is to ask, which then yields a low-grade error.


Actually, no. Using PHP's empty() function on an undefined variable (or undefined index) does not trigger this low-grade error (E_NOTICE).

I don't know why MAMP thinks I live in Berlin. Maybe it's where MAMP came from.


Maybe, although any server distribution shouldn't default the timezone out of the box - without first asking? The expected default is 'UTC'. (Although PHP will trigger an E_WARNING level error if this is not explicitly set before using any date/time functions.)

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved