OK, our error log works again (the file was too big an had to be manually cleared ):
The output of the error log after calling the snippet via a ssl-page or a 404-error:
[2010-12-09 19:05:16] (ERROR @ /index.php) Testing: 1
[2010-12-09 19:05:18] (ERROR @ /index.php) Testing: 1
[2010-12-09 19:05:41] (ERROR @ /index.php) Testing: adsfasdfadsfsadf
[2010-12-09 19:05:46] (ERROR @ /index.php) Testing: 1
[2010-12-09 19:05:49] (ERROR @ /index.php) Testing: 1
[2010-12-09 19:06:03] (ERROR @ /index.php) Testing: 794
[2010-12-09 19:06:05] (ERROR @ /index.php) Testing: 1
[2010-12-09 19:06:08] (ERROR @ /index.php) Testing: 460
[2010-12-09 19:06:09] (ERROR @ /index.php) Testing: 460
[2010-12-09 19:06:09] (ERROR @ /index.php) [OnWebPageInit]1
[2010-12-09 19:06:21] (ERROR @ /index.php) Testing: 1
[2010-12-09 19:06:25] (ERROR @ /index.php) Testing: 460
[2010-12-09 19:06:25] (ERROR @ /index.php) [OnWebPageInit]1
[2010-12-09 19:06:32] (ERROR @ /index.php) Testing: 1
In summary the plugin works very well with the exception of the 404-error-page which redirects to the startpage instead of the predefined error-page.
Hi cipa,
the code works and the 404-page works, too. Very good!
But unfortunately using the improved plugin we got thousands of errors in our error-log leading to crash down of our server because of RAM-Overload while many people went to our page at the same time (directly after a Newsletter-Send-Out with links to our webpage).
The Errors were mostly of this type:
(ERROR @ /server/modx/core/xpdo/cache/xpdocachemanager.class.php : 413) PHP warning: unlink(/server/modx/core/cache/objects/modTemplateVarResource/2c3468c42bcf1c299e5839accdace0ea.cache.php) [<a href=’function.unlink’>function.unlink</a>]: No such file or directory
(ERROR @ /server/modx/core/xpdo/cache/xpdocachemanager.class.php : 421) PHP warning: closedir(): 413 is not a valid Directory resource
We also get these errors without using the ssl-plugin but in a very less number which is normally no problem for our server. Unfortunately we have no idea how we can figure out what could be the reason for this error...
Hi Letti,
A quick dirty fix would be changing
if (unlink($path)) {
to
if (@unlink($path)) {
and
closedir($handle);
to
@closedir($handle);
You should also open a bug for this and point to this post. Maybe the developers can do something for the future versions
Thanks a lot. The error-messages stopped. And it seems like the error-messages of this type which were also produced (in a less number) without the ssl-plugin disappeared, too. So it seems like this bug also made problems in other areas of MODx or maybe in combination with other plugins/snippets.
Can you explain shortly what is the function of @ (which you added in your last post) in this case?
Now we will watch in the next hours if the problem disappears completely (hope so)...
Thanks a lot again!!
Thank you very much!
I have read the explanations on the recommended site but I didn´t understand if @ stops only the error-reporting or does @ also stop the script at this point?
Do you think we now can use the ssl-plugin with the @ without having problems or will we still have the same problems of RAM-overload?
You shouldn’t use @ error suppressing anywhere. It only doesn’t output a error message but the error still is there! If an PHP error occurs you have to update your code doing the right not the server accepting it.
What is the final code for this plugin?