Auto Updates Probleme obwohl Vorraussetzungen ok, wie debuggen?

Ich versuche schon seit einer gefüllten Ewigkeit erfolglos die automatischen Updates einer Wordpress Installation zum Laufen zu bringen. Komme leider nicht weiter, vielleicht hat jemand einen Tipp zum Debuggen.

So schaut die Situation aus:

• Besagte WordPress Installation befindet sich auf dem gleichen Server mit gleichen Servereinstellungen wie andere Wordpressinstallationen, die ohne Probleme funktionieren. Ich schließe Serverprobleme aus.
• Manuelles Update funktioniert ohne Probleme, darum schließe ich Berechtigungsprobleme aus.
• Ein Background Update Tester Plugin meldet: alles ok
• Einstellungen zum automatischen Updates in der config habe ich zigg mal probiert, erfolglos. Schlussendlich benutze eine Standard config, wie sie in anderen Autoupdate funktionierenden WordPress Installationen funktionier1. Minor Updates möchte ich haben, große nicht.
• Es ist eine sehr alte WordPress Installation die zigg mal upgedatet wurde. Zur Zeit Version 4.9.7
• Wenn ich das Autoupdate wie hier beschrieben triggere: http://blog.birdhouse.org/2013/11/02/for…ss-auto-update/ funktioniert es. Nur passiert das Autoupdate nicht von alleine. Alle anderen Blogs auf dem gleichen Server mit gleichen PHP Einstellungen updaten sich, nur der eine nicht. Ich vermute, dass aus ihren einem Grund der Cron Job nicht angelegt wird, da manuelle Updates funktionieren und sogar das Autoupdate, wenn ich es per Script anstosse, funktioniert.

Hat jemand eine Idee wie ich das Ganze loggen bzw. debuggen kann, damit ich eine Chance habe zu erkennen wo es hackt? Querfeldein einfach nur die Vorrausetzungen prüfen hat leider nichts gebracht. Ich denke ich muss das Ganze systematisch debuggen… Wobei ich keinen Plan habe wie ich das am besten angehe bei einem Ereignis (WordPress Sicherheitsupdates) dass nur alle heiligen Zeiten auftritt.

Tipps?

Eher nicht bei fast 2.000 Besucher am Tag... ;-)

Außerdem genügt für das Auslösen des Triggers ja nur ein einziger Besuch indem man z.B. selbst mal die Seite ansurft...

Trotzdem Danke für die Antwort.

Sorry, für die späte Rückmeldung. Habe die Antwort nicht mitbekommen. In der wp-config.php stehen die Standardvorgaben von Wordpress und ja ein Cache Plugin ist installiert und zwar WP Fastet Cache. Das kann es aber nicht sein, denn am gleichen Server gibt es zwei andere Wordpress Installationen mit exakt der gleichen Konfiguration, bei denen das Update ohne Probleme funktioniert.

Mir wäre es am liebsten wenn ich das Problem irgendwie tracken/debuggen/loggen könnte... Aber anderseits komme ich ja zum Schluss (siehe oben), dass das Autoupdate eigentlich funktioniert, es nur aus irgend einem Grund nicht getriggert wird. Vielleicht irgend welche alten DB Einträge, da besagt Installation zwar auf dem neuesten Stand ist aber die Website schon über 10 Jahre alt ist (immer wieder upgedatet).

zu wp-config.php:
Ich meinte damit dass ich keine zusätzliche Angaben zu den Out of the Box Angaben in der wp-config gemacht habe. Aber du hast recht, am besten ich poste den Inhalt, ist verständlicher:

define('DB_NAME', 'xxxxxxxxxxxxxxxxxxxx');
define('DB_USER', 'xxxxxxxxxxxxxxxxxxxx');
define('DB_PASSWORD', 'xxxxxxxxxxxxxxxxxxxx');
define('DB_HOST', 'xxxxxxxxxxxxxxxxxxxx');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');






define('AUTH_KEY',         'xxxxxxxxxxxxxxxxxxxx');
define('SECURE_AUTH_KEY',  'xxxxxxxxxxxxxxxxxxxx');
define('LOGGED_IN_KEY',    'xxxxxxxxxxxxxxxxxxxx');
define('NONCE_KEY',        'xxxxxxxxxxxxxxxxxxxx');
define('AUTH_SALT',        'xxxxxxxxxxxxxxxxxxxx');
define('SECURE_AUTH_SALT', 'xxxxxxxxxxxxxxxxxxxx');
define('LOGGED_IN_SALT',   'xxxxxxxxxxxxxxxxxxxx^');
define('NONCE_SALT',       'xxxxxxxxxxxxxxxxxxxx');




$table_prefix  = 'wp_';


if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');




require_once(ABSPATH . 'wp-settings.php');

Das ist exakt was drin steht. Ich habe nur die Kommentare entfernt und die individuellen Angaben mit xxxx ersetzt.

Zum Cache Plugin:

Zitat

Das weiss man erst, wenn man es deaktiviert.

Da hast du auch Recht. Nur will ich nicht unbedingt das Cache Plugin oder andere Plugins deaktivieren und auf das nächste Autoupdate warten und somit ohne Cache Plugin /andere Plugins bis zum nächsten Autoupdate dastehen. Darum habe ich - wie oben beschrieben - das Autoupdate manuell getriggert. In dem Fall funktioniert alles. darum denke ich, es liegt irgendwie daran, dass der Wordpress Pseudo Cron aus irgend einem Grund das Autoupdate nicht anstoßt...

Was sein kann, dass irgendwelche nicht mehr existierende Plugins in der DB Rückstände hinterlassen haben (die Website ist > 10 Jahre), die was blockieren. Ich frage mich ob der Wordpress Pseudo Cron in Zusammenhang mit dem Autoupdate irgendwelche DB Einträge macht/nutzt die ich kontrollieren solle....

Da fällt mir nun ein ich könnte mal ein Cron Plugin installieren und mal schauen ob notwendige Crons existieren....

WP Control installiert.

Aha, das Plugin WP Control zeigt unter Cron Ereignisse zwar das Ereignis wp_version_check 2x täglich an aber da steht auch eine Fehlermeldung:

Ein Problem trat während des Aufrufs des WP-Cron-Systems auf deiner Website auf. Dies bedeutet, dass WP-Cron-Ereignisse auf deiner Website nicht funktionieren. Das Problem war:
cURL error 35: SSL received a record that exceeded the maximum permissible length.

Das schaut mir nun schon nach einer möglichen Ursache aus. Fragt sich nun von wo her der "Record" kommt der Probleme macht...

Auf jeden Fall bin ich nun schon ein stück weiter....

Habe nun das hier in der wp-config.php eingefügt:

define('ALTERNATE_WP_CRON', true);

Aufgrund von: https://wordpress.org/support/topic/…working-in-282/

Der Fehler in WP Crontrol ist verschwunden. Nun bin ich gespannt ob das nächste Autoupdate funktionieren wird....

Danke, ich frage diesbzgl. mal meinen Hoster. Der ist diesbzgl. hoffentlich etwas besser drauf...

Mein Hoster konnte dem Problem auf die Spur kommen:
Es waren falsche bzw. veraltete Einträge in der etc/hosts enthalten. Wahrscheinlich durch frühere Einstellungen über Plesk verusacht. Die etc/hosts wurde auf Standardauslieferung des Hosters zurück gesetzt, nun passt es :-)