Enabled logging and now Help page gets 500 error

[Russell Todd]

I enabled logging on the help page and when I go back to the page it’s blank. After a little digging I realized that there is now a 500 PHP Fatal Error. Please advise on how I can change the logging settings, perhaps through the database directly??

This is from the PHP error log:

[Wed Sep 27 17:43:46.244388 2017] [:error] [pid 17967] [client 69.38.121.162:15087] PHP Fatal error: Uncaught UnexpectedValueException: DirectoryIterator::__construct(/tmp): failed to open dir: Permission denied in /nas/content/live/xxxxx/wp-content/plugins/the-events-calendar/common/src/Tribe/Log/File_Logger.php:223

Stack trace:
#0 /nas/content/live/xxxxx/wp-content/plugins/the-events-calendar/common/src/Tribe/Log/File_Logger.php(223): DirectoryIterator->__construct(‘/tmp’)
#1 /nas/content/live/xxxxx/wp-content/plugins/the-events-calendar/common/src/Tribe/Log/Admin.php(129): Tribe__Log__File_Logger->list_available_logs()
#2 /nas/content/live/xxxxx/wp-content/plugins/the-events-calendar/common/src/Tribe/Log/Admin.php(16): Tribe__Log__Admin->get_available_logs()
#3 /nas/content/live/xxxxx/wp-content/plugins/the-events-calendar/common/src/admin-views/tribe-options-help.php(49): Tribe__Log__Admin->display_log()
#4 /nas/content/live/xxxxx/wp-content/plugins/the-events-calendar/common/src/Tribe/Settings_Manager.php(264): include_once(‘/nas/content/li…’)
#5 [internal function] in /nas/content/live/xxxxx/wp-content/plugins/the-events-calendar/common/src/Tribe/Log/File_Logger.php on line 223, referer:

[Andras]

Hello Russell,

Thanks for using our plugins and welcome to the forums!

Sorry about this logging issue. I can try to help you solve this.

Based on the error message it looks like you don’t have access to the /tmp directory on your server. This can be 2 cases:

• either the /tmp directory doesn’t exist – this usually resides in the root folder of your server
• or you (your site) doesn’t have privileges to write to this directory. With privileges -755 you should be able to work with this folder already.

If you don’t know what these mean, then your hosting provider should be able to help you out with this.

Let me know if you have any further questions.

Cheers,
Andras

[William]

I wanted to add to this. Frankly, this answer is a hogwash, washing hands type of response.

It’s VERY COMMON (I’d dare say the norm) to NOT have write/create access to /tmp as a non-root user. The page where you show this information, is the same as the page where you enable/disable the functionality. Given this, it seems like there should be a way to recover from this.

I now have this same issue. My hosting company, WPEngine, has stated that they don’t allow /tmp writing. They have suggested that we get help from the plugin author.

And, basically, both of you are pointing the finger at each other. Blah.

We have tried every permutation to fix this. Turning on and turning off the plugin. Looking through the database for a field or setting to switch. So far, we’ve not found anything to fix this problem.

I have lost 8+ hours of work from this. I can’t recover that time. Thankfully, I have a backup from that point in time.

I’m VERY frustrated by this. When YOUR product isn’t working well for ajax queries, and I turn on YOUR logging, I lose 8+ hours of work. And you wash your hands.

[Russell Todd]

William – thanks for weighing in on this.

Like you, I have spent way too much time chasing down issues with this plugin. The sync with google calendar is just not reliable, and over the past month I have wasted hours looking into issues, updating the plugin, retrying, and we’ve finally decided we can’t afford to lose any more time on this. So we’ve switched to another plugin entirely.

The two cases that András mentioned are both legitimate issues, but the fact remains that is a bug in the plugin that causes a PHP Fatal error. Simple error handling would be able to gracefully handle this situation and allow the plugin to work normally. Free advice below:

• When a user enables logging, check to see if there are write permissions on the directory BEFORE saving the setting.
• Put a try… catch around the code in the stack trace above.

These basic coding best practices would keep your plugin functioning correctly. And it would have saved you a customer…

[William]

Agreed.

I got around the problem, for now, by patching the File_Logger.php’s “find the directory to write to” method and statically point it to a folder that I DO have write access to. This let me disable the logging. However, when I tried to reset the file back to its original, it seems the setting doesn’t “stick” and the file resumes erroring.

So, I guess now we’re running with a “custom” version of this plugin.

As a paying user of this plugin.. this, IMO, is ridiculous. I’m not a PHP developer. I shouldn’t have to write code to solve problems that this plugin introduces.

[Barry]

Hi there William and Russell,

We’re sorry for the disruption and realize this must have been a frustrating experience.

It’s VERY COMMON (I’d dare say the norm) to NOT have write/create access to /tmp as a non-root user.

I agree 100% that this is something we can and should anticipate.

In fact, for that very reason, we do already test to see if we have read/write permissions before trying to iterate across the directory. Based on your feedback there is clearly a case we’ve missed and so we’ll make some changes to ensure this doesn’t happen in the future.

When YOUR product isn’t working well for ajax queries, and I turn on YOUR logging, I lose 8+ hours of work. And you wash your hands.

Nobody is washing their hands of the problem — we’re here to help. Andras put forward some solid suggestions and left it open for you to come back if they didn’t help or were not viable.

We’re also not “pointing the finger” at your host — we understand that a configuration where the system temporary directory is inaccessible is a valid one and, as I noted, we have code in place that is intended to handle that (the fact that it doesn’t is, again, something we’ll rectify as quickly as we can).

I’m glad however that you were able to patch things, though as you realize it would be optimal to unwind any direct changes to our plugin code to give you a clean upgrade path up until we ship a fix for the problem.

To that end, could you add a new file to your mu-plugins directory (typically this is located at wp-content/plugins/mu-plugins) containing the following code:

<?php
# Disable logging
add_filter( 'tribe_common_logging_engines', '__return_empty_array' );

This should have the effect of forcibly shutting down our logging and you can undo any custom changes you made in preparation for our upcoming releases.

Let me know if that helps.

[Barry]

This reply is private.

[Victor]

Hello Russell!

Just wanted to share with you that a new maintenance release (for the Week of 16 October 2017) is out, including a fix for this issue

Find out more about this release → https://theeventscalendar.com/maintenance-release-for-the-week-of-16-october-2017/

Please update the plugins and let us know if the fix works for your site.

Best,
Victor

[Support Droid]

Hey there! This thread has been pretty quiet for the last three weeks, so we’re going to go ahead and close it to avoid confusion with other topics. If you’re still looking for help with this, please do open a new thread, reference this one and we’d be more than happy to continue the conversation over there.

Thanks so much!
The Events Calendar Support Team

[Author]

Posts