Fatal error on update “tad_DI52”

Cannot be! I’m not using tad_DI52_Container anymore and it’s not mentioned anywhere. Are you sure you updated to 2.2.0?

Yes I updated to 2.2.0, I assure you that’s the error message I received, I saw a update available about 50 min ago clicked update then the whole back end error-ed out with that message.

I don’t know if it is related (I doubt it as the same error was reported just before me) but yesterday I switched my php-fpm config from ProxyPassMatch to SetHandler and increased the resource settings in my user pool and was experiencing a problem with the cron list displaying queuing and not automatically running.

I was looking in to other ways of running the cron jobs when I saw your update.

• This reply was modified 7 years, 7 months ago by lexlucas.
• This reply was modified 7 years, 7 months ago by lexlucas.

You are right! I had a mention of DI52 in delete.php file which is running upon plugin removal. Patch is coming!

I wasn’t sure why but it makes sense with what you said about the mention of DI52 in delete.php (I take it this is run/included when the update function runs) I was in the process of taking screen shots for you and when I renamed the folder back and re activated you plugin it started working again..

Sounds like the case ?? thanks a ton for reporting and helping me fix this!

No problem, Thank you for creating such a useful tool.

I have another quick question for you does your pro version have the ability to view/edit the cron job command or edit the schedule of the job?

On a side note I know my timing is not the best as I know your probably busy repairing your code and updating your svn, But do you know why all the cron jobs would be stuck “in queue” after altering php-fpm handler and pool resources?

This is a screen shot of my Cron Manager tab: https://image.ibb.co/mHijRa/4.png

Thanks

• This reply was modified 7 years, 7 months ago by lexlucas.

You cannot manage the cron job command with PRO, unfortunately. You can edit the schedules with the free version, but only the schedules you registered with ACM. That’s because editing them could break the 3rd party plugins.

The same problem “In queue” I have on my localhost (I develop using Docker) and I have not idea why it’s not spawning. So I think I cannot help you with this one ??

Thanks,

I think I might be on to something, The main reason I switched my php-fpm config from ProxyPassMatch to SetHandler was to enable parsing of .htaccess for an extra level of basic protection for a subdomain, I just read that someone else had a problem with the cron jobs not running due to a few rewrite lines in .htaccess so it stands to reason that might be the cause for my problem maybe yours?

These where the lines that were causing his issues:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} .
RewriteCond %{QUERY_STRING} !^(s|p)=.*
RewriteCond %{REQUEST_URI} !.*wp-admin.*
RewriteRule ^(.*)$ /$1? [R=301,L]
</IfModule>

I don’t have lines that match 100% but some similar that i’am stripping out to test now.

Thanks for your time.

Just to update as it might be helpful to others stuck with the same problem.

adding define('ALTERNATE_WP_CRON', true);

To my wp-config.php then visiting:

https://yourdomain.com/wp-cron.php?setcronjob
https://yourdomain.com/wp-cron.php?doing_wp_cron

Fixed the problem for me, All the cron jobs are firing and being correctly listed within your plugin.

You can also use the following rewrite rule to prevent “https://yourdomain.com/?doing_wp_cron=1234567890.09876543210987654321” showing up in your url bar and for SEO reasons.

#Rewrite Wp Cron Errors:
RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron=[0-9]+.[0-9]+(&|$) [NC]
RewriteRule ^ %{REQUEST_URI}? [R=301,L]

I am still looking at the different methods to trigger cron jobs from cpanel cron and a rewrite rule to protect wp-cron.php from being externally triggered as it looks like it might be a possible weak point in potential DDos attacks.

• This reply was modified 7 years, 7 months ago by lexlucas.
• This reply was modified 7 years, 7 months ago by lexlucas.

That’s awesome you found the answer! I can confirm it’s not about the .htaccess rules and ALTERNATE_WP_CRON looks right.

Regarding the vulnerability check this post: https://wordpress-hackers.1065353.n5.nabble.com/ALTERNATE-WP-CRON-Is-it-worth-it-tp39843p39846.html

Seems it’s fine to have alternate cron.