Gyakori PrestaShop hibák és javításaik

A Prestashop felépítéséből adódóan vannak vissza-visszatérő hibák amelyek jellemzők a motorra, és ha a környezet adott akkor meg is mutatják magukat.

Ezekből kívánok összeállítani egy általános listát segítségül hívva a Magyar Prestashop Facebook Csoportban és a Prestashop.Com fórumban szerzett tapasztalataimat.

Első és legfontosabb: szinte mindegyik hibajelenség felismeréséhez és megszüntetéséhez szükségünk lesz a developer módra, melyről ITT írtam korábban.

• • “suhosin.post.max_vars/suhosin.request.max_vars” vagy gyakrabban: “max_input_vars” probléma a fordításoknál
    

    

    

    “A szolgáltatód a Suhosin PHP javítást használja, ami korlátozza az űrlapon belüli mezők számát 1000 suhosin.post.max_vars., 1000 suhosin.request.max_vars.”

    A fent említett kétféle (illetve 3) hibaüzenet a szóban forgó változók értékeiről beszélnek a szerverbeállításokat definiáló “php.ini” fájlban a szerveren.
    A legtöbb osztott tárhelyes megoldásnál nincs beleszólásunk, a szolgáltatótól kell segítséget kérni ez ügyben. Le kell írni a hibaüzenetet és kérni őket, hogy emeljék meg xy értékre.
    Ezt vagy megteszik, vagy nem – legtöbb helyen igen, de ha mégsem akkor gondolkozzunk el a szolgáltatóváltáson. Ha már itt elcsúszik az együttműködés akkor később problémákra lehet számítani.

    Alternatívák, más megoldások melyek egyes szolgáltatóknál/szervereknél (beállítástól függően) működhetnek:

    – A legtöbb mai szolgáltató ad adminisztrációs felületet a tárhely kezelésére (CPANEL, PLESK stb). Ezeknél szokott lenni “php.ini” beállítás, ahol legtöbbször definiálni tudjuk a fenti változók értékét tetszés szerint.

    – Egyes szolgáltatók engedélyezik a saját php.ini fájl használatát a szerveren. Ebben az esetben (vagy kipróbálási jelleggel) töltsd le ezt a php.ini-t, tedd bele az admin könyvtárad gyökerébe FTP-n keresztül és nézd meg, hogy megoldotta-e a problémát.

    – HTACCESS-es megoldás: szintén ugyanaz vonatkozik erre, mint az előzőre: egyes szolgáltatók engedélyezik, hogy ekképp befolyásold ezt az értéket. Nyisd meg a gyökérkönyvtárban lévő “.htaccess” fájlt, és a végére biggyeszd be: “php_value max_input_vars 10000“. Ezek után próba.

    – Az indexes megoldás: nyisd meg a gyökérkönyvtáradban lévő “index.php“-t, és illeszd be az elejére: “ini_set('max_input_vars', 10000);” vagy:
    “ini_set('suhosin.post.max_vars', 10000);
ini_set('suhosin.request.max_vars', 10000);”
    természetesen attól függően, hogy melyikre van szükséged.

    – Ellenőrzés: a legbiztosabb forrás, ha a próbálkozások után egy phpinfo()-val kérdezed le a szerver aktuális beállításait. Ezt a fájlt letöltheted INNEN is. Töltsd fel a gyökérkönyvtáradba, majd hívd meg a böngészőből (http://valami.hu/phpinfo.php). Miután betöltött, a rengeteg érték között keress rá (CTRL + F) a “max_input_vars“-ra vagy a suhosin.post.max_vars/suhosin.request.max_vars-ra attól függően, melyiket akartad állítani.

  • Nem látni a kódban történt változásokat

    Prestashop telepítése után a cache/gyorsítótár beállításai bekapcsolt állapotban maradnak, ez okozza legtöbb esetben a gondot. Ellenőrizd ezeket a pontokat:
    Admin => Advanced Parameters => Performance/Teljesítmény:

    

    A “Gyorsítótár” legyen kikapcsolt állapotban. Ez után a jobb felső sarokban lévő “Gyorsítótár ürítése” gombra kattintva dobd ki a felesleges cache fájlokat. Extrém helyzetben szükség lehet ezeken felül a saját böngésződben is törölni a cache-t (előzményeket): ezt a CTRL + SHIFT + DEL billentyűkombinációval tudod megtenni. Minden időszak legyen kijelölve!
    Ha vannak elmentett jelszavaid akkor azokat ne pipáld be, mert törli a rendszer.

  • class_index.php

    Ha esetleg költözés után, új controller/class törlése vagy felvétele után, esetleg csak “úgy” elhasal a shop látszólag ok nélkül akkor érdemes megtekinteni a “/cache/class_index.php” fájlt. Ez a php tartalmazza a controller-eket és class-okat. Ha ez a fájl megsérül, vagy rosszul építődik fel, akkor a hiányzó/rossz php-k miatt nem fog betöltődni a shop.

    Megoldásként egyszerűen nevezzük át a fájlt (teszem azt “class_indexE.php“-re, jelezvén, hogy az az eredeti), hogy legyen mentésünk. Ha ez kész, frissítsünk rá a shopra: a motor érzékeli, hogy nincs “class_index.php” fájl és a meglévő controller-ekből és class-okból létrehozza az újat, ami jó eséllyel megoldja a problémát.

    1.7 alatt: /app/cache/prod/class_index.php/ és /app/cache/dev/class_index.php => Itt annyi is tökéletesen elég, ha az /app/cache/prod és dev mappát kitörlöd vagy átnevezed: prodE, devE, és így a shop legenerálja őket újra, helyesen

    1.7.4.x alatt: úgy néz ki megint átrakták máshová: /var/cache/dev és prod. Ugyanazt tegyük velük: törlés vagy átnevezés.

• Modul módosítás után nem látszik változás a front részen

  Gyakran előfordul egy-egy modul .tpl-beli, .css-beli vagy .js-beli változtatása után, hogy a módosítás nem látszik a bolt front részén. Ennek legtöbbször az az oka (természetesen a cache ellenőrzése után), hogy a gyökérbeli /modules/ könyvtárat használjuk, nem pedig azt a /modules/ könyvtárat ami a használatban lévő téma könyvtárában van: /themes/hasznaltsablon/modules/… .

  Miért van két különböző helyen látszólag ugyanaz? A válasz egyszerű: számos sablon kinézetét és működését nem csak .css szinten szükséges átírni. Példának okáért létrehozok egy zöld, szögletes szegélyű templatet amibe formailag nem illik bele a keresőmodul (blocksearch) “keresés” gombja, így ki akarom venni.

  Ebben az esetben .tpl fájlba is bele kell nyúlnom annak érdekében, hogy úgy nézzen ki és úgy működjön a sablonom ahogyan én azt megálmodtam. Ennek tükrében tehát a témán belüli /modules/ könyvtárban helyezem el a módosított keresőmodul .tpl fájlját, így nem lesz gond a későbbiekben az esetleges sablonváltással (mivel az eredeti helyén, a gyökérbeli /modules/ könyvtárban lévő .tpl-t nem bántottam).