Az élet úgy hozta, hogy eddig elkerültem a Joomla Form kezelőjének Checkbox típusát. A dolog első ránézésre szépen működik, de ha próbálgatni kezdjük az első mentést követően mindig bekapcsolt állapotú marad, és elsőre semmilyen szép szóval nem lehet kikapcsolt állapotra rábeszélni.

Tekintettel arra, hogy a mostani munkához szükségem volt rá, és kikerülni sem szerettem volna, ezért végigkerestem elsőre a weben elérhető dolgokat, majd a rendszert is megnéztem működés közben.

Az iránymutatást Posting Unchecked Checkboxes in HTML Forms cikkben találtam meg, ezt követően egyszerű vizsgálattal kiderült mi is a probléma. A HTML megközelítés szerint a checkbox csak akkor szerepel a POST-ban, ha az bekapcsolt állapotú. Amennyiben kikapcsoljuk, nincs benne a POST-ban. Ez gyorsan ellenőriztem is a beérkező modell osztályban és valóban a kikapcsolt vezérlő nem került be az érkező adatcsomagba. Néztem tovább mi is történik ezzel a csomaggal, és rá kellett döbbenjek, hogy a csomagban nem szereplő vezérlő értékét egyszerűen becseréli egy szimpla ‘1’ azaz igaz értékre a Table::Store működése során.

More »

Az a feladat került elő, hogy az IIS szerverrel Windows 2012 R2 alatt ki kell váltani az Apache szerveren lévő szolgáltatásokat. A tesztelés során első lépésben előkerült a Web Platform Installer (ugyebár ezen keresztül lehet könnyen komponenseket, kiegészítőket telepíteni az IIS-re is), és már válogattuk is össze a szükséges komponenseket.

A telepítés után érdekes meglepetés fogadott minket, minden php oldal Server Error 500-ra ment. A logokban igazából lényegi infó nem volt azon kívül, hogy még a FastCGI csatolóval van a gond – azaz a PHP értelmezőig el sem jut a dolog.

A megoldás hosszas keresgélés és nyüglődés után az lett, hogy a Web Platform Installer nem ellenőrzi a futtatási prerequisitumokat, és a PHP-val nem telepíti együtt a futtatáshoz szükséges könyvtárakat. Ezt követően már nem okozott nagy gondot a hiba elhárítása, hisz csak le kellett tölteni, és telepíteni a hiányzó dolgokat:

Visual C++ Redistributable for Visual Studio 2012 Update 4 
arra azért vigyázni kell, hogy itt milyen verziót teszünk fel (x86, vagy x64), ez a telepített rendszertől és nem az op.rsz-től függ!

joomla-32.pngJómagam még csak most kezdek site migrációs oldalról kacsingatni a Joomla 3.x felé (igazából vártam a már majdnem végleges J! 3.2-t ezekhez) és így igencsak felkaptam a fejemet a Joomla Community Portal-n tegnap megjelent cikkre, mely a UPDATE ON 3.2.1 AND SECURITY ENHANCEMENTS címet viselte. Különösen akkor kezdtem el a szememet és a számat mozgatni (első pislogott, a második vigyorra futott) amikor megértettem miről is írnak. A teljes cikk fordításának nem sok értelmét látom hisz elolvasható a fenti linken, de a lényeget összefoglalnám:

  • A probléma a Joomla erős biztonsági jelszókezelésével lehetséges, amennyiben az oldal futtató környezetében nem áll rendelkezésre a PHP 5.3.7 vagy ennél nagyobb verziójú PHP motor.
  • Joomla 3.2 alapú éles oldal esetén – amennyiben minden rendben működik – teszt nélkül véletlen sem szabad kikapcsolni az erős jelszókezelési módot.
  • Joomla 3.2 alapú tesztelési, vagy fejlesztési oldal esetén előszeretettel kapcsolják be az új erős jelszókezelést, de költözéskor nem figyelnek már arra, hogy a PHP 5.3.7 vagy erősebb legyen. Az alacsonyabb PHP verziókban nem áll rendelkezésre az erős jelszókezeléshez szükséges kiszolgálói háttér, így annak eredménye egy nem stabil oldal lesz, ahol a bejelentkezéssel gond lesz. Tekintettel arra, hogy az erős jelszóról áttérni a gyengébbre (visszakódolni a hash-t) nem lehet, így ekkor a bejelentkezés nem fog működni.
  • Joomla 3.0/3.1 alapú éles oldal esetén nyugodtan telepítse a Joomla 3.2-s verziót és élvezze az előnyöket, de ne kapcsolja be az erős jelszókezelést a 3.2.1 patch megjelenéséig
  • Joomla 2.5 alapú éles oldal esetén nincs semmi teendője, mert a fent leírtak csak a 3.2 rendszerrel megjelent kódot érintik
  • Joomla 1.5 alapú éles oldal esetén ajánlott az áttérésre serkenteni a felhasználókat, mert a rendszer támogatása 2012 decemberében lezáródott. Természetesen a J! 1.5 oldalak ma is működnek, de ezekhez a projekt hiba- és security javításokat már nem készít

Mikor jelenik meg a Joomla 3.2.1?

Ennek dátuma jelenleg nem ismert, de a projekt erősen dolgozik rajta. Mindent megtesznek továbbá azért, hogy a most tapasztaltakat az ellenőrzési folyamatba beépítsék. Amennyiben bárki úgy érzi, hogy a tesztelési munkában szeretne részt venni akkor nézzen körül bátran a https://groups.google.com/group/jtesters oldalon.

Erős jelszó használatának letiltása

Amennyiben valaki nem tudja a fent említett funkció ki és bekapcsolása miként lehetséges, akkor képekkel tarkított leírást talál a http://docs.joomla.org/How_to_disable_the_Strong_Passwords_feature oldalon.

be44bedc8a2f068e6343d56452fd4574_LEgy fontos változás következik be a Joomla! projektben, ami igazából csak a fejlesztőket érinti, de őket nagyon. Megváltozik az MVC felület (és így a szolgáltatásai). Erről született egy cikk is amit a Joomla magazin 2013 novemberi számában lehet megtalálni.

Amennyiben valaki most kezd neki a komponens fejlesztésnek már eleve csak az új MVC architektúrát ajánlott használni (és természetesen már a fókuszban a Joomla 3.x legyen). Akik már fejlesztettek komponenst azok meg nézzék át miért is éri meg áttérni.

 

 

A legfontosabb változásokat az alábbi táblázatba foglalták össze:

Szolgáltatás

Jelenlegi MVC

Új MVC

Web Service támogatás

nincs

van

Megtanulhatóság

nehéz

könnyű

Vezérlők, Modellek, Nézetek

nagyon összetettek

egyszerű kiterjesztés

Kiterjeszthetőség

legacy osztályok

alap osztályok

Osztályok száma

kevesebb

komponensenként változó

Ezek után a már meglévő komponens kreátoromat újra kell írnom…