The database configuration table row for SESSION_WRITE_DIRECTORY keeps getting reset to <my-renamed-admin>/includes/cache, and the admin page would not load until I created this directory and made it writable.
Printable View
The database configuration table row for SESSION_WRITE_DIRECTORY keeps getting reset to <my-renamed-admin>/includes/cache, and the admin page would not load until I created this directory and made it writable.
I've not seen this happen, at least not on a multitude of linux servers. What's your environment?
Fedora Core 13, Apache, PHP 5.3.15.
I just did a test by changing the value for SESSION_WRITE_DIRECTORY to point to an invalid folder. Then went to the admin URL and it let me log in and work fine without any unexpected redirects.
Help me trigger the problem. Were you starting from a point of having just an import of an old database which had the wrong SESSION_WRITE_DIRECTORY set? Or was it an old configure.php that was pointing to wrong folders too? or both?
I would assume that all of the logic for the symptom you're reporting is handled by /admin/includes/init_includes/init_cache_key_check.php
Upon looking at it I can only think of one thing that might be a problem, and that's if you had put the init_cache_key_check.php file into the init_includes/overrides folder for some reason ... in which case it might generate the wrong path. We'll consider addressing that in a future version, but there should be no need to do an override on that file, so that issue feels minor.
Not sure how exactly to trigger what you're reporting though.
The only thing old was an old configure.php file, which I pulled from my 151 installation and updated the catalog dir, logs dir, db, etc. I didn't notice any new entries in this file that were added since 1.5.1, but maybe I missed something. The file is attached.
A new db with test data was used. No other changes from vanilla 1.5.3 were made.
Hmmmm. Even testing with that I can't seem to trigger it. :(
If I rmdir , and then set SESSION_WRITE_DIRECTORY configuration_value to "/tmp" it happens.
I have to mkdir <my cart dir>/<my admin dir>/includes/cache then chmod 777 to make it work.
Why would SESSION_WRITE_DIRECTORY get set to <admin_dir>/includes/cache, a directory which doesn't exist in the default installation in the first place?
Okay, I've triggered it.
And I see why it's doing it. (wrong logic detecting the root folder, and then a redirect that always happens if the folder is missing. So ... don't delete the folder :P )
Now the challenge is determining how critical it is.
Wondering what the workflow process was that got you to the point of deleting the cache folder?
The value of that db row when it's created is "/tmp". There is no admin/includes/cache folder in the default installation. So why did it get changed to a folder which doesn't exist?
1. It's a bug.
2. It's an attempt to integrate the logic for fix_cache_key into core so people don't need to run that separate util if they switch servers.
3. This is what it was doing:
- if the directory named by SESSION_WRITE_DIRECTORY doesn't exist, it was detecting what folder the script was running in so that it could guess what the correct "store root" was, and then appending /cache to it (since if the one in the db didn't exist then the best guess after that is /cache). The bug is that the file doing the detection is 2 levels under the admin folder, and thus was *incorrectly* guessing that it needed to use /admin/includes/ instead of just /
It's easy to avoid encountering the bug:
- create the /cache folder (or any other writable folder)
- set SESSION_WRITE_DIRECTORY to point to it
The fix to have it guess the correct /cache folder is to change the file I mentioned above, and alter the realpath(dirname(__FILE)) to be realpath(dirname($_SERVER['SCRIPT_FILENAME'])) .... but the redirect will still happen if you don't actually have the /cache folder.
But I'm reluctant to commit a code fix for the above, because I'm wondering if the original need for this has maybe expired, and even using fix_cache_key may no longer be necessary, given that sessions are now only stored in the database, not the filesystem.
Further research is required to determine the optimum solution.
What if you just set the default value for SESSION_WRITE_DIRECTORY in the mysql script to DIR_FS_CATALOG/cache? That exists.
Will consider it.
It's just strange that in all the testing we've done with multiple environments and upgrades we never triggered this issue.
ok. I created the known bugs in 1.5.3 thread and added a pointer to this thread.
Here's a replacement file which should resolve the issue:
Simply unzip and upload to your server as /admin/includes/init_includes/init_cache_key_check.php
THIS FILE SHOULD ONLY BE USED ON ZC v1.5.3. .... DO NOT put it on any other version!
I wonder if the issue is that the /cache folder by default isn't writable. Could the installer check this condition and block progress as it does with configure.php files?
It does already point out that the folder isn't writable when running zc_install, on the System Inspection page.Quote:
Originally Posted by swguy
Hello there,
I originally posted here, when I first noticed the error it was a blank page, and then I went to 1.5.4 and it was 'too many redirects' on admin.
http://www.zen-cart.com/showthread.p...ht=blank+admin
I am going crazy here, lol. I have found this thread and can see there must be something wrong with my setup. I have had the same cache directory pointed to for ten year in configure:-
define('DIR_FS_SQL_CACHE', '/home/******/public_html/cache');
Is there a way to stop this check? I am sure the above is valid, I haven't changed it. I created more cache folders in admin as swguy put, and all permissions are 777. Hope somebody may be able to help please. thanks in advance.
I tried the replacement file contained here in this thread to no avail :-(
So where is it at now?
- what ZC version are you using?
- which init_cache_key_check.php file are you now using?
- are you actually getting just "blank page"? or are you really getting the "too many redirects"?
- Is your webserver running Linux/Ubuntu/CentOS/Windows/... what? If you don't know the answer to that, normally you could get it via your Admin, but since that's where your problem is, you could ask your hosting company to tell you what operating-system your server is using. They can answer the PHP questions too, if you don't know the answers:
- what's your PHP version? Is it running "PHP as CGI"? or "suPHP"? or simply as an Apache module?
Hello DrByte,
thanks ever so much for taking the time to reply to me. Please bear with me, I am just going to confirm the last two details. I think I know but I am not 100%.
- what ZC version are you using?
I upgraded to 1.5.3, then from there to 1.5.4. I applied sql patches before the admin went awry thankfully, so that is set
- which init_cache_key_check.php file are you now using
I am using the one on this thread, before that it was the 1.5.4 version, before that it was 1.5.3
- are you actually getting just "blank page"? or are you really getting the "too many redirects"?
What I think happened, is upgraded to 1.5.3 then saw blank page. I had a break then went back to it the other day and still blank. So I saw change log and thought there might be a strong chance it may be fixed in 1.5.4 so upgraded to that. I had someone trying to figure it out, and they notified it was redirect loop and been ever since.
- Is your webserver running Linux/Ubuntu/CentOS/Windows/...
Architecture x86_64
Operating System linux
- what's your PHP version? Is it running "PHP as CGI"? or "suPHP"? or simply as an Apache module?
PHP Version 5.3.28 - for the second part I will update this post accordingly, just wanted to get a reply to you as soon as I knew. I am sure it is either PHP or CGI though.
I asked the question as you did and only got this (?):-
The PHP handler on your server is DSO.
Also, is there a way to disable the function of this file init_cache_key_check? I have cache folder with sub folders for modules. Would that be messing with this file somehow?
You could just empty out the file contents, or comment-out all the code in the file.Quote:
Originally Posted by HeathenMagic
Hello DrByte,
I emptied the file and encountered some errors similar to this:-
I had a module that was displaying similar on the catalog itself but no fatal error. So regards to the admin, I found the files these logs were from and removed them and could get to the admin.Quote:
[16-Jan-2015 11:38:33 America/New_York] PHP Warning: mysql_list_fields() [<a href='function.mysql-list-fields'>function.mysql-list-fields</a>]: Access denied for user 'nobody'@'localhost' (using password: NO) in /
Regarding the file I emptied as you suggested, I tried the file again with code but it still does redirects. So obviously there is something it doesn't like about my server or something else its not giving clues to (admin only).
Thanks for the help! Appreciate it. And if anybody is having the same issue after trying the above fix, it is Numinix modules in the admin that were giving errors and error logs as a secondary error. With regards to that, I suspect it is deprecated MySQL code in those files perhaps.
Yes. All "mysql_" function calls need to be rewritten to use the built-in Zen Cart database function calls, else they won't work beyond PHP 5.3 or Zen Cart 1.5.1.Quote:
Originally Posted by HeathenMagic
Quote:
Originally Posted by HeathenMagic
I.e. Basically the plugin would need to be updated to a version that supports ZC 1.5.2/1.5.3+ as part of the upgrade/new installation... Numinix product/code is typically maintained up-to-date either here on ZC, on github or at their site... Without identifying the plugins as requested by the posting tips, further (specific) assistance on this issue is not possible.Quote:
Originally Posted by DrByte
Thanks DrByte! It makes sense regarding the separate errors I was getting. It is a shame I wasn't able to figure out what is making init_cache_key_check.php cause redirects, but making empty is making admin accessible :-)
Regarding Numinix, all modules are current on the site in question. I checked just now, and one has been updated today, mentioning 1.5.3 compatibility as a feature. Probably just a case of waiting for the others to be updated one at a time by Numinix.