WordPress şi istorii ale modificărilor


Acest articol (mai puţin partea lui de final) va fi foarte plictisitor pentru cei care nu sunt interesaţi de scrierea de pluginuri, ori chiar deloc de WordPress. Pentru categoria subţirică a celor ce scriu pluginuri WP, pentru ei sau pentru comunitate, aş dori să evidenţiez două resurse preţioase. Ambele sunt cumva de natură istorică. Iar WordPress are o vechime suficientă pentru a vorbi de o istorie… Şi de ce ne-ar interesa ea? Din pespectiva lui Ozh, care a realizat WordPress Functions Implementation History, pentru a şti când s-a introdus ce facilitate în WordPress. Din păcate proiectul nu este adus la zi (acum 2.6), dar oferă oricum informaţii interesante mai ales dacă se doreşte realizarea unei compatibilităţi cu versiuni mai vechi.

img129

O treabă mai temeinică o face Adam cu WordPress Hooks Database. Acoperind o plajă mai largă (şi până la 2.6) de versiuni, această "bază de date" indexează modificările esenţiale pentru cei care scriu pluginuri, respectiv ce s-a scos şi ce s-a adăugat. Unul din coşmarurile autorilor de pluginuri este dat de dispariţia unor funcţii pe care s-au bazat să zicem în WP 2.3 ca în WP 2.5 să se trezească fără ele. Din fericire WordPress nu evoluează abrupt, astfel că de regulă funcţiile ce se doresc a fi "omorâte" stau o vreme sub titlul de depreciate/învechite, cel puţin câteva versiuni minore dacă nu şi majore, timp în care autorii de plugin trebuie să se replieze după noile condiţii. Dar iniţiativa lui Adam mai este utilă dintr-un punct de vedere: oferă acces (mai elegant, dat fiind că la urma urmelor oricine îşi poate descărca pachetul WP şi săpa prin surse) la funcţiile chiar şi nedocumentate. Astfel, dacă ele nu apar în Codex pot fi găsite aici şi de regulă parametrii lor sunt comentaţi, mai explicit sau nu.

img130

Uh, v-am plictisit, nu? Dacă folosiţi WordPress şi v-aţi chinuit să rezistaţi eroic până în acest punct mă întorc puţin la problema copiilor de articole, pentru cei mai mulţi inutile, pe care le face WP de la 2.6 încoace. (În paranteză fie spus, a apărut 2.6.1, cei mai mulţi ştiu deja. Nu e o versiune care să ceară upgrade obligatoriu, deci dacă nu vă deranjează funcţionarea actuală puteţi rămâne cu ea.) Am spus într-un articol anterior că putem scăpa de revisions cu următoarea linie în wp-config.php.

define(’WP_POST_REVISIONS’, false);

Dacă nu vă simţiţi confortabil cu editarea de fişiere PHP (curaj… aici e vorba de a opera cu Notepad-ul!) atunci puteţi folosi un plugin precum No Revisions. Autorul acestui plugin foloseşte o singură linie de cod pentru a face această operaţiune de dezactivare:

remove_action("pre_post_update","wp_save_post_revision");

Dar… rămâne un dar… cum scăpăm de versiunile create până la dezactivare? Aici nu pare încă să fi fost scris un plugin, deşi s-ar putea scrie într-un minut! Trebuie doar rulată o interogare MySQL. Care? Ne-o spune Andrei Neculau aici.

DELETE a,b,c  
FROM wp_posts a  
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)  
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)  
WHERE a.post_type = 'revision' 

PS: Inutil de spus – faceţi un back-up la baza de date înainte de a rula interogarea.


Apreciază articolul:

1 stea2 stea3 stea4 stea5 stea (Neevaluat încă)
Loading...Loading...

4 comentarii

  1. cristi spune:

    Buna!
    Incep prin ati multumi pt acest articol. Eu cred ca este foarte util pt toti cei care detin un site cu wordpress.
    Am inserat in wp-config.php linia define(’WP_POST_REVISIONS’, false); dar am vazut ca este si un format putin diferit define (‘WP_POST_REVISIONS’, 0); Ambele formate sunt functionale si fac aceeasi treaba, nu?
    Am rulat interogarea mysql din acest articol (din phpmyadmin-baza mea wp- sql) si am primit urmatorul raspuns:

    Not Found
    The server was not able to find the document (./406.shtml) you requested.
    Please check the url and try again. You might also want to report this
    error to your webhost.

    Nu stiu ce n-a mers dar sper ca n-am stricat nimic.Blogul pare a merge bine. Ce fac mai departe.. readuc baza de date ca inainte de interogare.. incerc alta interogare.. sau nu mai fac nimic ? Ms.

  2. radu.capan spune:

    Da, false e interpretat ca zero. Cat priveste eroarea: eu am rulat interogarea MySQL si a mers bine. Nu stiu cum ai rulat interogarea, dar mesajul de raspuns imi suna cam ciudat (la o interogare MySQL nu are sens sa spuna „not able to find the document”). Deduc deci ca de fapt interogarea nu a rulat, datele nu au fost modificate.

  3. cristi spune:

    Am reusit sa rulez interogarea cu succes. Accesarea cpanel este trecuta printr-un proxy si a trebuit doar sa accesez phpmyadmin putin diferit… indrumat de cei care imi gazduiesc blogul. Numai bine!


Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile necesare sunt marcate *