x886
Forum Replies Created
-
… Als weiterer kostenfreier Debugging-Service für Nutzer die hier mitlesen uns die gleichen Probleme haben sei noch hinterhergeschickt: Das Product-Pages-Addon wird zu spät initialisiert. Dadurch werden die Produktseiten im WordPress-Backend nicht mehr korrekt angemeldet beziehungsweise nicht mehr angezeigt. Im Backend funktioniert der Addon-Reiter, jedoch werden weder im Produkteditor die Permalinks angezeigt noch die Produktseiten angezeigt.
Die Ursache sitzt in:
wp-content/plugins/affiliate-toolkit-starter/affiliate-toolkit.php
In der alten Version 3.8.5 wurde die Extension-Initialisierung über plugins_loaded ausgeführt:
add_action( ‘plugins_loaded’, ‘my_atkp_loaded’ );
Darüber wurde dann ausgeführt:
do_action( ‘atkp_initialize_extensions’ );
Damit konnten Addons wie das Product-Pages-Addon ihre Hooks und Filter rechtzeitig registrieren, bevor das Hauptplugin später bei init die Post Types und Taxonomien anmeldet.
In Version 3.8.6 wurde das geändert zu:
add_action( ‘init’, ‘atkp_loaded’, 12 );
Das ist für Addons, die sich vor der Posttype- und Taxonomie-Registrierung einklinken müssen, offenbar zu spät. Denn das Starter-Plugin registriert seine Post Types und Taxonomien bereits vorher bei init mit Priorität 11:
add_action( ‘init’, ‘atkp_init’, 11 );
Innerhalb von atkp_init() wird unter anderem die Produkt-Posttype-/Taxonomie-Logik ausgeführt. Wenn das Product-Pages-Addon seine Hooks aber erst danach über atkp_initialize_extensions registrieren darf, kommt es zu spät. Die relevanten WordPress-Strukturen sind dann bereits durchgelaufen. Ergebnis: Die Produktseiten werden im Backend nicht mehr korrekt angemeldet beziehungsweise angezeigt.
Hotfix:
Datei öffnen:
wp-content/plugins/affiliate-toolkit-starter/affiliate-toolkit.php
Diese Zeile suchen:
add_action( ‘init’, ‘atkp_loaded’, 12 );
und ändern zu:
add_action( ‘plugins_loaded’, ‘atkp_loaded’ );
Danach Backend neu laden und gegebenenfalls Caches leeren. Bei mir ist das Problem dadurch behoben. Die Produktseiten werden danach wieder korrekt bei WordPress angemeldet und im Backend angezeigt.
Ergänzend dazu, weil die Antwort leider am eigentlichen Kern vorbeigeht:
Es wurde nicht kritisiert, dass eine Sicherheitslücke geschlossen wurde. Natürlich muss eine Sicherheitslücke geschlossen werden. Kritisiert wurde die Art, wie diese Änderung eingeführt und kommuniziert wurde.
Wenn eine bisher “erlaubte” und in vielen produktiven Installationen genutzte Template-Funktionalität aus Sicherheitsgründen entfernt wird, dann ist das eine Breaking Change. Mehr als schräg ist daher, dass diese Änderung in den Changenotes mit keinem Wort erwähnt wurde.
Noch besser wäre zusätzlich ein einmaliges Info-Popup oder eine Admin-Notice im WordPress-Dashboard nach dem Update gewesen. Nicht irgendwo versteckt im Template-Untermenü, sondern dort, wo der Betreiber es auch tatsächlich mitbekommt.
Noch sinnvoller wäre ein Template-Scanner gewesen, der vorhandene Templates automatisch auf solche Stellen prüft und konkret auflistet, welche Vorlagen betroffen sind. Dann hätte man die Änderung nachvollziehbar und migrationsfähig eingeführt, statt Betreiber produktiver Seiten erst einmal in eine Fehlersuche laufen zu lassen.
Es ist eben ein Unterschied, ob man eine Sicherheitskorrektur sauber kommuniziert oder ob man eine zentrale Rendering-Änderung einbaut, die bestehende Ausgaben zerlegen kann, und das dann nicht einmal im Changelog erwähnt.
Nebenbei kommt in Version 3.8.6 nach meiner Beobachtung noch ein weiterer Fehler obendrauf: Externe Cronjobs funktionieren zumindest bei mir nicht mehr.
Die Ursache befindet sich in dieser Datei: wp-content/plugins/affiliate-toolkit-starter/affiliate-toolkit-cron.php
Dort steht direkt am Anfang in Zeile 7:
defined(‘ABSPATH’) || exit;
Problematisch, weil affiliate-toolkit-cron.php gerade direkt per externer Cronjob-URL aufgerufen werden soll. Bei einem direkten Aufruf ist WordPress aber noch gar nicht geladen. ABSPATH ist zu diesem Zeitpunkt also nicht definiert. Die Datei beendet sich dadurch sofort, bevor sie überhaupt wp-load.php laden und den Cronjob ausführen kann.
Der Code darunter versucht zwar anschließend noch, WordPress zu laden:
$atkp_default_wp_path = ‘./../../../wp-load.php’;
und später:
require( $atkp_default_wp_path );
Nur wird dieser Teil gar nicht mehr erreicht, weil die Datei vorher durch
defined(‘ABSPATH’) || exit;
beendet wird. Das erklärt, warum der externe Cronjob trotz Aufruf der Cronjob-URL nicht mehr ausgeführt wird.
Hotfix für externe Cronjobs:
Datei öffnen:
wp-content/plugins/affiliate-toolkit-starter/affiliate-toolkit-cron.php
Diese Zeile am Anfang der Datei suchen:
defined(‘ABSPATH’) || exit;
und auskommentieren:
// defined(‘ABSPATH’) || exit;