WordPress est mal codé ! (Créer un compte)

hum wordpress a les droits en écriture sur ton fichier cache ?
je pense que c activé par défaut, mais le problème vien d’un refus du serveur !

Dans config.php, j’ai rajouté (vu je sais plus trop où, mais surement dans le codex) :

define (‘WPLANG’, ‘fr_FR’);
define(‘ENABLE_CACHE’,true);

Salut,

A propos du cache, j’ai jeté un autre coup d’oeil au fichier wp-includes/cache.php
Voilà une tentative d’explication, n’hésitez pas à me corriger si je me plante.
De ce que j’ai compris, il y a 2 niveaux de cache:
– un cache ‘applicatif’
– un cache ‘persistent’

Le cache ‘applicatif’:
Il doit répondre au problème de faire N requêtes SQL pour lire N valeurs d’options.
Le cache fait UNE requête pour lire les N valeurs et les garde en mémoire.
Ce cache ‘applicatif’ devrait être actif sur toutes les installations.
Mais il semble y avoir des subtilités avec les options ‘autoload’ ou non.
Pour le moment, seules les valeurs des ‘catégories’ et des ‘options’ utilisent ce cache.

Le cache ‘persistent’:
Il doit répondre au problème que, même avec un cache ‘applicatif’ activé, si on a 100 visiteurs en 1 minute, on aura quand même 100 requêtes SQL en 1 minute (1 requête SQL par cache ‘applicatif’).
Pour optimiser, le 1er cache ‘applicatif’ fait la requête SQL et utilise alors un fichier pour sauvegarder ses valeurs. Les 99 visiteurs qui suivent utiliseront alors ce fichier (‘cache persistent’) sans passer par la base SQL.

De ce qu’on peut voir dans le constructeur de la classe WP_Object_Cache, le cache ‘persistent’ ne s’active pas sur toutes les plateformes:
– il faut que ENABLE_CACHE soit défini
– il faut que DISABLE_CACHE ne soit pas défini
– il faut que PHP soit en safe_mode off
– il faut bien sûr que le répertoire pour le fichier soit accessible en écriture

Ce serait bien de savoir sur quels hébergeurs le cache ‘persistent’ fonctionne!

Une dernière remarque:
Le cache ‘persistent’ est bien pour un grand nombre de visiteurs. Par contre, le premier visiteur doit créer le fichier cache alors que ça ne lui sert à rien. Donc si vous n’avez pas beaucoup de visites sur votre site, ce n’est pas la peine de créer ce fichier. Le fichier a une durée de validité et au delà, il ne sera pas utilisé.

[c]
function WP_Object_Cache() {
global $blog_id;

if (defined(‘DISABLE_CACHE’))
return;

if ( ! defined(‘ENABLE_CACHE’) )
return;

// Disable the persistent cache if safe_mode is on.
if ( ini_get(‘safe_mode’) && ! defined(‘ENABLE_CACHE’) )
return;

if (defined(‘CACHE_PATH’))
$this->cache_dir = CACHE_PATH;
else
// Using the correct separator eliminates some cache flush errors on Windows
$this->cache_dir = ABSPATH.’wp-content’.DIRECTORY_SEPARATOR.’cache’.DIRECTORY_SEPARATOR;

if (is_writable($this->cache_dir) && is_dir($this->cache_dir)) {
$this->cache_enabled = true;
} else {
if (is_writable(ABSPATH.’wp-content’)) {
$this->cache_enabled = true;
}
}

if (defined(‘CACHE_EXPIRATION_TIME’))
$this->expiration_time = CACHE_EXPIRATION_TIME;

if ( defined(‘WP_SECRET’) )
$this->secret = WP_SECRET;
else
$this->secret = DB_PASSWORD . DB_USER . DB_NAME . DB_HOST . ABSPATH;

$this->blog_id = $this->hash($blog_id);
}

[/c]

Y’a rien à expliquer.

Le cache de WP est utilisé si ton site a une très forte influence.
Au quel cas, un certains nombre de fonction sont mis en cache. Les bloginfo() par exemple.

Et cela à certaines condition serveurs :
– il faut que ENABLE_CACHE soit défini
– il faut que DISABLE_CACHE ne soit pas défini
– il faut que PHP soit en safe_mode off

Dans le PHP.ini

et le dossier wp-content/cache créé et en chmod 077

Pas assez de visite 🙂

10 000 / jour c pas assez ? Pourtant à 50 requetes par page, je trouve qu’un cache aurait son interet 🙂

Pour le XML, pourquoi reinventer la roue : il y a Plumxl … et qui est tres bien pour ton ami : avec en + une admin a la WordPress qui cree les fichiers XML 🙂