Ceon URI Mapping v4.x

[philip937]

hi guys, just found this in my error log this evening, not sure if its anything to be concerned about? its the first and only one i've had. any idea what it could be?

[09-Apr-2013 21:26:39 UTC] PHP Fatal error: Call to a member function add() on a non-object in /home/site/public_html/includes/classes/class.CeonURIMappingHandlerBase.php on line 131

Thanks in advance.

[dave010880]

hi guys, just found this in my error log this evening, not sure if its anything to be concerned about? its the first and only one i've had. any idea what it could be?

[09-Apr-2013 21:26:39 UTC] PHP Fatal error: Call to a member function add() on a non-object in /home/site/public_html/includes/classes/class.CeonURIMappingHandlerBase.php on line 131

Thanks in advance.

I have an update on this if anyone else comes across it, this particular problem was self made. I had simply copied the code from the includes/functions/html_output.php and incorrectly put that into the admin/includes.. etc. Using eth correct modified code has removed this error.

Unfortunately I till have the original problem of no category cration and meta's not working

[countrycharm]

hi guys, just found this in my error log this evening, not sure if its anything to be concerned about? its the first and only one i've had. any idea what it could be?

[09-Apr-2013 21:26:39 UTC] PHP Fatal error: Call to a member function add() on a non-object in /home/site/public_html/includes/classes/class.CeonURIMappingHandlerBase.php on line 131

Thanks in advance.

I have an update on this if anyone else comes across it, this particular problem was self made. I had simply copied the code from the includes/functions/html_output.php and incorrectly put that into the admin/includes.. etc. Using eth correct modified code has removed this error.

Unfortunately I till have the original problem of no category cration and meta's not working

This problem still exits. I know one said that he had the problem because he had incorrectly put the includes/functions/html_output.php file into admin/includes/functions/html_output.php and it created this problem That's not the case for me. I can confirm that both html_output.php files are in there correct place with the right code inside them and the error is still being created.

Diva any suggestions thank you

[lhungil]

[09-Apr-2013 21:26:39 UTC] PHP Fatal error: Call to a member function add() on a non-object in /home/site/public_html/includes/classes/class.CeonURIMappingHandlerBase.php on line 131

This problem still exits. ...

Took a "quick" look at this today. It appears in version 4.4.1, this code can be called before the "message stack" is initialized. (load points: message stack is at 130 and CEON URI is at 99).

However this code is only called if the "REQUEST_URI" cannot be found. This PHP variable is needed to determine what URI was requested (and will normally be populated by your web server). If this variable is not found, the CEON code attempts to preform some workarounds (and manually determine / build the variable).

Some questions:

1. What web server software is on the site displaying this error?
2. Is the server using mod_php? suPHP? FastCGI? Something else?

[philip937]

Took a "quick" look at this today. It appears in version 4.4.1, this code can be called before the "message stack" is initialized. (load points: message stack is at 130 and CEON URI is at 99).

However this code is only called if the "REQUEST_URI" cannot be found. This PHP variable is needed to determine what URI was requested (and will normally be populated by your web server). If this variable is not found, the CEON code attempts to preform some workarounds (and manually determine / build the variable).

Some questions:

1. What web server software is on the site displaying this error?
2. Is the server using mod_php? suPHP? FastCGI? Something else?

Looks like there has been discussion on this since I first posted about this. I am yet to be able to replicate the problem on my site all I do know is that it does happen occassionally. However putting things into perspective my site has around 600-1000 visits a day and I only get about 10 of these errors a month.

If I ever work out under what conditions the error occurs then I will come back and post more info.

With what you have determined from the code it sounds like just once every blue moon the server fails to execute the request uri perhaps?

[countrycharm]

Took a "quick" look at this today. It appears in version 4.4.1, this code can be called before the "message stack" is initialized. (load points: message stack is at 130 and CEON URI is at 99).

However this code is only called if the "REQUEST_URI" cannot be found. This PHP variable is needed to determine what URI was requested (and will normally be populated by your web server). If this variable is not found, the CEON code attempts to preform some workarounds (and manually determine / build the variable).

Some questions:

1. What web server software is on the site displaying this error?
2. Is the server using mod_php? suPHP? FastCGI? Something else?

What web server software is on the site displaying this error?

I'm using PHP Version: 5.4.24 (Zend: 2.4.0) and

Database: MySQL 5.1.72-cll

Is the server using mod_php? suPHP? FastCGI? Something else?

No to the question above.

[lhungil]

... With what you have determined from the code it sounds like just once every blue moon the server fails to execute the request uri perhaps?

Most likely. You may want to comment out line 131, use error_log(), or adjust the code to send the customer to your homepage / error page when this occurs...

... I'm using:
PHP Version: 5.4.24 (Zend: 2.4.0)
Database: MySQL 5.1.72-cll
...

Could possibly be something with PHP 5.4 / Zen Cart 1.5... Although I am running a heavily modified version of 1.5.1 on PHP 5.4 without seeing this error (although I am using a different alternative URL generator on that site).

Webserver Software and Version? (EX: Apache 2.2.26, Apache 2.4.7, IIS 8.5, nginx 1.5.8, etc)
Connector from Webserver Software to PHP? (EX: suphp, mod_php, fastcgi, etc)
Security Options? (such as mod_security, suhosin, etc)

I ask because most likely the connector (or some security module / setting) is the cause of REQUEST_URI not being populated. I'm running Zen Cart under both mod_php and suphp without encountering a missing REQUEST_URI.

Note: I do not know when / if I will be able to do futher testing on this subject, as I have been spending most of my time working with Zen Cart 1.5.2 RC2 / 1.6.0 under PHP 5.5 lately.

[countrycharm]

Most likely. You may want to comment out line 131, use error_log(), or adjust the code to send the customer to your homepage / error page when this occurs...


Could possibly be something with PHP 5.4 / Zen Cart 1.5... Although I am running a heavily modified version of 1.5.1 on PHP 5.4 without seeing this error (although I am using a different alternative URL generator on that site).

Webserver Software and Version? (EX: Apache 2.2.26, Apache 2.4.7, IIS 8.5, nginx 1.5.8, etc)
Connector from Webserver Software to PHP? (EX: suphp, mod_php, fastcgi, etc)
Security Options? (such as mod_security, suhosin, etc)

I ask because most likely the connector (or some security module / setting) is the cause of REQUEST_URI not being populated. I'm running Zen Cart under both mod_php and suphp without encountering a missing REQUEST_URI.

Note: I do not know when / if I will be able to do futher testing on this subject, as I have been spending most of my time working with Zen Cart 1.5.2 RC2 / 1.6.0 under PHP 5.5 lately.

I ask because most likely the connector (or some security module / setting) is the cause of REQUEST_URI not being populated. I'm running Zen Cart under both mod_php and suphp without encountering a missing REQUEST_URI.

Thanks for your help on this. It's not throwing the error all the time, just sometimes. I will check further in what you suggested. Thanks again.

[lhungil]

Thanks for your help on this. It's not throwing the error all the time, just sometimes. I will check further in what you suggested. Thanks again.

No problem and I really hope the root cause (of REQUEST_URI not being populated) is eventually found. If you find out I would love to know the exact cause. At the least it would give us all an idea of where best to send the request if the REQUEST_URI is missing.