http://joburgonline.com/*admin**

Winchester Responsive
CKEditor

*not named admin - have renamed it temporarily to something else after the admin directory was not accessible to test using another name.

Error on Windows and chrome browser

The webpage at http://joburgonline.com/admin/login.php?camefrom=index.php&zenAdminID=rtpeotqgmgqu28ninssu2jalh1 might be temporarily down or it may have moved permanently to a new web address.
ERR_CONTENT_DECODING_FAILED

error on safari on mac

Safari can't open the page http://joburgonline.com/admin/login.php?camefrom=index.php. The error is: "cannot decode raw data" (NSURLErrorDomain:-1015)

We haven't done anything other than downloading a backup after creating a new FTP access account.

Looked at my configure.php files - nothing changed
Nothing uploaded other than the CKEditor which was working after installing in the Admin panel

http://joburgonline.com

Site works fine

I searched ERR_CONTENT_DECODING_FAILED and came up with this:

It happens when your HTTP request's headers claim that the content is gzip encoded, but it isn't. Turn off gzip encoding setting or make sure the content is in fact encoded.

It might be a place to start.

answer=42:

I searched ERR_CONTENT_DECODING_FAILED and came up with this:

It happens when your HTTP request's headers claim that the content is gzip encoded, but it isn't. Turn off gzip encoding setting or make sure the content is in fact encoded.

It might be a place to start.

I’m having to go through the database to disable gzip.

Gzip enabled or disabled through phyMyAdmin in configuration table made no difference

Taken from my logs

GET /v######n/login.php?camefrom=define_pages_editor.php HTTP/1.0

Still not resolved.

Tried to login to my admin panel this morning again to get an error log for posting on this forum.> mod_fcgid: stderr: PHP Warning: strtotime(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /var/www/vhosts/joburlnx.ehost-services221.com/joburgonline.com/my_renamed_admin/login.php on line 13

So I went and had a look at the login.php file and found this, line 13 highlighted.

define('ADMIN_PASSWORD_EXPIRES_INTERVAL', strtotime('- 90 day'));

That has nothing to do with time zones. The only timezone setting that I have changed were in my other thread:

the edited or commented out code in root folder: /includes/extra_configures/set_time_zone.php

if ($TZ != '') {
//putenv('TZ=' . $TZ);
//@date_default_timezone_set($TZ);

vs original

if ($TZ != '') {
putenv('TZ=' . $TZ);
@date_default_timezone_set($TZ);

timezone in includes/extra_configures/set_time_zone.php:

// put your timezone here. Refer to http://www.php.net/manual/en/timezones.php
  $TZ = 'Africa/Johannesburg';  // eg: 'Europe/Oslo'

Parafanaylya:

Still not resolved.

Tried to login to my admin panel this morning again to get an error log for posting on this forum.

So I went and had a look at the login.php file and found this, line 13 highlighted.

define('ADMIN_PASSWORD_EXPIRES_INTERVAL', strtotime('- 90 day'));

> 
> That has nothing to do with time zones. The only timezone setting that I have changed were in my other [thread](https://www.zen-cart.com/showthread.php?223146-Blank-site-after-installing-using-Plesk-control-panel): 
> 
> 
> the edited or commented out code in root folder: /includes/extra_configures/set_time_zone.php
> 
> ```php
if ($TZ != '') {
//putenv('TZ=' . $TZ);
//@date_default_timezone_set($TZ);

vs original

if ($TZ != '') {
putenv('TZ=' . $TZ);
@date_default_timezone_set($TZ);

> 
> timezone in includes/extra_configures/set_time_zone.php:
> 
> ```php
// put your timezone here. Refer to http://www.php.net/manual/en/timezones.php
  $TZ = 'Africa/Johannesburg';  // eg: 'Europe/Oslo'

See post #2 in this link:
https://www.zen-cart.com/showthread.php?219463-Warning-strtotime%28%29-It-is-not-safe-to-rely-on-the-system-s-timezone-settings
Maybe this could help.

answer=42:

See post #2 in this link:
https://www.zen-cart.com/showthread.php?219463-Warning-strtotime%28%29-It-is-not-safe-to-rely-on-the-system-s-timezone-settings
Maybe this could help.

Thanks. I already had my timezone inserted into that file

Unfortunately this particular file modification which I guess has resulted in this message is a bit of a result of previous work that has been done to specifically support login to the admin for this ZC user at this host.

Last related action that was posted as necessary was finding another way to set the timezone because the php command putenv has been disabled by the host in the shared environment used at this site. Whether the solution is to add a command to an .htaccess or if it is possible to have/generate a php.ini file or not is to be seen. Oh and the issue may have been posted by a user with a very similarly spelt name because for some reason this user had to create a new account and continue the discussion but appears to be back now in this username.

There is still some debate about whether such a warning is the true cause of system non-response, but that issue is the last of things that appeared necessary in order to support continued operation...

Parafanaylya:

Still not resolved.

Tried to login to my admin panel this morning again to get an error log for posting on this forum.

So I went and had a look at the login.php file and found this, line 13 highlighted.

define('ADMIN_PASSWORD_EXPIRES_INTERVAL', strtotime('- 90 day'));

> 
> That has nothing to do with time zones. The only timezone setting that I have changed were in my other [thread](https://www.zen-cart.com/showthread.php?223146-Blank-site-after-installing-using-Plesk-control-panel):
One may think that there is no timezone relationship, but the system is not able to say what time it is currently to be able to compare the current time to 90 days before or after today... So, it too is a factor of the timezone and is something that should be a known value to support operation.

mc12345678:

Unfortunately this particular file modification which I guess has resulted in this message is a bit of a result of previous work that has been done to specifically support login to the admin for this ZC user at this host.

The admin panel continued to work fine for a few days....

mc12345678:

Last related action that was posted as necessary was finding another way to set the timezone because the php command putenv has been disabled by the host in the shared environment used at this site. Whether the solution is to add a command to an .htaccess or if it is possible to have/generate a php.ini file or not is to be seen.

Our host suggested a change to the .htaccess file, but they won't allow changes to the php.ini file

mc12345678:

Oh and the issue may have been posted by a user with a very similarly spelt name because for some reason this user had to create a new account and continue the discussion but appears to be back now in this username.

Correct - I couldn't access my original user profile after a password change.

mc12345678:

There is still some debate about whether such a warning is the true cause of system non-response, but that issue is the last of things that appeared necessary in order to support continued operation...

I need to resolve the issue but have no idea what is causing the lack of access.

So it worked and then it stopped working... what changed?

If I remember correctly, though I probably didn't, I thought in one of the posts related to this that php related information as gathered from the admin->version area had been provided. That same information if gathered again may show what "new" options have been disabled or how php has been altered. Otherwise, would look again at the htaccess file to validate that it contains the content expected. Not too long ago on a server not so far far away, had a service modify or as they thought of it "update" the htaccess of a site. Made their things work "wonderfully" but completely disabled everything else about the site... fortunately only went unnoticed a couple of hours for a site that mostly provides information rather than paid for services, but still...

Point being, if identify what changed, can identify what to do next.

mc12345678:

So it worked and then it stopped working... what changed?

I wish I knew

mc12345678:

If I remember correctly, though I probably didn't, I thought in one of the posts related to this that php related information as gathered from the admin->version area had been provided. That same information if gathered again may show what "new" options have been disabled or how php has been altered. Otherwise, would look again at the htaccess file to validate that it contains the content expected. Not too long ago on a server not so far far away, had a service modify or as they thought of it "update" the htaccess of a site. Made their things work "wonderfully" but completely disabled everything else about the site... fortunately only went unnoticed a couple of hours for a site that mostly provides information rather than paid for services, but still...

Point being, if identify what changed, can identify what to do next.

I cannot remember making any changes myself to files that would kill access to the Admin portal. After the fix, I added and used the Plugin CKEditor....

The sites, from my limited understanding, appear to work in tandem. Neither site nor admin worked, then both started working when the changes were made to the set-time-zones.php file.

In /my_admin/.htaccess:

#
# @copyright Copyright 2003-2013 Zen Cart Development Team
# @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
# @version GIT: $Id: Author: DrByte  Sat Dec 21 17:00:00 2013 -0500 Modified in v1.5.3 $
#
# This is used with Apache WebServers
#
# The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions
# It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.
# Will also prevent people from seeing what is in the dir. and any sub-directories
#
# For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.
# Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.
# Example:
#<Directory "/usr/local/apache/htdocs">
#  AllowOverride Limit Options Indexes
#</Directory>
###############################
DirectoryIndex index.php

# deny *everything*
<FilesMatch ".*\..*">
  Order Allow,Deny
  Deny from all
</FilesMatch>

mc12345678:

Point being, if identify what changed, can identify what to do next.

Is there a file or list of files that I could have a look at?

mod_fcgid: stderr: PHP Warning: strtotime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /var/www/vhosts/joburlnx.ehost-services221.com/joburgonline.com/my_renamed_admin/login.php on line 13				Apache error

Parafanaylya:

I wish I knew

I cannot remember making any changes myself to files that would kill access to the Admin portal. After the fix, I added and used the Plugin CKEditor....

The sites, from my limited understanding, appear to work in tandem. Neither site nor admin worked, then both started working when the changes were made to the set-time-zones.php file.

In /my_admin/.htaccess:

@copyright Copyright 2003-2013 Zen Cart Development Team

@license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0

@version GIT: $Id: Author: DrByte Sat Dec 21 17:00:00 2013 -0500 Modified in v1.5.3 $

This is used with Apache WebServers

The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions

It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.

Will also prevent people from seeing what is in the dir. and any sub-directories

For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.

Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.

Example:

#<Directory "/usr/local/apache/htdocs">

AllowOverride Limit Options Indexes

#</Directory>
###############################
DirectoryIndex index.php

deny everything

<FilesMatch "...">
Order Allow,Deny
Deny from all
</FilesMatch>

The htaccess file that would be in question would likely be the one in the root of the store not the one in the admin directory.

Thing is, when the store started working again successfully, was a complete backup made of the files? If so, how do those compare to the current store files? Is the change that was placed in whatever htaccess file still there or does it need to be applied again? In the future, if something fixes the problem, it helps you (and others) to specifically identify what fixed the issue. That way it could be a sort of backup in public...

I didn't finish searching for what was needed because of all the reports of the problem being fixed at the time.

It looks like you might see a solution to that specific issue if in your catalog's .htaccess you added:

php_value date.timezone 'Africa/Johannesburg'

This would be the file located at: /var/www/vhosts/joburlnx.ehost-services221.com/joburgonline.com/.htaccess

mc12345678:

It looks like you might see a solution to that specific issue if in your catalog's .htaccess you added:

php_value date.timezone 'Africa/Johannesburg'

> 
> This would be the file located at: /var/www/vhosts/joburlnx.ehost-services221.com/joburgonline.com/.htaccess

There wasn't a file as above, so I created the file in that location, and added that line, the only line in the file.

No difference....

Parafanaylya:

There wasn't a file as above, so I created the file in that location, and added that line, the only line in the file.

No difference....

When say no difference, does that mean that the front/catalog side STILL works, still DOESN'T work? The Admin STILL doesn't work? Does that mean that the same mydebug-adm file is being generated or is there different content?

If the catalog works but the admin does not, and there are no error messages about the catalog side timezone setting, then would again take a look at includes/extra_configures/set_time_zone.php as well as admin/includes/extra_configures/set_time_zone.php to see if/what difference there is.

Also, would apply the above suggested htaccess modification to the admin/.htaccess file, try again, and report results.