Kategória: ‘Cikk’

Sortörés a szöveges widgetekben

Alapvetően két módja van (az eredmény ugyanaz lesz), hogy a szöveges widgeteknél megoldjuk a tartalom tagolását, és ne csússzon egybe az összes tartalom.

1. Ugye úgy néz ki egy szöveges widget, hogy van egy “Cím:” része, valamint egy tartalmi része, ahová magát a szöveget másoljuk be. Na ez ALATT van egy olyan opció, hogy “Automatikus bekezdés hozzáadása”. Ha ezen opció előtti jelölőnégyzetbe teszünk egy pipát, és így mentjük el a widgetet, akkor ahol sortörést használtunk a widget tartalmi részén belül, ott a weboldalon is lesz egy sortörés.

2. HTML formázással berakunk egy sortörést a szövegbe oda, ahol azt szeretnénk, hogy a mondandónk új sorba kerüljön. A sortörés HTML kódja: <br> – ahová ezt tesszük, az utána következő rész egy új sorba fog kerülni. Ebből lehet egymás után többet is alkalmazni, ha egy sortörés nem elegendő.

Nehezített WordPress telepítés

Egy nagyon súlyos tévhitet szeretnék eloszlatni a mai bejegyzésemmel, amellyel rengetegen megnehezítik a WordPress amúgy rémesen egyszerű telepítését.

Többektől hallottam már, hogy elakadnak a WordPress telepítése során, amikor a wp-config.php fájlt kell szerkeszteni, majd a /wp-admin/install.php-t kell futtatni. Soha nem értettem, hogy telepítés során miért kellene szerkeszteni ezt a fájlt, egyáltalán honnan veszik ezt az infót.

Néhány napja megoldódott a rejtély.

Kiderült, hogy a magyar telepítőcsomagban található wordpress\olvasdel.html fájlban írják azt, hogy úgy kell telepíteni a WordPress-t, hogy nyissuk meg a wp-config-sample.php fájlt, és szerkesszük meg benne az adatbázis kapcsolódáshoz szükséges adatokat.

NA KÉREM! EZ ÍGY HÜLYESÉG, AHOGY VAN!!!

Régen lehet, hogy nem volt webes telepítőfelület a WordPress-hez, de immáron 2013-at írunk, és évek óta elérhető a webes WordPress telepítő, ami létrehozza helyettünk a wp-config.php fájlt, de legrosszabb esetben is megmondja, hogy ezt és ezt mentsük el wp-config.php néven, töltsük fel, és jó lesz.

WordPress telepítéshez nem kell mást tenni, mint a WordPress fájljait felmásolni a tárhelyre, megnyitni a leendő weboldalunk elérhetőségét egy böngészőben, és végigkattintgatni a webes telepítőt az ott leírtak alapján.

WordPress 3.6 Béta 1

A WordPress 3.6 Béta 1 már elérhető!

Ez a WordPress verzió még fejlesztés alatt van, így nem javasolt éles weboldalon használni. Inkább telepíts egy teszt WordPress-t az új verzióval (LETÖLTÉS). Ha van már teszt weboldalad, a WordPress Beta Tester bővítménnyel is ki tudod próbálni a 3.6-os verziót.

Már közel 3 hónapja fejlesztik az új WordPresst, és most jutott olyan állapotba, hogy már ki lehet próbálni. Érdemes letesztelni az összes használt bővítménnyel és kinézettel (saját fejlesztésekkel is!), hogy előre tudjuk, hogy minden megfelelően működik-e, illetve ha mégsem, azt jelezhessük a fejlesztőknek időben. A WordPress fejlesztői minden igyekezetükkel azon vannak, hogy az új verzió kompatibilis legyen a régebbi kinézetekkel és bővítményekkel, ez még ez csak Béta verzió, ezért előfordulhatnak hibák, amelyek még megoldásra várnak.

Mik az újdonságok a 3.6-os verzióban?

  • Bejegyzés formátumok: Különféle bejegyzés típusokat különféle módon tud megjeleníteni az új WordPress. A következő bejegyzés típusokat lehet majd létrehozni: Kép, Galéria, Link, Videó, Audió, Chat, Állapot, Idézet, Széljegyzet. Igazából elsőre úgy tűnik ritka haszontalan funkció, hiszen ezt az „újítást” a kinézetek nagyon nagy része nem kezeli, illetve eddig is létre lehetett hozni ilyen dolgokat.
  • Twenty Thirteen: Az előző évekhez hasonlóan az új WordPress verzióhoz készült alapértelmezett kinézet. A Twenty Thirteen színgazdag, blog központú kinézet, amely teljes mértékben támogatja az új bejegyzés formátumokat.
  • Audió/Videó: Bővítmény nélkül lehet beágyazni audió és videó fájlokat a weboldalba.
  • Jobb automata mentés: A bejegyzéseket helyileg menti az új rendszer. Ha a böngésződ összeomlik, a számítógéped meghal, vagy a szerver leáll, akkor sem veszik el a már befektetett munkád.
  • Fejlett bejegyzés zárolás: Lehetséges, hogy valaki éppen szerkeszt egy bejegyzést, amelyet megnyitsz, de előfordulhat, hogy csak „elaludt a billentyűzeten”. Könnyedén ki lehet „rúgni” a bejegyzés szerkesztőből, és ezzel elkerülhető a párhuzamos szerkesztés.
  • Navigációs menük: Megújul a „Megjelenés” => „Menük” menüpont. Sajnos nem előnyére, kicsit nehézkesebb lesz a használata.
  • Revisions: A tartalmak előző állapotainak összehasonlító funkciója is át lesz szabva, ezt viszont könnyebb lesz használni a korábbi állapotához képest. Innen eltűnt az Easter Egg.

Az újdonságokról fogok készíteni videót is.

Közkedvelt CMS rendszerek – WordPress

A Marketingesek Lapja című újság márciusi számában jelent meg az alábbi cikkem, amelyben a WordPress CMS (tartalomkezelő) rendszerről írtam:

A cikk szövege, vagy a fenti képre kattintva, vagy alább olvasható:

Weboldal csere, 69 mp leállással (esettanulmány)

Munkám során számos érdekes feladatom van, az egyik a következő volt: Adott egy WordPress weboldal, amely HELYETT egy másik WordPress weboldalt készítettünk, és minél kevesebb üzemidő-kieséssel szerettem volna megoldani az új WordPress weboldalra való átállást, hiszen a látogatók szempontjából létfontosságú, hogy ne hibás weboldalra érkezzenek.

Szándékosan emeltem ki a “helyett” szót, mert nem a meglévő oldalt alakítottuk, hanem egy teljesen új WordPress telepítésből alakítottuk ki az új weboldalt. Amikor elkészült az új oldal egy teszt tárhelyen, akkor azt költöztetni kellett a végleges, a régi weboldal helyére. Ugye a költöztetéskor a weboldal fájljait, és az adatbázist is át kell másolni a leendő szerverre. De esetünkben már ott volt egy WordPress weboldal összes fájlja, amely egy éppen működő weboldalt szolgált ki.

Hogyan lett mégis megoldva, hogy mindössze 69 másodpercig állt a weboldal?

  1. Az új weboldal minden fájlját lemásoltam a saját gépemre, valamint kiexportáltam az adatbázisát is.
  2. A lementett wp-config.php fájlban átírtam a kapcsolódási adatokat az új tárhelynek megfelelően.
  3. A MySQL adatbázisban kicseréltem az teszt tárhely url-jét a leendő újra.
  4. A MySQL adatbázist importáltam az új tárhelyen. Arra már az új weboldal kialakításakor figyelni kellett, hogy az adatbázis előtag más legyen, mint a régi weboldalnál. Valamint arra, hogy az alábbi pontok végrehajtása után a régi weboldal tábláit törölni kell az adatbázisból.
  5. A fájlok FTP-n történő felmásolásakor kellett figyelni, hiszen ha elkezdem felülírni/összekeverni/törölni a régi fájlokkal az újakat, abból csak bonyodalom lenne. Ezért először a saját gépemen lévő weboldal mappákkal kellett valamit kezdeni. Ugye a WordPress alapvetően 3 mappából és néhány fájlból áll. A mappák: wp-admin, wp-includes, wp-content. Ezeket átneveztem a következőkre: wp-admin2, wp-includes2, wp-content2. Így ezek a mappák anélkül felmásolhatóvá váltak az új tárhelyre, hogy befolyásolnák a jelenleg még működő, régi weboldalt. Ekkor ugye még leállás nélkül működik a régi weboldal.
  6. Miután a wp-admin2, wp-includes2, wp-content2 mappák fel lettek másolva a régi weboldal mellé, indul a stopper, indul a 69 mp, amikor elérhetetlen lesz a weboldal! Mi történik ezalatt? Lássuk:
  7. A tárhelyen már korábban fent lévő wp-admin, wp-includes, wp-content mappákat át kell nevezni a következőképpen: wp-admin3, wp-includes3, wp-content3. Azért nem töröljük egyből, hogy kevesebb ideig álljon a weboldal!
  8. A wp-config, és a többi alapértelmezett gyökér-könyvtárban található WordPress fájlt (csak azokat!!) töröltem a szerverről, és a helyettük felmásoltam az új WordPress ezekkel megegyező nevű (ha eltérő a régi és új WordPress verziója, előfordulhat, hogy nincs minden ilyen fájlnak párja) fájljait.
  9. A wp-admin2, wp-includes2, wp-content2 mappákat át kell nevezni, méghozzá így: wp-admin, wp-includes, wp-content.
  10. Ennyi volt, az régi weboldal helyén máris elérhető az új!
  11. Ne felejtsük el törölni a wp-admin3, wp-includes3, wp-content3 mappákat, valamint a 4. pontban említett táblákat.

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

WordPress jelszócsere PhpMyAdmin segítségével

Van úgy, hogy nem tudjuk használni a jelszó-helyreállító funkciót, nem érjük el a profilunkat, és nincs egyéb módszerünk se, hogy adminisztrátorként belépjünk a WordPress adminisztrációs felületére.

Ha van PhpMyAdmin hozzáférésünk, akkor egyszerű dolgunk lesz, könnyen tudunk egy-egy felhasználónak új jelszót beállítani.

1. Nyissuk meg a PhpMyAdmin elérhetőségét. Erre lehet, hogy egy külön linket ad a tárhelyszolgáltatód, de lehet, hogy cPanelhez kaptál hozzáférést, és ott éred el ezt a szolgáltatást. Hasonlóan (így) néz ki:

2. Miután beléptünk, ki kell választani azt az adatbázist, amelyet a WordPress használ, majd rá kell kattintani. Kattintásra nagyobb lesz az alábbi kép!

3. Ezután ilyet kell látni:

4. Ki kell választani (rá kell kattintani) az “_users” végű táblát. Ezt két helyen is meg lehet tenni:

5. Fontos, hogy a táblát a “Tartalom” fülön lássuk! Itt kell a kiválasztott felhasználó sorában található módosítás gombra kattintani (Kattintásra nagyobb lesz az alábbi kép!):

6. A megjelenő felület az alábbi képhez hasonlít. Itt a “0.”-val jelölt hely mellett (user_pass) a “0b.” helyen található legördülő menüből ki kell választani a képen “1.” ponttal megjelölt MD5 opciót. A képen “2.”-vel jelölt helyen található karaktersorozatot törölni kell, és a helyére be kell írni az új jelszót. A képen “3.” pontként jelölt helyen rá kell kattintani az “Indítás” gombra. Kattintásra nagyobb lesz az alábbi kép!

7. Máris lehet használni az új jelszót a WordPress adminisztrációs felületére történő belépéshez!

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!!!