Fatal error on update “tad_DI52”

  • Resolved lexlucas

    (@lexlucas)


    7 years, 10 months ago

    Hi I am facing the same error as reported by dan updated your plugin and the back end is inaccessible with the error:

    Fatal error: Class ‘tad_DI52_Container’ not found in /home/***/wp_html/wp-content/plugins/advanced-cron-manager/advanced-cron-manager.php on line 62

    I have temp renamed the advanced cron plugin folder until fixed.

Viewing 10 replies - 1 through 10 (of 10 total)
  • Plugin Author Kuba Mikita

    (@kubitomakita)

    7 years, 10 months ago

    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?

    Thread Starter lexlucas

    (@lexlucas)

    7 years, 10 months ago

    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, 10 months ago by lexlucas.
    • This reply was modified 7 years, 10 months ago by lexlucas.
    Plugin Author Kuba Mikita

    (@kubitomakita)

    7 years, 10 months ago

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

    Thread Starter lexlucas

    (@lexlucas)

    7 years, 10 months ago

    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..

    Plugin Author Kuba Mikita

    (@kubitomakita)

    7 years, 10 months ago

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

    Thread Starter lexlucas

    (@lexlucas)

    7 years, 10 months ago

    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, 10 months ago by lexlucas.
    Plugin Author Kuba Mikita

    (@kubitomakita)

    7 years, 10 months ago

    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 🙁

    Thread Starter lexlucas

    (@lexlucas)

    7 years, 10 months ago

    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.

    Thread Starter lexlucas

    (@lexlucas)

    7 years, 10 months ago

    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: 

    http://yourdomain.com/wp-cron.php?setcronjob
http://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 “http://yourdomain.com/?doing_wp_cron=1234567890.09876543210987654321&#8221; 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, 10 months ago by lexlucas.
    • This reply was modified 7 years, 10 months ago by lexlucas.
    Plugin Author Kuba Mikita

    (@kubitomakita)

    7 years, 10 months ago

    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: http://wordpress-hackers.1065353.n5.nabble.com/ALTERNATE-WP-CRON-Is-it-worth-it-tp39843p39846.html

    Seems it’s fine to have alternate cron.

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Fatal error on update “tad_DI52”’ is closed to new replies.