Visual Composer: Caching-Probleme mit dem Post Grid

Man kann über den Visual Composer schimpfen wie man mag. Es ist aber Realität, dass dieses Plugin auf vielen Websites eingesetzt wird. Bei einem Kunden bin ich nun auf ein interessantes Problem gestoßen, dass die Funktionsweise des Visual Composer Post Grid in Zusammenhang mit Caching-Plugins beeinflusst.

Die Grid-Elemente des Visual Composer

Der Visual Composer bietet vier Typen von Grids an: das Post Grid, das Post Masonry Grid, das Media Grid und das Media Masonry Grid. Damit können Medienelemente (vornehmlich Bilder) oder auch Beiträge in einem Grid (Raster) dargestellt werden. Dies wird häufig für Portfolios, Produktübersichten und Galerien genutzt. Der Visual Composer basiert auf diversen Shortcodes. Für die genannten Grids sind das die folgenden: [[vc_basic_grid]], [[vc_media_grid]], [[vc_masonry_grid]], [[vc_masonry_media_grid]].

Ein Beispiel für ein Grid des Visual Composers. Quelle: Website Visual Composer

Ein Problem stellt sich bei der Nutzung dieser vier Grid-Elemente in Zusammenhang mit Caching-Plugins, denn damit funktioniert nach einer gewissen Zeit das Nachladen der Grid- und Bilddaten per AJAX nicht mehr. Nachdem das Problem bei einem Kunden auftrat, bin ich auf die Suche gegangen und dokumentiere hiermit meine Ergebnisse.

Ich hatte die Probleme mit dem Plugin WP Fastest Cache, einen Hinweis auf ähnliche Probleme habe ich auch beim Plugin Comet Cache gefunden. Grundsätzlich können aber alle anderen Caching-Plugins das Problem auch haben. Es sei denn, sie haben eine spezielle Lösung für den Visual Composer bereits integriert (siehe unten).

Funktionsweise der Grid-Elemente

Alle VC-Grids arbeiten nach demselben Prinzip. Es wird minimaler HTML-Code in die Seite geschrieben, in diesem Fall ein einzelnes Container-Element (den sehr langen Settings-String habe ich in diesem Beispiel entfernt):


<div class="vc_grid-container vc_clearfix wpb_content_element vc_masonry_media_grid" data-initial-loading-animation="none" data-vc-grid-settings="{...}" data-vc-request="https://website-url/wp-admin/admin-ajax.php" data-vc-post-id="30" data-vc-public-nonce="5e08e09940">
</div>

Die eigentlichen Daten werden dann per AJAX nachgeladen.

Caching-Probleme

Die Caching-Probleme entstehen aufgrund der Nachlade-Technik der Grids. Damit die AJAX-Requests sicher ausgeführt werden können, hat WordPress Nonces eingeführt. So ausgeführte Requests haben nur eine bestimmte Gültigkeit. Ist das Nonce abgelaufen, liefert der Request kein (sinnvolles) Ergebnis mehr.

Die Probleme der Composer-Grids basieren nun genau auf diesen Nonces. Die HTML-Seite wird gecached und enthält im Container-Element ein Nonce (siehe Code Beispiel oben „data-vc-public-nonce„). Wird diese gecachte Seite aufgerufen, nachdem das Nonce ungültig ist, schlägt der nachfolgende AJAX-Request fehl und die anzuzeigenden Grid-Elemente können nicht mehr geladen werden.

Nun ist der Visual Composer nicht das einzige Plugin in WordPress, welches Nonces nutzt. Somit müssten ja alle diese Plugins nicht mit Caching zusammenarbeiten. Allerdings ist es so, dass es für Nonces in Formularen einen Quasi-Standard gibt. Wird ein Nonce in einem Formular genutzt, so wird standardmässig ein Feld mit dem Namen „_wpnonce“ erzeugt. Viele Caching-Plugins prüfen, ob eine HTML-Seite diese Bezeichnung enthält. Falls ja, wird die Seite nicht gecached.

Diese Methode scheitert beim Visual Composer Grid, da das Nonce als data-Attribut am Container-Element definiert wird und damit nicht standardkomform ist.

Workaround für Caching mit Visual Composer Grids

Ein Nonce ist immer nur eine begrenzte Zeit gültig. Ist die Seite gecached, die gecachten Daten aber noch nicht so alt, funktioniert auch der gecachte Nonce ganz vorzüglich. Erst wenn der Nonce abgelaufen ist (üblicherweise nach einem Tag), schlagen die AJAX-Requests aufgrund eines ungültigen Nonces fehl.

Damit ist der Workaround (Lösung möchte ich es nicht nennen) überraschend einfach. Wenn man den Cache regelmäßig löscht und neu aufbaut, werden die darin gecachten Nonces niemals ungültig. Da Nonces einen Tag gültig sind, bietet es sich an, den Cache häufiger als einmal am Tag zu löschen. Ich habe mich für einen 12-Stunden-Rhythmus entschieden.

Der Workaround besteht darin, den Cache einfach zweimal täglich zu löschen und neu aufzubauen. So werden die gecachten Nonces nie ungültig.

Zu wünschen wäre es, wenn auch der Visual Composer den Standardweg mit „_wpnonce“ nutzen würde, dann würden die Caching-Plugins dies besser handhaben können.

Fazit

Der Workaround mit häufigerem Neuaufbau des Caches ist einfacher als es die Suche nach der Ursache dieses Problems war. Eine Seite, die erst nach einem Tag anfängt, Teile ihrer Inhalte nicht mehr zu laden, ist auch nicht einfach zu debuggen.

Quellen:


Über Marc Nilius

Diplom-Informatiker, 20 Jahre IT- und Web-Erfahrung, 5 Jahre intensive WordPress-Erfahrung, Mit-Organisator WordPress Meetup Köln und WordCamp Köln 2016, Wapuu-Fan

3 Kommentare:

  1. Hallo Marc,
    ein ähnlicher Fehler hat mich auch auf deine Site gebracht, besten Dank für deinen Beitrag.
    Ich habe Comet Cache installiert und musste feststellen, dass das Plugin Post-Hit-Counter nur noch 10% der Hits zählt. Die Cache werden automatisch gelöscht, dies ist im Comet Cache-Plugin integriert, bzw. diese Funktion ist „immer an“. Falls ich einen Beitrag/Seite editiere (oder lösche), löscht Comet Cache die mit diesem Inhalt verbundenen Cache-Datei(en) automatisch. Auf diesem Weg wird automatisch eine neue aktuellere Version des Caches erstellt, wenn das nächste mal auf diesen Inhalt zugegriffen wird.
    Das Plugin Post-Hit-Counter gefällt mir sehr gut und lief immer einwandfrei, wird aber leider nicht mehr upgedatet.
    Hast Du vielleicht eine Idee woran es liegen könnte oder kennst ein Plugin ähnlich wie Post-Hit-Counter?
    Danke für Deine Bemühungen und ein schönes Wochenende.

    Mit freundlichen Grüßen
    I

    1. Da die Seiten aus dem Cache angezeigt werden und nicht bei jedem Aufruf neu generiert werden, kann der Post Hit Counter da keine korrekten Werte liefern. Ich schlage dir vor da auf Plugins wie Statify oder direkt auf externe Analysetools wie Google Analytics oder Piwik umzusteigen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.