Am creat răspunsuri în forum

Vizualizare 12 răspunsuri - 1 la 12 (din 12 în total)
  • Daca ai fi sters doar din wp-content/cache nu ar fi fost nicio problema. Din pacate, ai sters din /wp-content.

    Cei care iti tin site-ul ar trebui sa aiba un backup al tuturor fisierelor tale, disponibil pentru situatia in care le pica lor echipamentele.

    Oricum, ar trebui sa inveti din asta ca nu ai voie sa te atingi de un site pana cand nu ai o copie completa a tuturor fisierelor si a bazei de date. Dupa ce faci modificarile si inca merge, faci imediat o noua copie, pe care o pastrezi. E bine sa pastrezi ultimele 3 versiuni si orice versiune anoterioara unei schimbari semnificative.

    Forum: Probleme și soluții
    În răspuns la: Diverse probleme WP

    Presupunerea ta pleaca de la premise gresite. Daca folosesti o tema si module (plugin-uri) de tipul „one time development”, adica dupa ce au fost create procesul de dezvoltare a incetat si nu sunt mentinute la zi cu ultima versiune de WP, pe masura ce faci upgrade-uri la WP, fara sa faci la tema si plugin-uri, sansele sa apara incompatibilitati sunt din ce in ce mai mari.

    Ce pot sa-ti spun cu certitudine este ca, din pacate, chiar si dintre temele si modulele „premium” foarte multe sunt „one-time-development”. Este foarte important ca atunci cand decizi ce plugin-uri si ce tema folosesti sa te uiti atent la „Support” si sa vezi cat de bine sunt mentinute.

    Solutia in cazul tau este sa incerci sa descoperi de unde sunt bug-urile (exita unelte de debug-ing pentru WordPress) si sa schimbi tema/plugin-ul care le genereaza cu alta/altul care ofera design/functionalitate similare, dar sunt mentinute la zi.

    In mod cert, daca apelezi la un specialist vei obtine rezultate/sfaturi mai bune desi nimic legat de WordPress nu este secret. Daca ai timpul necesar si inclinatia, te poti documenta singur pentru a lua deciziile cele mai bune.

    • Acest răspuns a fost modificat acum 8 ani, O lună de către acub.

    Tema activa sau unul dintre plugin-urile active sunt incompatibile cu versiunea de WP la care ai upgradat. De principiu, un fix nu este simplu, si ar fi bine ca urmatoarele actiuni sa fie facute de un programator cu experienta.

    Orice ai face, primul lucru este sa faci backup la /wp-content si la baza de date.

    Cel mai simplu fix este, daca ai un backup al fisierelor si al db-ului relativ recent dar anterior upgrade-ului, pur si simplu stergi tot, pui db-ul si fisierele din backup si ar trebui sa mearga.

    Daca nu le ai, e posibil sa aiba cei care iti dau hosting (de regula tin back-up-uri la tot minim o luna in urma, pentru varianta in care le pica vre-un sistem, sa aiba de unde sa faca restore).

    Daca nu reusesti sa gasesti backup-uri sau sunt prea vechi ca sa fie utile si ai nevoie sa faci restore pe ce ai acum, exista doua variante.

    Varianta 1: Downgrade WP.

    Daca stii ce versiune de WP aveai inainte, o poti descarca de aici, stergi folderele /wp-includes si /wp-admin din existent, dupa care copiezi cele doua foldere din WP-ul downloadat. Este foarte important sa nu te atingi de /wp-content. Nu il stergi si nu il rescrii. In afara de cele 2 foldere, trebuie sa iei din WP-ul downloadat si toate fisierele din root, cu exceptia .htaccess si a wp-config-sample.php. Nu ar trebui sa existe un wp-config.php in WP-ul downloadat dar, daca exista, nici pe acela nu-l copiezi, il lasi pe cel vechi. Daca ai facut totul bine si versiunea este cea corecta, ar trebui sa mearga.

    Varianta 2: Upgrade tema si/sau plugins.

    Asta e varianta cea mai grea, dar si cea mai buna. Fac genul acesta de upgrade-uri frecvent insa sarcina de a scrie un ghid mai mult sau mai putin „universal” pentru aceasta operatiune mi se pare aproape imposibila, pentru ca depinde de foarte multi parametri si de natura conflictului. Ce pot sa-ti spun este ca mie, care sunt cotat si platit ca „expert” WordPress, imi ia, de regula, intre 2 si 8 ore o astfel de operatiune.

    404 in admin cand nu esti logat(a) poate fi generat fie printr-un plugin, fie din tema activa. De principiu, daca te loghezi intr-un cont de admin ar trebui sa nu mai dea 404, cu exceptia cazului in care pur si simplu a fost schimbat numele folder-ului de wp-admin (WP poate fi customizat in acest sens si cam toate folderele „clasice” pot fi redenumite).

    Daca esti sigur(a) ca e WordPress si ai acces ftp, poti incerca sa dezactivezi fortat toate plugin-urile, redenumind plugins in _plugins si incercand din nou /wp-admin sau sa dezactivezi fortat tema activa, redenumindu-i folderul.

    Orice schimbare ai face, nu uita sa schimbi la loc dupa ce te loghezi. Ambele schimbari de mai sus vor face site-ul sa dea erori sau sa nu se incarce deloc pentru perioada cat folder-ele sunt redenumite.

    • Acest răspuns a fost modificat acum 8 ani, O lună de către acub.

    Tot scurt si la obiect: poate fi din multe cauze. Cele mai probabile:

    1. Le publici cu o data de publicare ulterioara momentului actual. Asta poate fi din cauza unei proaste configurari a serverului si, desi ele au status-ul „publish”, fiind cu data de publicare ulterioara sunt considerate „future” si nu sunt afisate pe site decat dupa ce trece momentul publicarii, sau…
    2. Folosesti cache. Adica stocare temporara. WordPress, hosting-ul sau chiar browser-ul tau pot salva anumite pagini pentru a le „servi” mai rapid. Si atunci cand primesc un „request” pentru ele, in loc sa-l ceara de la server, servesc copia „de-a gata” din cache. Cum poti goli aceasta stocare temporara sau cum sa o impiedici depinde de ce anume face cache si cum. Sunt prea multe cazuri ca sa stea cineva sa le insire pe toate.

    De cele mai multe ori, cauza acestui simptom nu este usor de depistat si necesita atentia unui programator experimentat.

    Datele de conectare la DB se găsesc în wp-config.php, în directorul root al WordPress. WP nu se poate conecta la DB. Trebuie să modificați constantele DB_NAME, DB_USER, DB_PASSWORD, DB_HOST cu cele corecte.

    Trebuie ca db-ul și userul să existe, user-ul să aibă drepturi asupra db-ului. DB_HOST este de regulă localhost sau 127.0.0.1, cu excepția cazurilor în care provider-ul de hosting cere altceva, caz în care cu siguranță v-a transmis deja această informație dar ați trecut peste ea.

    De fapt, dacă totul pare să fie ok cu setările de mai sus, cu hosting provider-ul puteți rezolva aceasstă problemă, pentru că ați avea-o cu orice ați instala pe server, nu doar cu WordPress.

    • Acest răspuns a fost modificat acum 8 ani, 2 luni de către acub.
    Inițiator fir de discuții acub

    (@acub)

    Ok, mulțumesc.

    Pentru traducerea plugin-ului în sine (nu a readme-ului) am folosit metoda clasică, cu .po file. Dar văd că nu apare automat în translate.wordpress.org, deși traducerile merg în plugin. Presupun că este din cauză că am folosit $this->slug în loc de stringul propriu-zis în load_plugin_textdomain(). Am să schimb, deși e tardiv (am pus deja traducerile și pe translate.wordpress.org, ca să fiu sigur).

    P.S. M-aș fi așteptat să nu am nevoide de nicio aprobare pentru a adăuga traducători la modulele mele (presupun că sunt proiecte și le pot adăuga traducători, în calitate de autor al modulului), dar nu am găsit o astfel de opțiune. Dacă știi să-mi spui unde o găsesc sau ce trebuie să fac ca să o văd, mi-ar fi de folos.

    Încă o dată, mulțumesc.

    Cu placere.

    Nu uita sa schimbi status-ul in „rezolvat”.

    Poti sa-l muti pur si simplu in root.

    Dar varianta cea mai buna ar fi sa-l lasi acolo (e de preferat, nu-ti umple root-ul cu o gramada de foldere si fisiere, in plus iti creste un pic securitatea (nu mult), prin simplul fapt ca marea majoritate a botilor sunt scriptati sa incerce in root, nu se uita daca site-ul e intr-un folder.)

    Cu scriptul de mai jos in .htaccess (plasat in root folder) ar trebui sa mearga, conform documentatiei. Pentru ca nu l-am testat, iti recomand sa salvezi fostul .htaccess si abia apoi sa-l inlocuiesti cu cel de mai jos. Atentie! trebuie sa inlocuiesti example.com de mai jos cu domeniul tau (fara *www*), in ambele locuri:

    
    <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{HTTP_HOST} ^(www.)?example.com$
    RewriteCond %{REQUEST_URI} !^/wp/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ /wp/$1
    RewriteCond %{HTTP_HOST} ^(www.)?example.com$
    RewriteRule ^(/)?$ wp/index.php [L] 
    </IfModule>
    

    Daca nu merge, incearca metoda 2 de la acelasi link.

    • Acest răspuns a fost modificat acum 8 ani, 2 luni de către acub.
    • Acest răspuns a fost modificat acum 8 ani, 2 luni de către acub.

    Regulamentul forumului nu permite adresarea unei intrebari noi in intrebarea altcuiva. Avand insa in vedere ca OP nu s-a gandit sa faca publica solutia care a functionat in cazul sau (adevarul este ca nici nu se afla intr-o comunitate open-source si nici nu beneficiaza de zecile de mii de ore de programare care au intrat in WordPress in mod gratuit, de ce sa contribuie si el?), am sa fac o exceptie si am sa-ti raspund aici:

    Pentru ca WordPress sa interpreteze corect o tema, aceasta trebuie sa indeplineasca cateva conditii:

    1. trebuie ca fisierul style.css sa se afle in directorul temei, si nu intr-un sub-director al acesteia
    2. style.css trebuie sa inceapa cu un comentariu specific, numit „theme header” care sa respecte structura din acest model
    3. doua teme nu pot avea acelasi header (daca ai copiat o tema trebuie sa-i schimbi macar numele ca sa mearga)
    4. daca tema ta este o tema copil, trebuie sa aiba in header, pe rand separat: Template: parent, unde parent este numele directorului temei parinte. Tema copil isi incarca toate fisierele din tema parinte, daca acestea nu exista in tema copil.
      Asta iti da posibilitatea sa copiezi orice fisier din tema parinte in tema copil (pastrand structura directoarelor) si sa efectuezi modificari asupra lor fara sa te atingi de tema parinte (daca ai face modificari in tema parinte s-ar pierde la update).
      Sunt exceptate de la aceasta regula doua fisiere: style.css si functions.php. Astfel, o tema copil minima este o tema copil in care se afla doar style.css cu un header ce contine numele si template-ul. Avantajul folosirii unei teme copil este ca functions.php din tema copil se incarca inaintea temei parinte iar style.css se incarca dupa cel din parinte, si permite CSS override cu selectori identici
    • Acest răspuns a fost modificat acum 8 ani, 2 luni de către acub.
    • Acest răspuns a fost modificat acum 8 ani, 2 luni de către acub.
    • Acest răspuns a fost modificat acum 8 ani, 2 luni de către acub.
    • Acest răspuns a fost modificat acum 8 ani, 2 luni de către acub.

    Am gresit linkul către PS și nu mai pot edita. Este: http://photoswipe.com/

    WP Featherlight pare să fie ceea ce cauți, dacă vrei să meargă fără să modifici nimic la articolele existente. Ar trebui să meargă, dar până nu testezi nu poți știi sigur.

    ___

    Probabil ar trebui să menționez că eu, de când am dat de PhotoSwipe, îl implementez oriunde am nevoie de lightbox și nu există deja unul integrat (multe teme premium au). Însă încă nu am avut nevoie de el pe WordPress.

    Văd că există două module PS pentru WP, iar aceasta pare să aibă „support” activ. Nu știu dacă funcționează fără să fie nevoie să schimbi nimic la articolele existente, trebuie să verifici. La celălalt (care nu pare să fie grozav – support: aproape zero, documentație: firavă) scrie că ar fi nevoie să salvezi articolele vechi o dată pentru ca modulul să se aplice pe galeriile existente (ceea ce e oricum cam suspect – un astfel de plugin nu ar trebui să se atingă de conținutul articolelor, după părerea mea). În funcție de câte articole ai, poate însemna un efort prea mare. Între cele două implementări de PhotoSwipe, la prima vedere, aș alege-o pe prima.

    • Acest răspuns a fost modificat acum 8 ani, 2 luni de către acub.
    • Acest răspuns a fost modificat acum 8 ani, 2 luni de către acub.
    • Acest răspuns a fost modificat acum 8 ani, 2 luni de către acub.
Vizualizare 12 răspunsuri - 1 la 12 (din 12 în total)