29
czerwca
2010
Podczas pracy z Joomla! widziałem już sporo ogólnodostępnych komponentów i modułów w akcji. Z reguły jest miło i przyjemnie do jednego momentu - chwili w której trzeba trochę zmodyfikować styl/strukturę modułu lub komponentu. W poniższym wpisie chciałbym zaprezentować pięć najbardziej drażniących motywów z którymi wielokrotnie się spotkałem w czasie pracy.
Podstawowa bolączka wielu modułów, wynikająca prawdopodobnie po części z niewiedzy, po części z lenistwa programisty. Nieświadomym przypominam, że katalog tmpl/ zawiera pliki ze strukturą generowaną przez konkretny moduł, które można w łatwy sposób nadpisać w danym szablonie. Zaleta ? Przenosząc szablon na inną instalację Joomla! nie musimy tworzyć własnych wersji plików modułu, które trzeba przenosić z szablonem - wszystko mamy w jednym miejscu. Przy tworzeniu szablonów dla większego grona klientów jest to wręcz jedyne sensowne rozwiązanie (bo typowy klient nie lubi gdy poza zainstalowaniem szablonu każemy mu jeszcze podmienić jakieś pliki/katalogi).
Joomla! 1.5.* od początku wykorzystywała framework MooTools po stronie back-endu i ma wbudowane dla niego wsparcie po stronie front-endu. Dlatego zupełnie nie rozumiem ludzi, którzy tworzą rozszerzenia dla Joomla! z użyciem jQuery. A już zupełnie nie trawię ludzi, którzy tworzą rozszerzenia dla Joomla! w jQuery i nie stosują funkcjonalności noConflict. Problemy na bardziej złożonej stronie są wtedy wręcz gwarantowane, a o dodatkowym transferze nie wspomnę (nie ma to jak dwa frameworki JavaScript o zbliżonych możliwościach, zastosowane na jednej witrynie). Podsumowując - w światku Joomla! , a szczególnie świecie ogólnodostępnych rozszerzeń lepiej zapomnieć o swojej miłości do jQuery - dla dobra użytkowników.
Kolejny "klasyk" - osobiście rozumiem, że nieraz trzeba zastosować atrybut style do określenia szerokości danego modułu, czy wysokości kontenerów - przy elastyce Joomla! jest to wręcz niezbędne by uniknąć gigantycznej sekcji head z masą znaczników style. Nie rozumiem natomiast zupełnie jak można w ten sposób definiować takie rzeczy jak styl obramowania czy kolor czcionki. Widziałem takie cuda i to o zgrozo także w płatnych komponentach.
W komponencie Jomsocial ktoś wpadł na pomysł zastosowania skryptów do tworzenia tooltipów. I wszystko działałoby pięknie i ładnie, gdyby nie to, że wszystkie style tych tooltipów były generowane przez... skrypt JavaScript. Fantastyczna sprawa, szczególnie w wypadku tworzenia efektu zaokrąglonych rogów dla tych tooltipów, które w wypadku IE były generowane jako elementy w języku VML i nijak nie szło się ich pozbyć bez ingerencji w kod komponentu.
Pora na "kwiatek" z komponentu K2 w której zawarto w stylu CSS zupełnie bezstresowo taki oto zapis:
.even{...}
.odd{...}
A teraz proszę sobie wyobrazić co mogło się stać z wszystkimi szablonami i modułami używającymi tych klas ;)
Ja wiem, że to kilka znaków więcej, ale naprawdę warto wyposażyć swoje moduły/komponenty w głównym kontenerze w jakąś charakterystyczną klasę / identyfikator, która może i wydłuży ciut kod CSS:
.dziudek .even{...}
.dziudek .odd{...}
Ale zaoszczędzi masy nerwów i analizowania potencjalnym użytkownikom ;)
I na koniec absolutny klasyk - nieczytelny kod. Wielu ludzi sobie chyba nie zdaje sprawy, że zamiast klamerek w PHP można stosować takie słowa kluczowe jak:
Mógłbym w tym miejscu wkleić kilka znakomitych kawałków nieczytelnego kodu, ale po prostu wręcz nie mogę na nie patrzeć. Naprawdę warto na koniec swojej pracy rzucić okiem w kod i zastanowić się czy jest on chociaż odrobinę czytelny dla innego użytkownika.
Podsumowując to zacne zestawienie - warto poświęcić odrobinę czasu i zastanowić się czy to co puszczamy w świat zadziała w ogóle u innych użytkowników, a jeżeli tak to warto się zastanowić czy ciężko jest dostosować nasze dzieło do różnych szablonów. Bo nawet najbardziej funkcjonalny moduł/komponent nie będzie użyteczny dopóki nie będzie się dawał względnie łatwo zmodyfikować.
01
czerwca
2010
Jeżeli ktoś z czytelników bloga korzysta na swojej stronie opartej na Joomla! z komponentu CKForms to apeluję o wyłączenie tego komponentu dla własnego bezpieczeństwa.
Dziś kolega zaprezentował mi dziurę w tym komponencie, która pozwala na zrobienie właściwie wszystkiego z serwerem na którym postawiona jest strona z wspominanym komponentem. Informacja została wysłana do zespołu tworzącego CKForms, ale jak dotąd nie uzyskano odpowiedzi ani tym bardziej aktualizacji komponentu, którego ostatnia wersja z tego co widzę pochodzi z 20 marca.
18
kwietnia
2010
Gdy zajmujemy się wdrażaniem rozszerzeń dla Joomla!, które są używane do wyświetlania tekstów w różnych językach może pojawić się problem z kodowaniem znaków lub błędnym obliczaniem pozycji znaków w tekście. Wszystkiemu winne są funkcje PHP służące do operowania na ciągach znaków.
Standardowe funkcje PHP takie jak np. substr, stripos nie są przystosowane do operowania na ciągach znaków w których znak może być reprezentowany jako więcej niż jeden bajt. W UTF-8 niektóre znaki są reprezentowane właśnie w taki sposób. Stąd powstało rozszerzenie dla PHP - Multibyte String - jego cechą charakterystyczną są funkcje z prefiksem "mb_". Co jednak jeżeli przygotowujemy rozszerzenie dla szerszego grona użytkowników z których nie każdy posiada zainstalowane u siebie takie rozszerzenie ?
Rozwiązaniem problemu w takiej sytuacji jest klasa JString - jest ona swoistą nakładką na bibliotekę PHP UTF-8, która wchodzi w skład standardowych bibliotek dostarczanych razem z Joomla!.
Po zaimportowaniu klasy JString:
jimport('joomla.utilities.string');
możemy swobodnie korzystać z funkcji operujących na ciągach znaków, które poradzą sobie z UTF-8.
Pełna lista metod tej klasy znajduje się na tej stronie. Nie ma sensu ich tutaj kolejno opisywać gdyż są to po prostu odpowiedniki funkcji znanych z PHP. Jedyną niestandardową metodą jest transcode, która bazuje na rozszerzeniu iconv i pozwala na konwersję ciągu znaków z jednego kodowania na inne (w tym wypadku z UTF-8 na ISO-8859-2):
JString::transcode('UTF-8', 'ISO-8859-2', $text);
Wszystkie metody klasy JString są statyczne więc przykładowo wywołanie metody substr ogranicza się do zapisu:
JString::substr($text, 0);
Dzięki funkcjonalnościom tej klasy unikniemy sytuacji w której użytkownik z Grecji żali się nam, że nasz moduł wyświetlający skróty artykułów zamiast znaków jego alfabetu wyświetla znaki zapytania :)