Citazione:
Originalmente inviato da giuseppeiemma
|
Guarda, io non vorrei essere costretta a dover conoscere prima di tutto da cima a fondo il funzionamento dell'intero wordpress per poter capire cos'è che impedisce al plugin di WP Super Cache di fare il suo lavoro.
Ho fatto una provina con un altro plugin (hyper cache) che ha una struttura apparentemente più semplice, trasformando un "ob_start('funzionechiamata()');" in "funzionechiamata();" e aveva iniziato a popolare la cache come doveva fare, il problema è che poi mi sono arenata perché non capivo come fare a "richiamare" il CONTENUTO della pagina da cachare per infilarlo dentro la cache, perché evidentemente si appoggiava a variabili globali definite altrove all'interno di wordpress.
Ora tu mi dici che hai fatto una provina e secondo te le funzioni che hai chiamato sono attive.
Io ho fatto un'altra provina per capire se alcune delle funzioni interne a wordpress fallivano per via di un path assoluto (solitamente richiamato e definito all'interno di wp-config) andato a donnine allegre o no, ma non sembra sia quella la causa.
Di conseguenza il "difetto" deve risiedere da qualche altra parte. probabilmente all'interno di qualche funzione/classe che definisce i vari hooks forniti da WP per chi volesse creare sistemi di caching.
Ergo, sarebbe carino sapere se quelli di altervista hanno effettivamente disabilitato l'accesso a determinate funzioni e, se sì, quali...
(OT: da un phpinfo su php5 vedo che da li' hanno proprio tolto il modulo di mysql
i -- !!!!!!!!! non è che io sia tanto d'accordo, ma tant'è, i server li gestiscono loro
).
P.S.: in estremissima sintesi, per quel che ho capito io, WordPress
NON FA NESSUN CACHING DI SUO, SE NON QUELLO DELLE QUERY PIU' RIPETITIVE, AFFIDANDOSI ALL'APC INTERNO A PHP. PER IL RESTO FORNISCE COMUNQUE DEI HOOKS A CHI VOLESSE SCRIVERE PLUGINS /PEZZI DI CODICE X IL CACHING FISICO. Sempre per quello che ho capito io eh.
basta, per oggi mi sono anche snervata pure troppo con queste cose :(