internal server error when using plugins

If you compare class-framework-widgets.php, this was added in 4.4.1. It was not present in 4.4. This is the cause of the error.
Line 3020:

			if( ! is_array( $cache_dirs ) )
			{
				/**
				 * Something went wrong reading directory - folder does not exist, access denied, .....
				 * There is nothing we can do.
				 */
				return;
			}

@ricweb0

Yes I solved the error, but the root cause of the error needs to be addressed by Kriesi developers.

Here’s what I did:
Key point for Kriesi. I am not using the Enfold Instagram widget, nor do I plan to or have every used it on this site.
For testing purposes I placed the Enfold Instagram widget in a sidebar and enabled it on a page. With the default settings of the widget, the cache folder is not created. Changing and saving the widget settings “Location of your photos or videos:” to “Cache on your server…”, the avia_instagram_cache folder is immediately created in the uploads folder.

I removed the widget after, since I am not using Instagram. The folder IS removed after removing the widget, so we are back to square one.

The only way to resolve it is to manually create the folder.

Regardless, this needs to be fixed. If you are not using this feature/widget, there’s no need to create a cache folder. There need to be a check in place.

@Ismael,

The custom function you provided does not resolve the issue.

However I stumbled upon this other thread. It looks like it’s a cron job causing the error.

Taking it a bit further, I installed WP Crontrol. In the list of Cron Events, is ‘av_instagram_scheduled_filecheck’. It is scheduled to run every 2 hours. If I manually run the job, the error occurs.

To resolve the issue, the above mentioned article provides steps to remove the cron job from class-framework-widgets.php. However this will not survive an update to Enfold.

So perhaps we need a custom function to remove the cron job OR better yet, fix the issue.

BTW. You can delete the cron job in WP Crontrol.

Ismael,

I already tried the wp_clear_schedule_hook. The result of it clears the schedule, as expected. All this does is resets the next run time to 2 hours. Every time you refresh the /wp-admin page it resets the schedule.

I tried using WP Crontrol to delete the cron job, however it immediately reappears. So there’s something in-place that checks for the job and if it not present, it adds it. Like I mentioned before, I am not using the widget anywhere and it still adds the cron job.

I don’t want to disable WP-Cron entirely with a define statement. This will stop the delete_expired_transients cron job in WP.

For now, I am going to remove the cron job at the source until the issue is resolved, as mentioned in the other thread.