My small web app has intermittent blank page issues

[underg12]

Hi all,

The url for the tiny web app I have hosted for free is http://thestoryofmh370.x10host.com

If a visitor is a registered user, the visitor can log in and modify the site contents. The login script is very basic:

<form action="<?php print HTTP . 'includes/login_post.php'; ?>" method="POST">

<ul>

<li>

<label for="username">Username</label>
<input type="text" name="username" id="username" autocomplete="off" value="" />
<?php

if(Session::exists('username')){

echo '<p class="error">' . Session::flash('username') . '</p>';​

}​

?>​

</li>
<li>

<label for="password">Password</label>
<input type="password" name="password" id="password" autocomplete="off" value="" />
<?php

if(Session::exists('password')){

echo '<p class="error">' . Session::flash('password') . '</p>';​

}​

?>​

</li>​

</ul>​

<ul>

<li id="desc_inline">

<input type="checkbox" name="remember" id="remember" />
<p class="remember">Remember me</p>
<input type="hidden" name="token" value="<?php echo Token::generate(); ?>" />
<input type="submit" value="Log In" />​

</li>​

</ul>​

</form>

So it is pretty clear that the form will be processed at the file "login_post.php". This file, in turn, will validate the text inputs. If the login is successful, the browser is redirected to the index.php page without trouble. If login is unsuccessful, the browser is still redirected to the index.php page except that error messages are displayed near the text input fields ("Incorrect username/password", "Username cannot be blank", etc.).

For the first few days after I started operating the app, I was able to login/logout and make modifications (it's a dynamic site with MySQL databases) as needed.
This was a period perhaps between 13 October 2015 to 27 October 2015, which is just over 2 weeks.

Right around after that period, I suddenly encountered a blank page every time I logged in. The "login_post.php" wasn't redirecting me back to the index.php page anymore. I have complete control over the app, so I can use multiple registered usernames on it. All the usernames were not logging in, or even at least redirecting to the index.php page to reflect any login errors.

It was working before without any problems and then it wasn't.

Just this afternoon, I looked at the advice in x10hosting's Help Center, where one of the "Popular Questions" is tagged "My website is showing a blank page." The advice given was pretty sensible, which is to change the "display_errors" directive in the PHP Settings to "on" and to change the "error_reporting" directive to the appropriate "E_ALL" or "~E_"-whatever setting is appropriate. I do the same thing on my own local test server so I have a sufficient understanding of how it works. Doing so would logically display on my browser whatever PHP error may have been thrown during the POST request and response of the form processing.

What actually happened when I tested logging in after changing the PHP settings was somewhat of a surprise. Everything suddenly worked the way it was supposed to, without any PHP errors being displayed. I can login again, I can login with intentional errors to test the form error reporting, and I can again make changes to the app contents.

I'm pretty sure that changing the PHP settings wasn't significant. I have the same files in my development server, and reproducing those steps won't do squat.

Can anyone helpfully explain to me what may have happened? And now that I can use the app normally, would it mean that I may experience the white pages again?

By the way, I've restored the PHP settings to their defaults, since my web app is so simple and tiny that I wouldn't really need to alter any existing PHP directives.

Any help would be greatly appreciated. Thank you and I hope to hear from any gracious member.

 

[essellar]

(This assumes your Session::xxxx props/methods are properly static.)

Believe it or not, it can be magic. You'd think that the error reporting state (or turning on a debugger, or what have you) would be a no-op, but it does change the environment. And changing the environment even in the most subtle way can fix - or cause - Heisenbugs. That can be especially frustrating when you don't control the environment, like when you're running a high-level interpreted language on a stack and hardware you have to treat as a black box that ought to just work; you don't have the opportunity to examine what's happening at a low level.

And then, it may just be coincidence. Again, since you don't control the environment, and you share that environment with half of humanity, you don't know what else was going on at the time, or whether or not the change you made in testing just happened to coincide closely enough with another, bigger change on the system for you to see a cause and effect.

Certainty is good, but psychologically speaking, it's not a good idea for a programmer to get too attached to it. If you're ever doing real life-or-death stuff, you'll have the whole stack - hardware, software and firmware - under your control, and nobody's allowed to change anything, ever, without your OK. Other than that, you can only make sure that you write as few bugs as possible, and that you've anticipated the things that users are most likely to do (accidentally or deliberately). (NB: Foolproof is impossible; the best you can defend against is sufficiently malicious, sufficiently drunk, or insufficiently caffeinated.) At some point you have to draw a box around what you can't control and just expect that it will work - and if it doesn't, and the fault is consistent, then maybe someone can do something about that. If it's intermittent and out of your control, especially in a shared environment, medications are often the best answer.

 

[underg12]

I commend you for your eloquent and adroit response. I was leaning towards a suspicion that mod_security may have had a significant hand in interfering with the re-direction. But I also agree with you that several components are definitely beyond my control, and that making the occasional tweak will eventually be necessary down the road. Thank you for alerting me to the notion of Heisenbugs. I'm pretty sure I'll be encountering more of them as I continue tinkering further with other projects.