Vorschau von Entwürfen funktioniert nur sporatisch...

Hallo liebe Community,

ich habe leider ein mittelschweres Problem mit unserer Wordpress Seite.

Und zwar, meine Kollegen aus dem SEO Bereich schreiben regelmäßig neue Artikel (Seiten), welche bei der Erstellung als Entwurf angelegt werden. Diese sollen erst veröffentlicht werden, wenn der Artikel fertig ist, ich denke das ist so weit auch nachvollziehbar.

Jedoch zeigt sich seit geraumer Zeit (leider habe ich dazu keine verbindlichen Informationen bekommen, ab wann genau der Fehler auftrat) ein merkwürdiges Phänomen. Die Artikel werden angelegt, wie oben beschrieben. Meine Kollegen schreiben halt je nachdem, wie Sie Zeit finden an einem solchen Artikel weiter. Jedoch funktioniert nach einer gewissen Anzahl von Speichervorgängen die Vorschau dieser Artikel nicht mehr, es wird dann praktisch irgend ein letzter Stand des Entwurfs angezeigt.

Daraufhin habe ich mich der Problematik angenommen und Recherche zu diesem Problem betrieben. Im Netz fand ich allerlei Ansätze, welch in Richtung Browser Cache löschen, Plugins deaktivieren (Inkompatibilität als Ursache), Server Konfiguration prüfen etc. gingen. Ich habe alles fein durchgeführt, das Problem bestand immer noch. Also bin ich tiefer ins System vorgedrungen und habe mich angeschaut, wie Wordpress solche Entwürfe in der Datenbank speichern.

Fakt ist, wird eine Seite als Entwurf gespeichert werden beim ersten Speichervorgang zwei Datensätze angelegt. Siehe folgendes Bild (siehe unten).

Der erste wird beim veröffentlichen des Entwurfs angezeigt, der zweite Datensatz ist der Entwurf selbst. Soweit alles logisch. Nun habe ich weiter den Entwurf (im Backend) bearbeitet und fleißig gespeichert. Nach dem 4 bis 5 mal (kann auch durchaus erst beim 10 Speichervorgang auftreten) speichern, tritt nun wieder das Problem auf, das nicht der letzte Entwurf aktuell angezeigt wird, sondern ein vorheriger Stand.

Genau an dem Punkt habe ich die Daten zum Entwurf geprüft und siehe da, es werden keine neuen Datensätze erzeugt. Für jeden erfolgreichen gespeicherten Entwurf legt Wordpress einen solchen Datensatz an. Angenommen ich haben den Entwurf 5 mal erfolgreich speichern können, dann habe ich 6 Datensätze.
Einen vom Typ page mit dem status draft und 5 weitere vom Typ draft mit dem Status inherit.

Tritt nun dieses Problem auf, dann werden keine neuen Datensätze vom Typ draft erzeugt, nur der eigentliche Datensatz vom Typ page wird aktualisiert! Damit ist mir nun auch klar, wieso diese Vorschau nur den zuletzt erfolgreich gespeicherten Draft anzeigen kann.

Ich bin selbst Webentwickler und kenne mich daher mit der Materie aus (bin jedoch noch Junior Entwickler), genau dieses Verhalten von Wordpress ist sicherlich nicht gewollt, das es das Revisions Prinzip untermauert. Kennt jemand das Problem, oder gar eine Lösung?

Es ist ja auch nicht so, das bei einem nicht erfolgreichen Speichervorgang der Benutzer eine Fehlermeldung bekommt, nichts dergleichen passiert. Ich habe meine Untersuchung was die Datensätze betrifft an mehreren Seiten in diesem Projekt getestet und meine Interpretation ist korrekt! Wieso also, kann unser Wordpress ab einen gewissen Punkt, keine Draftdatensätze mehr schreiben?

Mein aktueller Ansatz sieht so aus, wenn die Vorschau der Entwürfe nicht mehr funktioniert, dann lösche ich zum beispiel (angenommen es existieren 5 Draft DS) die erste drei Datensätze und dann funktioniert auch wieder das Abspeichern und die Vorschau. Oder, man veröffentlich den Entwurf (so verwendet Wordpress den Datensatz vom Typ page mit status publish also nicht die Draft DS) und betrachtet dann den Artikel in der Vorschau. Das alles ist natürlich suboptimal, da es ein offensichtlicher Bug unseres Systems ist.

Wir nutzen Wordpress 4.4.1 und mit Enfolg Theme 3.4.7. Also beides ist aktuelle, das betrifft auch den Rest der Plugins etc. Wobei ich nicht glaube, das diese dafür der Grund sind.

<?php
/** 
 * The base configurations of the WordPress.
 *
 * This file has the following configurations: MySQL settings, Table Prefix,
 * Secret Keys, and ABSPATH. You can find more information by visiting
 * {@link https://codex.wordpress.org/Editing_wp-config.php Editing wp-config.php}
 * Codex page. You can get the MySQL settings from your web host.
 *
 * This file is used by the wp-config.php creation script during the
 * installation. You don't have to use the web site, you can just copy this file
 * to "wp-config.php" and fill in the values.
 *
 * @package WordPress
 */


// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', '');


/** MySQL database username */
define('DB_USER', '');


/** MySQL database password */
define('DB_PASSWORD', '');


/** MySQL hostname */
define('DB_HOST', 'localhost:3306');


/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');


/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');


/**#@+
 * Authentication Unique Keys and Salts.
 *
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
 * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
 *
 * @since 2.6.0
 */
define('AUTH_KEY',       '');
define('SECURE_AUTH_KEY',       '');
define('LOGGED_IN_KEY',       '');
define('NONCE_KEY',       '');
define('AUTH_SALT',       '');
define('SECURE_AUTH_SALT',       '');
define('LOGGED_IN_SALT',       '');
define('NONCE_SALT',       '');
/**#@-*/


/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each a unique
 * prefix. Only numbers, letters, and underscores please!
 */
$table_prefix = 'präfix eben_';


/**
 * For developers: WordPress debugging mode.
 *
 * Change this to true to enable the display of notices during development.
 * It is strongly recommended that plugin and theme developers use WP_DEBUG
 * in their development environments.
 */
 
 // Enable WP_DEBUG mode
define( 'WP_DEBUG', true );


// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );


// Disable display of errors and warnings 
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );


// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
define( 'SCRIPT_DEBUG', false );


// DB Querys speichern 
define( 'SAVEQUERIES', false );




/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');




/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');


/**
 * WordPress Localized Language, defaults to English.
 *
 * Change this to localize WordPress.  A corresponding MO file for the chosen
 * language must be installed to wp-content/languages. For example, install
 * de.mo to wp-content/languages and set WPLANG to 'de' to enable German
 * language support.
 */
// define ('WPLANG', 'de_DE');    // wirft einen Fehler im Debug Modus, wäre dann hier doppelt definiert!!!
define( 'WP_ALLOW_MULTISITE', false );
// define ('FS_METHOD', 'direct'); // nur bei Update Fehlern aktivieren


//--- disable auto upgrade
define( 'AUTOMATIC_UPDATER_DISABLED', true );


?>

Plugins:
Antispam Bee Version: 2.6.8
CBX Feedback Version: 3.7.2
Contact Form 7 Version: 4.3.1
Query Monitor Version: 2.8.1
SI CAPTCHA Anti-Spam Version: 2.7.7.5
Wordfence Security Version: 6.0.22
Yoast SEO Version: 3.0.7
WP Multibyte Patch Version 2.5 (inaktiv)

PHP Version 5.6

An das mySQL Error Log komme ich aktuell leider nicht ran, ich versuche dies Morgen nach zu liefern.

Heute habe ich mich wieder der Thematik gewidmet, ich hatte leider Null Erfolg.

Mein heutiger Ansatz sah wie folgt aus, ich habe unter folgender URL (https://de.wordpress.org/plugins/tags/revisions)
so ziemlich jedes Plugin getestet (welches zu WP 4.4.1 kompatibel ist), damit meine Kollegen ohne SQL Querys die Drafts löschen können. Für mich ist das ja
kein Problem, aber für meine Kollegen ohne SQL Wissen praktisch so nicht machbar. Daher dachte ich mir, diesen Job könnte ja
auch eines dieser Plugins lösen. Die Drafts löschen mit zum Beispiel Revisions Control ( fand ich vom Handling her sehr intuitiv ) war ja kein Problem,
leider heißt das noch lange nicht, das Wordpress zuverlässig nach dem Löschen der Drafts wieder neue Datensätze anlegt.

Ist es möglich, dass dies auch an irgend einer Server Konfiguration z.B. query_cache_size liegen kann?

Der Wert für Query cache Size irritiert mich etwas!?
Warum ist der Query Cache aktiviert, obwohl er offensichtlich mit dem Wert 0 konfiguriert wurde!?