Actualizare WordPress si plugin

Am o mica problema cu GravityForms si WordPress. Mai exact, dupa update-ul de WordPress de la 3.5 la 3.9, am facut si update-ul de GravityForms de la 1.7 la 1.8.9. Toate bune si frumoase, pana cand imi da blank page dupa actualizarea pluginului. Crezand ca este din cauza unui conflict. Am incercat toate chestiile obisnuite:

  1. am redenumit folderul cu pluginul.
  2. dezactivat toate pluginurile
  3. Verificat in db daca active_plugins mai contine gravity in tabela cu options
  4. am pus WP_DEBUG si toate constantele WP pentru debugging (log, show, etc)
  5. Adaugat error_reporting(E_ALL) si init_set(‘display_errors’, ‘1’) in fisierul principal al pluginului inainte de cod si dupa info-ul pluginului.
  6. die-uri si echo-uri in fisierul principal al pluginului, inainte de tot codul (yeah, disperat)
  7. Sters tot ce continea transient prin db.

Ce e cu adevarat ciudat e ca pluginul functioneaza pefect daca il redenumesc si il activez. Toate datele din db sunt ok, totul e ok. Atunci cand il redenumesc inapoi revine blank page-ul. Dupa toti pasii de mai sus, tot n-am reusit sa primesc macar un warning, un notice, ceva - doar un blank page care ma innebuneste. Ce e si mai ciudat e ca pluginul reuseste sa strice chiar daca nu e activ (instalat) - verificat la pasul 3.

Dupa ce am incercat pasul 6., singura varianta ar fi ca e ceva praf prin Core, si n-are nicio legatura cu pluginul, pentru ca nu ajunge nici macar sa intre in die().

Any help? E prima data cand mi se intampla sa nu stiu cum sa rezolv anumita chestie atat de banala ca update-ul unui WP si plugin…

Stupid question: Ai verificat syslog-urile si log-urile serverului? DIn DirectAdmin sau Cpanel (sau whatever you’re using)?

Cateodata cele setate din PHP nu sunt afisate toate.

1 Like

N-am acces, oricum ar fi trebuit sa se afiseze in logurile WP (din wp-content) din moment ce celalalte warninguri si error sunt introduse atunci cand pluginul e redenumit.

Pe sistemul There's a plugin for that incearca asta cu flag-ul de WP_DEBUG pe true. Poate ajuta. Poate e o chestiie de permisiuni pe foldere sau poate de query sau poate de htaccess (cu toate ca imi vine cam greu sa cred asta ultima).

2 Likes

Trimite si un ticket la support, poate au mai intalnit situatia asta.

1 Like

@Bogdanu any updates? Ai reusit sa iti dai seama?

E recomandat ca atunci când faci un update major (3.5->3.9 este destul de major!) să dezactivezi toate plugin-urile. Ai făcut asta de la început sau abia după ce ai vazut că nu mai merge?

1 Like

Scuze pentru intarziere, am fost putin obosit si am uitat complet de thread.
Pai asta era problema, facusem update la WP 3.9, dezactivasem toate pluginurile - primul lucru facut :).
@serbanbc am rezolvat, se poate inchide. Glumesc, explic mai jos cum “am rezolvat”.

Problema era din cauza GravityForms cat si a developerului initial a template-ului. Omu’ s-a gandit ca ar fi o idee buna sa adauge o noua functionalitate pluginului in template. Practic, a inclus un script php din template, custom, in functions.php (in template) unde includea gravityforms/export.php, plus cateva conditii care verifica daca exista clasa default a GravityForms, RGGFORM, sau ceva de genul. Daca nu exista, nu se declarau cateva clase custom care extindeau clasa de export - nu de aici dadea blank page, oricum.
Eh, se pare ca in WordPress 3.9 functions.php a template-ului se incarca INAINTEA pluginurilor, spre deosebire de WP 3.5 - de asta a mers pe WP-ul vechi.

Mai sus v-am zis de gravityforms/export.php, care are nevoie de clasa main a pluginului. Cum baietii de la GravityForms sunt niste programatori “talentati”, ei verifica daca exista clasa respectiva si daca nu exista, ii da un die(), pentru ca asa e frumos. Se intampla urmatorul lucru la request: functions.php se executa inaintea pluginului, include scriptul php custom care la randul lui incarca gravityforms/export.php, cum gravityforms/gravityforms.php nu e inca inclus, nu exista clasa default a pluginului si intra pe if-ul cu die().

De asta mergea daca redenumeam folderul gravityforms in altceva si mergea, pentru ca in scriptul custom era o conditie hardcodata pe folderul gravityforms, daca nu exista, nu se includea export.php si nu intra in die()

Asa am stat eu 2 zile sa descopar o eroare care defapt nu e eroare. Cum am gasit-o? Babeste, echo + die, pentru ca nu am acces la serverul de dev sa ma joc cu xdebug. Asa ca am mutat eu fisierul custom intr-un nou plugin si am rezolvat “problema”.

Scuze pentru ditamai reply-ul, dar dupa 2 zile de debugging imi vine sa zbier daca nu explic toata patania. :smiley:

3 Likes

Nu cred că functions.php a fost vreodată executat înaintea plugin-urilor (sigur nu se întâmplă nici acum).

Cel mai probabil gravity folosește un hook care se execută în altă ordine decât crezi/vrei tu :smile:


E cel puțin ciudat cum au preferat să folosească die() în loc de throw