Ügyfélszolgálat: +36 70 623 8822

161 aloldal szerkesztése 1 órán belül? Lehetséges!

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.

Példa:

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.

A megoldás számokban:

  • 161 cikk/oldal lett szerkesztve.
  • 59 perc 37 mp alatt végeztem.
  • Ez idő alatt 9762 “interakciót” tettem: 6026 egérgörgetés, 2398 billentyűzet leütés, 1307 bal egérgomb kattintás, 1 jobb klikk, 30 duplaklikk.
  • A fentiek átlagosan másodpercenként 2,73 műveletet adnak ki, ez percenként 163,7 művelet, 1 órán keresztül.
  • Egy aloldallal 22,2 mp alatt végeztem: ennyi idő elég volt a cikk megtalálására, megnyitásra, szerkesztésre, mentésre és ellenőrzésre.

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.

    

WordPress statisztikák 2015-2017

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ó.

Hogyan használják a WordPress-t?

Jellemzően milyen ügyfelek használják a WordPress-t?

(fejlesztőknek feltett kérdés)

Mire használják legfőképp a WordPress-t?

Mennyi időt (óra) szánnak egy WordPress-el felépített weboldal elkészítésére?

Mi a legjobb dolog a WordPress-ben?

A fejlesztők szerint:

A felhasználók szerint:

Mi a legrosszabb dolog a WordPress-ben?

Forrás, további adatok:
WordPress User Survey Data for 2015-2017

Fertőzött WordPress weboldal – egy tanulságos sztori

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.

Mi vezetett idáig, mi volt a megoldás? Miért volt extrán peches az ügyfél? Hogyan lehetett volna enyhíteni a károkat előrelátó módon?

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.

Azonnali jelzés – FONTOS!

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.

Miért kellett biztonsági mentés, nem lehetett volna leírtani a vírust az oldalról?

A tartalmak olyan mértékben sérültek, hogy erre sajnos nem volt mód.

Legyen havi biztonsági mentésed!

  • A következő dolog, hogy legalább havonta készüljön biztonsági mentés a weboldalról.
  • Amikor elkészül egy biztonsági mentés, az legyen elmentve tömörítve és kicsomagolva is. Ezt korábban nem kommunikáltam eléggé, ezért frissült az erre vonatkozó levelem is, hogy erre külön felhívjam a figyelmét a mentést kapó ügyfeleknek.
  • Ha készül egy újabb mentés, a RÉGI mentések AKKOR SE legyenek törölve.

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.

Mi történjen két mentés között?

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.

Kinézet megmentése:

A kinézetben végzett módosítások egy export-import fájllal menthetőek voltak, így ez nem volt nagy gond.

Tartalmak megmentése: 

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.

Mi volt a probléma?

Sajnos erre nem derült fény. Nagyrészt teljesen azonos konfigurációt használ sok más, érintetlen weboldallal.

  • De más tárhelyen van a weboldal, lehet, hogy ott volt valamilyen gond.
  • Az ügyfél telepített jópár olyan bővítményt, ami már elavult.
  • Néhány admin felhasználónak “kismacska” szintű gyenge jelszava volt.

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.

Lehetett volna nagyobb baj?

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.

WooCommerce 18. – Szállítási és fizetési módok összehangolása

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.

Mik a legfőbb szállítási és fizetési módok egy webáruházban?

Szállítási módok:

  • Személyes átvétel (üzletben, telephelyen).
  • Futáros kiszállítás.
  • Postai utánvét.
  • Letöltés (letölthető terméknél).

Elterjedt fizetési módok:

  • Utánvét, készpénzben.
  • Banki átutalás.
  • Bankkártyás fizetés.
  • PayPal fizetés.
  • Barion, Borgun, Baintree, stb.

Hogyan lehet összekombinálni az alábbiakat?

  • Legyen személyes átvétel és futáros postázás.
  • Legyen készpénzes, banki átutalásos és PayPalos fizetési mód.
  • Letölthető terméknél ne legyen szállítási díj.
  • Letölthető terméknél ne lehessen személyes átvételt választani. (mert ott letöltik majd a terméket)
  • Személyes átvétel vs. banki átutalásos fizetési mód beállítása.

    

WooCommerce 17. – Szállítási osztályok, alapszintű példával

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.

Mik azok a szállítási zónák és osztályok?

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.

Hol vannak a szállítási osztályok?

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.

Mit mutatok a videón?

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.

    

Megjelent a WordPress 4.9.6 – szem előtt a GDPR!

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.

Mik a WordPress 4.9.6 legfőbb újdonságai?

  1. Beállítható adatvédelmi szabályzat oldal. (alap mintával)
  2. Hivatkozás az adatvédelmi szabályzat oldalra a belépő/regisztrációs oldalon.
  3. Tárolt személyes adatok exportálása.
  4. Tárolt személyes adatok törlése.
  5. Hozzászólás-cookie tárolásához engedély kérése.

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!

WooCommerce 16. – Végösszegfüggő szállítási díj alkalmazása

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ó: