Szerző: Szűcs Ádám 
Kategória: Hasznos lehet, Videó, WooCommerce webáruház
Tudtad, hogy a WooCommerce tud olyat, hogy a shopban a nettó árakat mutatja, de a kosár oldalon már ÁFÁ-val növelt összeg jelenjen meg?
Mutatom egy kettő perces videón, hogyan:
Szerző: Szűcs Ádám Kategória: Cikk, Ingyenes videók, cikkek, WordPress biztonság
GYORSHÍR!
Megjelent egy fontos frissítés, amely visszamenőleg – a 3.7-es WordPress verzióig – minden verzióban megtalálható sérülékenységet javít. Érdemes tehát frissíteni a szokásos módon.
További részletek:
wordpress.org/news/2018/07/wordpress-4-9-7-security-and-maintenance-release/
Szerző: Szűcs Ádám Kategória: Admin felület, Érdekesség, Videó
Időről-időre szembejön olyan munka, amikor a szó szoros értelmében vett “rabszolgamunkát” kell végeznem. Az olyan munkákat hívom ilyennek, amikor ugyanazt a pár kattintásos feladatot kell adott esetben több százszor elvégeznem, és ezt nem lehet automatizálni, tehát muszáj beletenni az élőerős munkát.
Egy ügyfél hírlevélszoftvert váltott, és kiderült, hogy régen minden cikk (161 cikk volt érintett) végébe manuálisan berakta a hírlevél feliratkozás kódját, és ezt törölni kell, mert az új szoftver kódja már be van illesztve minden cikk végére. Erre van bővítmény, hogy ami egy adott kódot minden cikk végére betesz, ezzel ez meg is lett oldva, de a régi tartalmakból csak manuálisan lehet törölni a régi hírleveles szoftver kódjait. Miért? Mert nem mindenhol ugyanaz a kód van, van hogy máshogy van megtördelve, így pl. egy adatbázisban történő keresés-csere funkcióval az utólagos ellenőrzés miatt nagyobb munkát generálnánk magunknak.
Hogyan lehet a fentiekkel végezni egy óra alatt? Lehetetlen? Nem szeretem ezt a szót, jobban szeretek helyette gondolkozni.
Hihetetlenek a fenti számok?
Megmutatom egy 18,5 perces videón az alapelveket, illetve a konkrét megvalósításból is mutatok részletet. Ha hasonló feladattal fogsz szembenézni, nem fog gondot okozni.
Ui.: Hasonló módszerrel volt már olyan munkám is, amikor 20 percen belül sztornóztam számlázóprogramban 175 db, automatizáltan (és persze tévesen) kiállított számlát.
Szerző: Szűcs Ádám Kategória: Cikk, Érdekesség, Ingyenes videók, cikkek
Készül évről-évre egy felmérés (már 3 éve) a WordPress-t használó közösség körében, amely jó sok hasznos, és kevésbé hasznos kérdésre adja meg választ. Vannak olyan kérdések, amelyekre tízezrek válaszoltak.
Igen, az adatok már fél évesek, de azt hiszem, hogy a trendek, és a válaszok eloszlása szempontjából ez irreleváns információ.
(fejlesztőknek feltett kérdés)
A fejlesztők szerint:
A felhasználók szerint:
Forrás, további adatok:
WordPress User Survey Data for 2015-2017
Szerző: Szűcs Ádám Kategória: Hasznos lehet, Hírek, WordPress biztonság
A vírusírtás alapok című cikkemben körbejártam, hogy mit kell tenni akkor, ha már megtörtént a baj. Azóta (2018. májusában) történt egy olyan eset, amely mellett nem tudok szó nélkül elmenni. Az egyik ügyfelemnek (ráadásul TOP20-as ügyfélről van szó) megfertőzték a weboldalát, de olyan módon, hogy az ékezetes karakterek helyére (mind helyére ugyanaz) kriksz-krakszok kerültek, és azokat hexaeditorral sem lehetett normális módon helyreállítani.
A helyreállítás sokkal könnyebb lehetett volna, ha pár helyen szerencsésebben alakulnak a körülmények. De ahogy a sportban sincs “ha”, úgy itt sem volt sajnos.
Az első és legfontosabb hasonló esetben, hogy AZONNAL jelezni kell azt, ha ilyet tapasztalunk a weboldalon. Sokszor volt már olyan, hogy “azt hittem csak ideiglenes hiba, és megoldódik”. Magától az esetek többségében nem fog megoldódni a probléma, sőt, csak nagyobb bajt okozunk vele. Mint itt is. Amikor az ügyfél jelezte, hogy mi van az oldallal, mondta, hogy már 2-3 hete ilyen az oldal, akkor szóltak neki. Csak a gond ezzel az volt, hogy a tárhelyszolgáltatónak 2 hétre visszamenőleg volt mentése, így a tartalmak – azonnali jelzés esetén – 100%-osan helyreállíthatóak lettek volna. De így pont akkor lett jelezve a baj, amikor már a tárhelyesnek is csak vírusos állapotról volt mentése.
Itt volt még egy kör a tárhelyessel, mert azt mondta, hogy minden év végén készítenek egy biztonsági mentést, és azt egy széfben tárolják. Erre több mint két hetet vártunk (részben azért, mert nem fért hozzá, részben azért, mert pont szabadságra mentem egy hétre), amikor kiderült, hogy 2017 végén nem készült ilyen mentés, csak 2016-ban.
Amíg ez ki nem derült (illetve amíg szabadságra mentem), egy 2017. márciusi állapotot állítottunk vissza.
A tartalmak olyan mértékben sérültek, hogy erre sajnos nem volt mód.
Itt bonyolította a dolgot, hogy tavaly novemberben készült biztonsági mentés az oldalról, de az ügyfél hibásan tárolta (nem futott végig a kicsomagolás, és az általam küldött zip fájlt pedig törölte – ergo használhatatlan volt).
A mentéseket én 7 napig tárolom, így nálam sem volt meg a novemberi mentés. Ha lett volna havi mentés, akkor max. egy hónapnyi tartalom veszik el és/vagy sokkal könnyebb a helyreállítás.
De szerencsére volt egy 2018. márciusi mentés, abból lett helyreállítva a weboldal váza. Azért írom így, mert az azóta eltelt több mint 400 napban számtalan cikket írt az ügyfél, és rengeteg módosítást is eszközöltünk a weboldalon. 60+ oldalas levelezést gyűjtöttem össze az ügyféltől ezen 400 napról, ezen (mint fejlesztési lista) végig kellett rágnom magam a tökéletes helyreállításhoz.
A havi mentések készítése plusz pénz (vagy egyszer meg kell tanulni, és becsülettel elvégezni havonta), de ha szükség van rá, akkor rengeteg időt és pénzt lehet megspórolni a felhasználásukkal.
Ha havonta készül biztonsági mentés, mondhatjuk, hogy akkor történhet adatvesztés. Ennek megelőzésére, saját oldalaknál a következőt alkalmazom: Ha írok egy cikket, akkor a HTML nézetből (hogy a formázás is meglegyen) ki szoktam másolni a forráskódot egy jegyzettömbbe, és elmentem. Ez azért jó, mert a tartalom hiánytalanul rendelkezésre áll később. Ha kép is került a cikkbe, azt is egy külön mappában (“backupig” a neve) tárolom a következő biztonsági mentés készítéséig.
A kinézetben végzett módosítások egy export-import fájllal menthetőek voltak, így ez nem volt nagy gond.
A legfontosabb szempont ilyen esetben mindig a tartalmak megmentése. A tartalom nélkül nem ér semmit a weboldal, és azt a legnehezebb rekonstruálni (újraírni). A korábbi cikkek (157 db), oldalak (13 db) tartalma végül 95,3%-osan helyre lett állítva. Ahhoz képest, hogy 400+ napos mentés állt rendelkezésre, szerintem nem rossz arány. A helyreállítás során több helyről lettek kinyerve adatok: részben korábbi mentésekből, részben archive.org oldal használatával, részben pedig a WordPress revision fájljaiból való kimazsolázással. 8 olyan cikk volt, amit sehonnan nem tudunk megmenteni, ezért azokat újra kell gépelni. Illetve a meglévő cikkek, oldalak 400 napja eszközölt változtatásai elvesztek, és kb. 30-40 cikk formázása, címkézése, kategorizálása, SEO-zása (vegyesen, hol mi, attól függ, honnan lett helyreállítva) is odalett. Ezeket ismét be kell majd állítani.
Mivel úgy volt, hogy a tárhelyesnek van év végi mentése, ezért csak az idei megmenthető cikkeket mentettem le a weboldalról. Amikor kiderült, hogy mégsincs ilyen, akkor a vírusos verziót egy másik tárhelyen össze kellett raknom, hogy további tartalmakat menthessek onnan.
Sajnos erre nem derült fény. Nagyrészt teljesen azonos konfigurációt használ sok más, érintetlen weboldallal.
Ezeket orvosoltam, és már van az oldalon WordFence is, valamint egyéb biztonsági bővítmény is, így hasonló esetnél sokkal gyorsabban fogunk tudni reagálni. Illetve lett feltelepítve olyan bővítmény, amivel az ügyfél egy kattintásra tud biztonsági mentést készíteni a weboldalról.
Igen, ha nincs ~400 napos biztonsági mentés, akkor sokkal nagyobb baj lett volna. De így is több, mint 13 munkaórám ment el a teljes helyreállításig. Igaz, ez a nagy szám annak is betudható, hogy az elmúlt 400 nap fejlesztéseit is újra végig kellett csinálnom.
Szerző: Szűcs Ádám Kategória: Videó, WooCommerce webáruház
Véleményem szerint érdemes minél egyszerűbb, és minél kevesebb opciót megadni fizetési módként is, és szállítási módként is. Nem érdemes mindent belezsúfolni egy webshopba, mert egyrészt a fejlesztő dolga is nehezebbé válik, a látogató sem fogja átlátni a lehetőséget, és végső soron tulajdonosként is nehezebb dolgunk lesz követni a rendeléseket és a beérkezett összegeket.
Szállítási módok:
Elterjedt fizetési módok:
Szerző: Szűcs Ádám Kategória: Videó, WooCommerce webáruház
A következő videón bemutatom a szállítási osztályok alapfunkciót a WooCommerce webáruházban, egyből egy példával illusztrálva.
Földrajzi helyek, irányítószámok, vagy irányítószámtartományok alapján különféle szállítási díjakat (vagy éppen ingyenes szállítást) lehet megadni a webáruházban.
A WooCommerce => Beállítások => Szállítás menüpont alatt található a “Szállítási zónák” és “Szállítási osztályok” menüpont.
Egy olyan szállítási díjkalkulátor összerakását, ami figyeli a vásárló szállítási címét (Budapest, vagy vidék), illetve azt, hogy a 1 kg alatti, vagy feletti termékeket vásárolt-e.
Szerző: Szűcs Ádám Kategória: Cikk, Hírek, Videó
2018. május 25-én lép életbe az egységes Európai adatvédelmi rendelet. Hogy ennek megfeleljen a WordPress, a fejlesztők 2018.05.17-én kiadták (remélem, a cikket korábban írtam) a 4.9.6-os verziót, amely a GDPR szellemében készült.
Részletesebb infók a másik blogomon ide kattintva érhetőek el.
Készítettem egy 5,5 perces videót a fejlesztésekről:
Figyelem!
A fentieken túl kérd ügyvéd/adatvédelmi szakértő segítségét a teljesen személyre szabott jogi megfelelőségért!
Szerző: Szűcs Ádám Kategória: Videó, WooCommerce webáruház
Az egyik munkám során az volt a megrendelő igénye, hogy a webshop úgy számítson szállítási díjat, hogy a kosár végösszegét vegye figyelembe, és előre meghatározott sávok alapján más-más szállítási díj kerüljön felszámításra a vásárlónak.
Találtam egy remek bővítményt, ami rengeteg mindent tud, és ez a funkció pont az ingyenes verziójában van, és tökéletesen működik. Ha ilyenre van szükséged, nagyon hasznos lesz!
Egy ilyen táblázatban lehet megadni a szükséges sávokat, és szállítási díjakat:
Jöjjön a videó:
Szerző: Szűcs Ádám Kategória: Videó, WooCommerce webáruház
Az alábbi 5,5 perces videón megmutatom, hogyan kell PayPal fizetési módot integrálni egy WooCommerce webshopba.
