Ausgabe der Custom Post Type verschwindet nach Update auf 4.3.

Hallo Zusammen. Dies ist mein erster Post hier in diesem Forum und ich hoffe auf die Hilfe der Community bei meinem – ehrlich gesagt sehr kuriosem – Problem.

Vielleicht vorab zum besseren Verstehen: Wir sind ein Nachrichtenportal mit Paywall und beliefern mehrere Städte mit Nachrichten. Damit die Redakteure im Backend den Überblick behalten bekommt jede Stadt ihren eigenen Custom Post Type. Um unterschiedliche Rubriken auszugeben, wie zum Beispiel Sport, Kurznachrichten oder Hauptnachrichten bekommen die Custom Post Types Kategorien, damit ich bei der Ausgabe sagen kann: Suche mir einen bestimmten Custom Post Type aus der Datenbank, der die Kategorie XYZ hat.

Nun zu meinem Problem: Vergangenen Donnerstag habe ich das Update 4.3. aufgespielt. Dabei ist wirklich etwas kurioses passiert – also die Seite lief einwandfrei, auch die Artikel inklusive aller Custom Post Types waren weiterhin im Backend sichtbar, aber die Ausgabe der Custom Post Types ist verschwunden. Und dann noch nicht mal komplett sondern nur Partiell, also z.B. alle Hauptnachrichten. Die Sportnachrichten werden weiterhin angezeigt...

Auf jeden Fall war der mega Alarm los und weil ich das Problem nicht sofort ermitteln und somit lösen konnte, musste ich erstmal wieder das komplett Backup vor dem Update auffahren. Dank automatischer SSH Datenbankbackups via Cronjob konnte ich zum Glück relativ gut das richtige Backup wieder herausziehen und neuinstallieren. Das Problem bestand aber trotzdem weiterhin, sodass ich damit ermitteln konnte, dass es wohl irgendwie an der neuen Wordpress Version liegen muss. Also wieder die alte Version aufgespielt und erstmal so belassen. Seitdem geht es auch jetzt erstmal wieder. Aber das kann ja aufgrund von Sicherheitslücken ja nicht die Lösung sein.

Deshalb meine Frage an euch: Wurde mit der neuen Version irgendwelche Query Aufrufe für die Custom Post Types als deprecated eingestuft? Denn ganz verschwunden sind diese nicht, die Aritkel, die nicht ausgegeben wurden waren trotzdem weiterhin per Permalink als Single Article aufrufbar.

Ich danke schon einmal für jeden brauchbaren Kommentar dazu und – ja, zukünftig erstmal lokal updaten und testen bevor man es im Livezustand macht. Lehrgeld muss jeder irgendwie mal zahlen...

Hallo Zusammen, zuerst einmal vielen Dank für die zahlreichen Hinweise. Wir verwenden gar kein Plugin sondern generieren die Custom Post Types "manuell" innerhalb der functions.php, haben uns dabei aber dem Code bedient, den das Plug-In Custom Post Type UI generiert. Hier mal ein Auszug:

Zitat

add_action('init', 'cptui_register_my_cpt_meinestadt');
function cptui_register_my_cpt_meinestadt() {
register_post_type('meinestadt', array(
'label' => 'Meinestadt',
'description' => '',
'public' => true,
'show_ui' => true,
'show_in_menu' => true,
'capability_type' => 'post',
'map_meta_cap' => true,
'hierarchical' => false,
'rewrite' => array('slug' => 'meinestadt', 'with_front' => true),
'query_var' => true,
'menu_position' => '5',
'menu_icon' => '/wp-content/themes/theme/assets/ico/wappen-meinestadt.ico',
'supports' => array('title','editor','excerpt','trackbacks','custom-fields','comments','revisions','thumbnail','author','page-attributes','post-formats'),
'yarpp_support' => true,
'taxonomies' => array('category','post_tag'),
'labels' => array (
'name' => 'Meinestadt',
'singular_name' => 'Meinestadt',
'menu_name' => 'Meinestadt',
'add_new' => 'Neuer Artikel',
'add_new_item' => 'Neuen Artikel hinzufügen',
'edit' => 'Bearbeiten',
'edit_item' => 'Artikel bearbeiten',
'new_item' => 'Neuer Artikel',
'view' => 'Ansehen',
'view_item' => 'Artikel ansehen',
'search_items' => 'Artikel suchen',
'not_found' => 'Keinen Artikel gefunden',
'not_found_in_trash' => 'No Meinestadt Found in Trash',
'parent' => 'Parent Meinestadt',
)
)
);
}

Alles anzeigen

Aufgerufen werden diese auf den Seiten wie folgt:

Zitat

<?php global $wp_query; query_posts( array('post_type' => array( 'meinestadt' ),'showposts' => 1, 'paged' => $paged, 'category__in' => array(17) ) );?>
<?php if (have_posts()) : ?>
<?php while (have_posts()) : the_post(); ?>

Title, Content, etc...

<?php endwhile; ?>
<?php endif; ?>

Alles anzeigen

Ich möchte mich sicherlich nicht davon freisprechen ein wohl konfiguriertes sauberes System zu haben. Deshalb ist jeder freundliche Hinweis sehr förderlich für mich. Zu dem Rest melde ich mich im Laufe des Tages. Ich teste jetzt mal lokal weiter mit dem Debug Modus. Das mit der Datenbankversion ist schon einmal ein guter Hinweis, wir nutzen aber schon MySQL 5.6.19 mit PHP 5.6.0. Also daran dürfte es nicht liegen. Error Logs für MySQL muss ich mal schauen wie ich bei Domainfactory da ran komme... ;) Zur Not repliziere ich das Problem von Donnerstag lokal mit MAMP und lese damit mal den MySQL Error Log.

Also, DEBUG Modus bei Wordpress gibt mehrmals folgende Fehlermeldung aus:

Zitat

Notice: Die verwendete Konstruktoren-Methode für WP_Widget ist seit Version 4.3.0 veraltet! Verwende stattdessen
__construct()[FONT=Verdana]

[/FONT]

[FONT=Verdana]Zu diesem Thema gibt es wohl anscheinend mehrere Topics schon hier, u.a. der hier: http://forum.wpde.org/design/146092-…lermeldung.html[/FONT]

[FONT=Verdana]Aber auch wenn hier eine Fehlermeldung ausgegeben wird – ich habe daraufhin mal alle Plugins deaktiviert, DEBUG Modus an und die CPT werden trotzdem nicht ausgegeben. Es erscheint auch keine Fehlermeldung. Man könnte fast meinen, dass er den post_type "meinestadt" einfach ignoriert...ein Blick in die DB hat auch ergeben, dass in der wp_posts in der Spalte "post_type" auch weiterhin "meinestadt" eingetragen ist. Also nötige Informationen wurden bei der DB Aktualisierung von Wordpress nicht entfernt.[/FONT]

Erstmal danke für deine Antwort. Deine Anmerkung am Ende prüfe ich auch noch einmal. Was ich aber zufälligerweise jetzt entdeckt habe lässt mich noch ratloser zurück.

Mich hat es die ganze Zeit gewurmt, warum im Backend alle Artikel einwandfrei immer noch gespeichert waren, sich aber partout geweigert hat die CPT auszugeben.

Im wordpress.org Forum habe ich den Hinweis bekommen, besser WP_Query() zu verwenden um CPT auszugeben. Um die Parameter dafür richtig einzusetzen war ich im Backend in der Bearbeitung der Kategorien und konnte bei der Parameter URL folgendes entdecken:

Danke für deine Anmerkung. Insbesondere die letzte werde ich noch einmal prüfen müssen.

Was ich aber nun zufälligerweise dank einem Hinweis vom wp.org Forum herausfinden konnte…

Mich hat es die ganze Zeit gewurmt, dass die Artikel im Backend einwandfrei gespeichert waren. Sie waren immer noch sauber mit Inhalt gefüllt, die Artikelthumbnails waren korrekt verknüpft und die Kategorisierung war auch nicht fehlerhaft. Und doch hat er die Ausgabe partout – partiell – verweigert.

Nachdem mir jemand geraten hat, lieber WP_Query() als Ausgabe für CPT zu verwenden bin ich in die Bearbeitung der Kategorien in wp-admin gegangen, um die richtigen Parameter rauszufischen. Bei der Betrachtung der Parameter URL ist mir folgendes aufgefallen:

Vor dem Update:

Zitat

wp-admin/edit-tags.php?action=edit&taxonomy=category&tag_ID=17&post_type=meinestadt

Nach dem Update:

Zitat

wp-admin/edit-tags.php?action=edit&taxonomy=category&tag_ID=3693&post_type= meinestadt

Jetzt meine Preisfrage: warum ändert Wordpress partiell die ID’s der Kategorien? Partiell deshalb, weil es teilweise Kategorien gibt, die ihre alte ID’s behalten haben…

Aus welchen Gründen sollte Wordpress bei einer Datenbankaktualisierung so etwas tun? Wenn es ein Fehler wäre, dann würde ja die Verknüpfung der Artikel im Backend entsprechend der CPT fehlen. Aber er macht es bei der Aktualisierung wohl global in der gesamten DB. Erklärung? Keine Ahnung…

Das kann ich nicht bestätigen aber auch nicht leugnen. Von daher prüfe ich jetzt mal ob ich irgendwo tatsächlich doppelte Bezeichnungen verwendet habe. Aber es muss anscheinend wohl so sein. Komisch, dass dies erst jetzt "Probleme" macht. Danke an dieser Stelle schonmal für die Schützenhilfe! :)