NineChime forum

Okay, so this is a caching issue of some sort, most probably with PHP bytecode caching.  What's happening now makes sense.  As to WHY it's happening, I don't have a clue.

Now, bear in mind that I'm using a Windows machine as my test platform, and I'm using PHP directly through the executable.  Every time I run a PHP script, it runs php.exe from scratch.  No accelerators, no Apache modules, no FastCGI, no background processes.  I've never touched FastCGI and have no idea how to set it up, and I only know that PHP-FPM has been included in the PHP core, but I don't know what it does.  So, most of what follows is just guesswork...

From what I gather, PHP generally has two "helpers".  The first is FastCGI or PHP-FPM, which runs as a separate process and prepares the CGI input for the server.  The second is an accelerator of some sort, which checks to see if the PHP scripts have changed recently and thus need to be recompiled to bytecode.  I've heard that there's a number of accelerators available for PHP, and they have to be installed as a PHP module or a Zend extension.  Whether the accelerator is configured in php.ini or whether it has its own config file... I have no idea.

My web host uses eAccelerator.  Once they had a configuration problem with it, which was returning some weird errors in the server log (not the PHP error log).  I helped them track down which config settings were causing the issue, but how my host implemented those changes is beyond me.  The key is that since the errors were in the server log, most likely it was on the FastCGI/Apache end, not PHP.

From what I can tell, since the oekaki config file is a PHP script, the problem here is that your PHP accelerator is misconfigured, and is always using old, cached versions of the config.php file.  When you "restart" PHP, it flushes the cache.  What you need to do is look for a config setting that controls how caching/acceleration is controlled.  On my system, I configured Apache to use php.exe as a handler for PHP files, and the executable is run in a new process every time Apache wants to run a PHP script.  It's slow, but it's easy to set up and I never run into caching issues and stuff like that.

What confuses me here is that if you're "restarting" PHP, that probably means restarting the FastCGI dispatcher.  How that would affect caching is beyond me, because I thought PHP did that.  Check your FastCGI config file first, and if there isn't anything related to acceleration, caching, or bytecode in that file, take a look at php.ini.  I doubt looking at any Nginx config files would be useful.

Sorry I'm a bit confused over this, but I've spent most of my time working with PHP code, but not setting up a production web server.

I'd be interested in knowing what happens, so please do let me know.  Thanks!

I updated the xTest script to add another test.  Test #6 will try to print out your entire config, so we can figure out which variables are not parsing and which are.  The encryption salt will be masked out.

The purpose of the old script was to determine if you have a PHP extension installed that prevents PHP from printing anything that has not been HTML encoded.  Some tools will do this to try to prevent XSS attacks, although my impression is that they cause more problems than they solve.  Thankfully, this doesn't appear to be a problem on your server.

This new script will try to figure out how many variables are empty.  I suspect that the "title" and "author" are the only ones affected, and I want to make sure.

To be honest, though, I still have no idea what's going on, and am not really sure where to go from here.  I'm using PHP 5.3.4, the latest version, so it can't be a parsing problem due to a new version of PHP.

You can try disabling Suhosin.  My server doesn't use it, and I've been running my oekaki with thousands of members for several years without incident.  Other than sanity checks for buffer overflow errors, I don't see what advantage it offers.  However, if disabling Suhosin doesn't fix the problem, turn it back on.

BTW, is the "author" field in your config file still blank?  Try putting something in there.  It doesn't matter what.

Okay, this is really getting frustrating.  I think I know what's going on here, but why your server is doing it is beyond me.  That's the trouble with "automagic" security features.

Try downloading this file and put it in your oekaki folder:  xTest.zip

If you run it, you can try each test, but the output probably won't make much sense to you.  What it's supposed to do is try an number of filtering techniques when printing variables, to see if your server is doing some weird things.

There are some hardened versions of PHP out there that do some automatic filtering.  Do you know if you have "Suhosin" installed as a PHP extension?  You can check PHP extensions by going to the Diagnostics page, and under PHP Information, click "click for more details".

Okay, I updated the ZIP file with a couple changes.  Give this new cpanel a try.

As far as I can tell, the config file is writable, and is being opened properly.  But, it's not being written.  I've added another couple of tests to make sure that the write operation completes, and to verify that the written file is the size it should be.  I also read something interesting on the PHP web site that said writing a file could return "0" instead of "FALSE", so I took that into consideration as well.

If this still doesn't work, the next step would for me to give you a cpanel with an entirely new write routine, but it really shouldn't behave any differently.  You could also send me a copy of your config.php file (it does not contain any database or login information, though it does contain the board's encryption salt).

I find it really bizarre that the board would install just fine, and the config file is not locked, but the cpanel doesn't work.  I'm kind of stumped.

Waccoon wrote:

What bugs me is that you're not getting an error message.  If the board can't write the config file due to a filesystem problem, you should get an error.

So, I'm leaning more towards a filtering problem, but that's kind of odd if you're using a stock LAMP (LEMP?) setup on your own box.  Since the board installed just fine, I'm comparing the difference between the installer and cpanel to figure out what might be the issue.

Here's a modified cpanel for you to try:  cpanel 1.5.5

Other things:
1) Which fields are you changing?  Do they include the "Title" and "Author Name"?
2) Have you tried changing only a few at a time instead of a bunch of them?
3) In the "My Oekaki" administration menu, there's a "Log" option.  When you check the log, under Category/Commet, does it tell you the cpanel was updated recently?
4) Have you had any trouble updating your member profile, or is it just the control panel?

Yeah, if there were any error message I might have a better chance in locating the problem. I didn't use any LEMP installation script - I installed everything one by one, but the setup should be the same as a stock LEMP setup - the only difference between a LAMP setup and a LEMP setup is that a LAMP setup uses Apache while a LEMP setup uses Nginx. So now I should rename the current cpanel to cpanel.php.bak and upload your cpanel.php to the Oekaki and then try to change something? Okay, I'll try to do that and report my findings here. And here are my answers to your questions.

1) I tried changing most of the fields there, including "Title" and "Author Name". None of them worked/saved.
2) I tried changing one of them at a time, two of them at a time, and a bunch of them at a time. Nothing's changed.
3) It did. Here's the screenshot.



4) Nope, no problem at all updating my (or any other) member's profile. Just the control panel.

If all else fails, can I update the settings myself (probably by editing the config.php file)? I'll go ahead and try your alternative cpanel for now. Thanks!