Dans un nouveau projet, nous utilisons wp-super-cache (le plugin préféré du client) pour créer les fichiers html statiques pour les types de contenu personnalisés. Mais nous essayons de déterminer si tout est correctement mis en cache.
Il s'agit d'une question en deux parties.
1) Le thème que nous avons créé utilise des modèles de page pour sortir json qui est ingéré via des appels ajax. c'est à dire. si vous accédez à la page: theurl.com/sample - vous obtiendrez du json pur. Bien qu'il existe une version non javascript de chaque page et publication, Ajax pilote le front-end de ce thème. Nous avons supprimé l'en-tête et le pied de page de ces fichiers afin qu'ils soient purement json, et nous essayons de déterminer comment déterminer si le json est mis en cache. En théorie, les données seraient mises en cache car il s'agit techniquement d'une page servie par wordpress. Mais, comment pouvons-nous savoir s'il est mis en cache?
2) Nous utilisons le plugin json api pour servir également certaines données de publication. http://wordpress.org/extend/plugins/json-api/ Pour cet exemple, disons que nous utilisons la méthode de sortie par défaut du plugin et que nous voyons cette page: mon url.com/category/news?json=1 - Est-ce que quelqu'un sait comment nous pouvons vérifier si cette sortie est mise en cache? S'il n'est pas mis en cache, quelle méthode y arriverait-il?
Il ne semble pas y avoir beaucoup d'informations à ce sujet en ligne, donc dans l'esprit de créer des sites wordpress convaincants et optimisés, aidez un frère
WP Super Cache examine les pages de votre site WordPress à la recherche de certaines balises HTML avant de les mettre en cache.
Vos pages n'ont probablement pas de
</html>
balise (problème commun), dans ce cas, essayez d'ajouter quelque chose comme//</html>
- c'est une solution de contournement, et WP Super Cache devrait alors générer des versions mises en cache de vos pages.Pourquoi WP Super Cache le fait-il comme ça? Vous voyez, il n'y a pas de moyen évident de vérifier si une page n'est qu'à moitié chargée, que de vérifier si toutes les balises HTML de base existent et sont fermées correctement.
Selon les propres mots de Donncha (développeur de WP Super Cache) , "c'est pour empêcher la mise en cache des pages à moitié générées."
la source
NOTE DE SÉCURITÉ: Ceci (et les autres solutions) ne doit pas être utilisé sauf si vous avez un moyen de remplacer l'en-
Content-Type: text/html
tête que WP Super Cache envoie avec laapplication/json
valeur appropriée . Envoi de JSON en tant quetext/html
que le navigateur le rendra en HTML, qui pourrait potentiellement être un vecteur XSS.Il semble que cela doit être fait au niveau de la couche serveur, car WPSC ne fournit pas les hooks nécessaires.
C'est comme ça que je l'ai fait. C'est similaire à l'approche de Liang, mais ne nécessite pas de modifier directement le plugin, et a un modèle d'expression régulière plus précis.
Si vous utilisez la v2 de l'API REST, vous devez utiliser à la
REST_REQUEST
place deJSON_REQUEST
.Ce serait bien de s'abonner à 22 et # 79 au cas où quelque chose changerait dans WP Super Cache.
la source
XMLHttpRequest cannot load http://api.mywebsite.com/wp-json/wp/v2/posts. Origin http://mywebsite.com is not allowed by Access-Control-Allow-Origin.
comment puis-je le corriger?Access-Control-Allow-Origin
tête pour autoriser la demande d'origine croisée. Je suppose que les pages en cache ne produisent pas cet en-tête.J'ai aussi rencontré ce problème. J'avais écrit un peu mon code pour être API. Lorsque le type de réponse était XML, le cache fonctionnait. Mais lorsque le type de réponse était json, cela n'a pas fonctionné.
Il me faut quelques heures pour corriger ce bogue.
C'est du travail pour moi.
Mettez simplement à jour votre code comme mes modifications.
Ça marche pour moi maintenant.
la source
wp_cache_eof_tags
filtre au lieu de modifier directement le plugin.