Kategória: ‘Bővítmények’

All in One SEO Pack – használd, vagy sem?

Az All in One SEO Pack nevű bővítményt az egyik legnépszerűbb WordPress bővítmény, amelyet az eredményesebb keresőoptimalizálás elősegítéséért szoktunk telepíteni.

Tegnap egyik ügyfelem jelezte, hogy a tárhelyszolgáltatója kikapcsolta az All in One SEO Pack (AIOSP) bővítményt a weboldalán, ahol több száz cikkhez volt beírva a cím/leírás/kulcsszó érték. Arra hivatkozott, hogy “tönkrevágta” a szerverüket egy, az All in One SEO Packban felfedezett biztonsági rés.

Arra figyelmeztetett, hogy töröljük ezt a bővítményt. Aki nem tette meg, ott megtette a szolgáltató. Igazából nem is törölték, csak egy fájlnevet megváltoztattak, hogy ne legyen elérhető.

Mivel már többen kerestek, hogy elveszik-e az eddigi befektetett munkájuk, meg kell őket nyugtassam: nem, a _postmeta táblában megvan minden beírt érték, a bővítmény visszakapcsolása (alul leírom hogyan kell) után ismét láthatóak lesznek ezek!

A tény az, hogy egyetlen egy hasonló hírt találtam az interneten, itt tekinthető meg. Azaz korántsem akkor a probléma (ha van vele) a bővítménnyel, mint ahogy tűnik. 1 hír, 14,5 millió felhasználóra. Szerint ezek alapján biztonsággal lehet használni a bővítményt. Legalábbis én akkor szoktam mérvadónak venni egy hírt, ha arról többen is beszámolnak.

Véleményem szerint az a legfontosabb, hogy aki használja az All in One SEO Pack nevű bővítményt, készítsen biztonsági mentést a weboldaláról (de ezt ugye minden olvasóm csinálja rendszeresen? :) ). Egyszerűbb ebből visszatölteni az esetlegesen feltört weboldalt, mint az AIOSP törléséből eredő hátrányokat elszenvedni.

Ráadásul a figyelmeztetés alapján nem a weboldalt törik fel, hanem a szervert támadják valamilyen módon a bővítmény segítségével. Azaz nem a weboldalt kell félteni, ezért a tárhelyszolgáltatónak kell gondoskodni a védelemről.

ui.: Aki ennél a szolgáltatónál van, a következőképpen tudja visszakapcsolni a bővítményt:

  • FTP-n csatlakozni kell a tárhelyhez.
  • Meg kell keresni a wp-content/plugins/all-in-one-seo-pack mappát.
  • Ebben a mappában van egy “all_in_one_seo_pack.php_none” nevű fájl. Ezt kell átnevezni “all_in_one_seo_pack.php”-ra
  • Ezután vissza lehet kapcsolni az admin felületen a bővítményt.

Figyelem! Csak a saját felelősségedre kapcsold vissza a bővítményt, mert az adott szolgáltató korlátozás alá vonhatja a weboldaladat, ha ez a visszakapcsolás sérti a köztetek fennálló szerződést!

Felmerülhet a kérdés: ha fent linkelt cikkben a “quickedit_functions.js”-t nevezik meg támadási felületnek, akkor miért az “all_in_one_seo_pack.php” fájlt nevezték át? Két válasz van:

  • Nem függ össze a két hír.

Ráadásul egy másik levélben azt írták, hogy: “TÖRÖLNI” kell a bővítmény fájljait, nem átnevezéssel blokkolni az egész bővítményt, és fent hagyni a fájlokat, ami állításuk szerint a problémát okozza. Erre ezt csinálják. Ebből azt látom, hogy ők sem igazán értik, hogy mi okozza a gondot. Persze ha nincs bekapcsolva a bővítmény, nehezebben tudják megállapítani, hogy a tárhelyen van-e AIOSP, de attól a fájlokat még meg lehet hívni a böngészőben. Ezért ha tényleg komoly lenne a probléma, akkor tényleg törölni kellene minden hozzá tartozó fájlt.

Bővítmények április első napjára (Bolondok napja)

Bolondok napja alkalmából nézzétek meg az alábbi összeállítást! Ha nem üzleti célú a weboldalatok, nyugodtan ki lehet próbálni! :)

1) Weboldal elforgatása x fokkal (IE alatt nem működik):

Ehhez nem kell mást tenni, mint EZT a kódot beilleszteni a css fájlba, a “body {” részhez.

Eredmény:

Természetesen a kódban található “7deg”-ben található 7-es szám helyére bármennyit lehet írni. Ez határozza meg, hány fokkal legyen elforgatva a weboldal.

2) Cornify for WordPress – Unikornisok a weboldalon

A bővítményt elég telepíteni és aktiválni, máris működésbe lép. Ha valaki 5 mp-ig nem kattint a weboldalon, megjelenik egy unikornis. Ha még 5 másodpercig tétlen, még egy. És így tovább! :) Eredmény:

3. Upside Down WordPress bővítmény
Aktiválás után megfordítja a weboldalt. Eredmény:

Persze a listát lehetne folytatni akár bővítmények “okos” összehangolásával. Pl.: Jelszó megadáshoz virtuális billentyűzet használatának kötelezővé tétele kombinálva egy kötelezően minimum 15-20 karakteres jelszóval kombinálva: garantált a hatás!! Esetleg ezt összekombinálva egy kínai karakterrel a jelszóban :D

Kellemes húsvétot kívánok!

Kategorizált legutolsó bejegyzések szekció(k) létrehozása

A Megjelenés => Widgetek menüpont alatt található alapértelmezett “Legutóbbi bejegyzések” widget azt tudja, hogy a legutolsó bejegyzéseket kilistázza a megadott helyen az oldalsávon.

Ez nem minden esetben lehet megfelelő megoldás, ugyanis előfordulhat, hogy NINCS blog menüpont, csak a menüben/oldalsávon található linkekből érhetőek el a különféle tartalmi kategóriák tartalmai. De mellette felmerülhet az igény, hogy az egyik kategória legfrissebb bejegyzései jelenjenek meg az oldalsávon, egy különálló részben. Erre nyújt megoldást a Category Posts Widget nevű bővítmény.

Telepítés, aktiválás után nincs más dolgunk, mint a Widgetek között kikeresni a “Category Posts” nevűt, feltenni valamelyik widget-területre, és kiválasztani, hogy ott mely kategória legfrissebb bejegyzései jelenjenek meg, illetve azokból is mennyit listázzon.

Category Posts Widget letöltés

Többszörös regisztráció engedélyezése

Az Allow Multiple Accounts bővítménnyel felülírhatjuk azt az alapértelmezett WordPress funkciót, amely szerint egy e-mail címmel egy felhasználói fiókot lehet létrehozni.

Telepítés után megjelenik egy “Multiple Accounts” menü a Felhasználók menüpont alatt. Itt először is be lehet állítani, hogy a) legyen-e többszörös (“Allow multiple accounts for everyone?”) regisztráció; b) egy e-mail címmel mennyi fiókot lehessen (“Account limit”) létrehozni?

Lejjebb pedig láthatók a felhasználói fiókok, e-mail cím szerinti bontásban (klikkre nagyobb lesz!):

Allow Multiple Accounts letöltés

Tagsági rendszer bővítmény és a WordPress együttes frissítése

A minap a következő feladattal néztem szembe:
Adott volt egy WordPress 2.9.2-es rendszer, amelyen volt egy User Access Manager (klikkre eljuthatsz a róla készült 33 perces videóhoz) 0.9.1.3-es verziójával működtetett tagsági rendszer.

Feladat:
Mindkettőt frissíteni úgy, hogy tökéletesen működjön minden.

A feladat nem volt egyszerű, több okból sem:

  • A WordPress már a 3.5.1-es (+23 verzió) verziónál jár, míg a tagsági rendszer már az 1.2.2-nél (+14 verzió). Ekkora verziókülönbségnél fokozottan kell figyelni a kompatibilitásra, hiszen korántsem garantált az, hogy ami 2-3 éve működött egy bizonyos párosításban, az most is működni fog.
  • A tagsági rendszer nem állhatott le, legfőképpen nem omolhatott össze, mert az azt eredményezte volna, hogy tagság nélkül is meg tudták volna nézni a látogatók a zárt tartalmakat.

Melyek voltak a megoldáshoz vezető lépések?

  1. Teljes biztonsági mentés a weboldalról. Erre azért van szükség, hogyha bármi balul sülne el, vissza tudjuk állítani az eredeti verziót. Valamint a következő pont miatt is.
  2. A biztonsági mentésből egy tesztoldal létrehozása egy másik domain alatt, másik adatbázissal. Így elértük, hogy van egy – az eredetivel mindenben megegyező – tesztfelületünk, azaz bármilyen kockázat nélkül tudunk kísérletezni.
  3. Először a WordPress-t frissítettem 2.9.2-ről 3.5.1-re. Ez gond nélkül ment.
  4. Utána frissítettem a tagsági rendszert kiszolgáló bővítményt, ám itt beütött a krach: a tagsági rendszer leállt, minden tartalom nyilvánossá vált. Milyen jó, hogy nem az éles oldalon csináltam!
  5. Összehasonlítottam az eredeti weboldalhoz tartozó adatbázisban a tagsági rendszer tábláit, a teszt oldal azonos részeivel, és a következőt láttam: Nem ugyanolyan a táblaszerkezet a két helyen! Ezért az összeomlás. A régi beállításokat nem tudta kezelni a bővítmény a frissítés után, mivel azok már teljesen máshogy (kevesebb táblában is) tárolódtak az adatbázisban. Innentől lesz bonyolult a megoldás.
  6. Feltettem egy bővítményt, amely azt a célt szolgálja, hogy csak bejelentkezett felhasználók láthassák a weboldalt. Erre a tesztoldalon nem lett volna szükség, ám így ténylegesen tudtam szimulálni az eredeti oldalon szükséges lépéseket. Erre azért lesz szükség, hogy a tagsági rendszer kikapcsolása miatt “külsősök” ne férhessenek hozzá a védett tartalmakhoz. Így ideiglenesen csak a regisztrált tagok látják a tartalmakat, igaz ők jogkör nélkül mindent.
  7. Töröltem az összes, a bővítményhez tartozó táblát az adatbázisból.
  8. Töröltem magát a tagsági rendszeres bővítményt is.
  9. Újratelepítettem a bővítmény legfrissebb verzióját.
  10. Újra létrehoztam a különféle jogköröket, felhasználói csoportokat.
  11. A felhasználókat egyesével be kellett sorolni az őket megillető jogosultsági szintekbe.
  12. Mivel eredetileg úgy voltak kialakítva a jogkörök, hogy egy-egy kategóriába tartozó bejegyzések megtekintése volt egy-egy jogkör meglétéhez kötve, ezért ezeket a kategóriákat ismét össze kellett kötni a tagsági rendszerrel.
  13. Itt felmerült egy újabb gond: a kategóriáknál van egy alapértelmezett kategória, amelyet nem lehet törölni, csak átnevezni. Az egyik jogkör úgy volt kialakítva, hogy ehhez a kategóriához tartozó bejegyzéseket lehetett megtekinteni vele. Itt egy olyan érdekes hiba jött elő, hogyha beállítottam, hogy ezt a kategóriát csak azzal a bizonyos jogkörrel rendelkező felhasználók nézhetik meg, akkor az összes oldal is zárolva lett, holott ez nem volt célom. Ezt a problémát úgy hárítottam el, hogy ezt a kategóriát újra létrehoztam, majd ezt az újonnan létrehozott kategóriát soroltam be az egyik jogkör alá. Természetesen a régi kategóriából át kellett sorolni a tartalmakat az újonnan létrehozott alá.
  14. Miután minden működött, a fenti lépéseket el lehetett végezni az éles weboldalon is!

Tanulság: biztonsági mentés nélkül még egy bővítményt se frissíts!!!

Időjárás widget

A várható időjárás általában mindenkit érdekel, ezért is népszerű a weboldal tulajdonosok körében az oldalsávban elhelyezett előrejelző widget.

A WordPress.org oldalról közel kilencven időjárással kapcsolatos plugin tölthető le, de most végre elkészül az ismereteink szerint első hazai fejlesztésű időjárás előrejelző bővítmény.

Mit tud ez az új kiegészítő?
Nos, meglepően szép designt ad, és eltér az Amerikában népszerű időjárás megjelenítésektől, és jobban illeszkedik a hazai ízléshez. A widget mérete szabadon változtatható 72 pixeltől felfelé, így szinte bármilyen oldalsávba jól beilleszthető. A szélességtől függően változik az előre jelzett napok száma is. Ez legfeljebb öt nap lehet, de ez több mint amit a legtöbb ilyen kiegészítő nyújt.

A widget három alapdesignt nyújt (fekete, fehér és színes), de  lehetőség van egyedi színek beállítására is, amivel a widget jobban belesimítható oldalunkba.

A plugin jelenleg több mint 15 ezer településre vonatkozóan ad előrejelzést, Magyarország esetén közel félszáz város választható. Az előrejelzést ez esetben a Yahoo időjárás előrejelzése adja. De a fejlesztőnek van egy kis bónusza a hazai alkalmazóknak. Van külön magyar verzió is, ami az Esőtánc előrejelzését használja fel, és így sokkal pontosabb előrejelzést ad, mint a magyarországi helyzetet nem túl pontosan megfogó nemzetközi oldalak. A magyar verzió a fejlesztő oldaláról tölthető csak le.

Letöltés:

A bővítményeltüntető bővítmény

A WordPress oktatóvideó Facebook oldalát követők már február 7-én értesülhettek arról, hogy találtam egy remek bővítményt. Ezt posztoltam akkor:

“Olyan WordPress kódot találtam, hogy csak na! Már készül is az oktatóvideó róla, amely a PROFI PLUSZ csomaggal rendelkezők számára lesz elérhető!

Mit tud?
Segítségével el lehet rejteni a bővítmények listájából egy vagy több bővítményt (saját magát is)!

Aki ügyfeleknek készít weboldalt, az tudja, hogy ez egy kincs!

Azóta kiderült egy hiányossága a bővítménynek, mégpedig az, hogy az admin felületen, a Bővítmények => Szerkesztő menüpont alól nem tünteti el a bővítménylistából már “eltüntetett” bővítményeket. De ez cseppet sem von le az érdemeiből, hiszen van olyan bővítmény, amellyel a Bővítmények => Szerkesztő menüpontot eltüntethetjük, majd a művelet után eltüntetjük magát a bővítményt is, valamint el lehet tüntetni a Bővítmények => Szerkesztő menüpontot eltüntető bővítmény menüpontját is :)

Na jó, nem bonyolítom tovább, jöjjön a részletes (és érthető) videó a fent leírt “bővítményeltüntető bővítményről”.

A videó hossza: 7 perc 51 mp.


qTranslate – widgetcím fordítási trükk

Ahogy a mondás tartja: “A jó pap is holtig tanul.” – Munkám során nap mint nap rengeteg dolgot tapasztalok, próbálok ki, és tanulok meg. Következzék hát egy kulisszatitok. Sokáig úgy gondoltam, hogy a qTranslate nevű WordPress bővítménnyel csak egy nevet lehet megadni egy-egy widgetnek. Azaz bármilyen nyelven is nézi a látogató a weboldalt, mindig csak egy adott nyelven láthatja a widgetek címet. Ez alól kivétel volt az összes alapértelmezett (pl.: legutolsó hozzászólások, legújabb cikkek, oldalak, stb.) WordPress widget, amelyeknek ha nem adtunk címet, akkor a rendszer olyan nyelven jelenítette meg a widget-címet, amely nyelven éppen állt a weboldal. De az egyéni widgeteknél nem lehetett mást tenni, mint megadni egy címet, amelyen nem lehetett nyelvenként változtatni. Legalábbis így tudtam. Lehet, hogy a lentebb bemutatott trükk már a régebbi qTranslate verziónál is működött, azonban én csak nemrég ismerkedtem meg vele egy ügyfél által kezelt weboldalon.

A következő videón tehát bemutatom, hogyan lehet az alábbi képnek megfelelően nyelvenként egyedi címet adni a widgeteknek:


qTranslate – keresőbarát url minden nyelvhez!

Vegyünk egy példát.
Magyar és angol nyelvű weboldal, angol az alapértelmezett nyelv. Legyen egy Prices (Árak) menüpont. Alapértelmezett esetben ennek az aloldalnak a következők lesznek az elérési útvonalai:

  • oldal.com/prices (angol)
  • oldal.com/hu/prices (magyar)

Ugye nem szép, és nem is keresőbarát, hogy a magyar nyelvnél is angol szó szerepel az url-ben?

A következő videón megmutatom mit kell tenni, hogy a fenti példánál maradva a magyar url így fessen (természetesen az angolt nem bántjuk, az marad az eredeti, az megfelelő a fentiek szerint):

  • oldal.com/hu/arak

Hogyan? Mit kell tenni? Íme:


qTranslate kompatibilitási probléma

Ha használod a weboldalad több nyelven való megjelenítéséhez a qTranslate nevű bővítményt, akkor hasznos lesz számodra a következő táblázat.

Mivel a többnyelvű weboldalt kiszolgáló WordPress-t is frissíteni kell, nem árt tisztában lenne vele, hogy ennél a bővítménynél a frissítés tönkreteheti a weboldalt részben, vagy egészben. Mielőtt frissíted a WordPress-t, meg kellene nézned a lenti linken, hogy a leendő WordPress verzióhoz van-e működő qTranslate verzió. AZAZ NEM MINDEGY, HOGY MILYEN WORDPRESS VERZIÓ MELLÉ MILYEN VERZIÓJÚ QTRANSLATE PLUGINT HASZNÁLSZ! Ha van, akkor egymás után kell frissíteni a WordPress-t, és a qTranslate bővítményt is, hogy ne legyen fennakadás csak az egyiknek a frissítése miatt.

Egy Ügyfél oldalát frissítettem a napokban, és ott derült ki, hogy a fentiekre figyelni kell. Frissítettem a WordPress-t a 3.5 verzióra, és a qTranslate plugint is a legfrissebbre. Erre elromlott a szerkesztőfelület. Erre csak azt tudtam csinálni, hogy a WordPress-t VISSZAFELÉ frissítettem, kettővel korábbi verzióra, míg a qTranslate plugint eggyel régebbire. Így helyreállt a rend, és ismét működött minden megfelelően.

A jelenlegi kompatibilitás táblázat itt érhető el. A legfrissebb táblázat itt található mindig: http://www.qianqin.de/qtranslate/download/

qTranslate 2.5.31 letöltés – (ez a WordPress 3.4.1-es verziójával kompatibilis.