Dzisiaj będzie szybko, krótko, treściwie, niczym po żołniersku Jestem zakręcony z powodu kończenia kolejnego projektu dla klienta oraz poniedziałkowego wylotu do ciepłych krajów; szok, że udało mi się coś nowego napisać (ale o prokrastynacji i GTD będzie innym razem, obiecuję).

Kohana Projects to długo oczekiwany serwis (oparty na popularnym ostatnio (tfu) Railsowym Redmine) mający za zadanie w jednym miejscu zgromadzić wszystkie “okołokohanowe” projekty. Podoba mi się. Może nie sam system (bo trochę bałaganu w nim jest), ale sam fakt zebrania wszystkiego do kupy. Widzę, że ilość dodatków systematycznie wzrasta. Super.

Kohana Debug Toolbar to pierwsza perełka wygrzebana na tym serwisie. Jeżeli ktoś miał styczność z Symfony to z pewnością jest zaznajomiony z tym widokiem:

KDT to udana próba przerobienia standardowego profilera w ten znany z Symfony. Dodatek jest fantastyczny. Takie proste a tyle radości Profiler często “wykrzaczał” mi layout, wydłużał stronę i w ogóle dostarczał innych niepożądanych wizualnych efektów. Z KDT problem mamy z głowy, dane mamy pod ręką, jedynie trochę więcej musimy się naklikać

Kończąc te “kohane” wiadomości nie sposób pominąć Naszej Kohany czyli inicjatywy osób związanych z polskim forum kohany. NK to odpowiedź na ogromne zapotrzebowanie na jakąkolwiek literaturę o KohanaPHP w naszym języku. Lektura obowiązkowa dla początkujących (których ostatnio jest coraz więcej i którzy reprezentują coraz to niższy poziom wiedzy :/ ).

Dzisiaj taka mało przyjemna sprawa :/ Jakiś czas temu pewna osoba dostała maila, którego można by streścić słowami: “wasza aplikacja jest dziurawa, mam hasła do bazy, proponuje 150zł i wykonam odpowiednie poprawki bezpieczeństwa”. Śliska sprawa tym bardziej, że napisała to osoba udzielająca się na polskim forum Kohany, notabene także czytelnik tego bloga Nie chce tego komentować, za to proponuje lekturę wpisu Vagli. Skupmy się na samym problemie.

Problem dotyczy frameworka KohanaPHP od wersji (chyba 2.2) w której dodano internal cache w konfiguracji. Internal cache to solidny kop wydajnościowy uzyskiwany poprzez zbuforowanie na ustalony okres czasu całej konfiguracji frameworka oraz wszystkich ścieżek dostępu. Zserializowane tablice są zapisywane w formie tekstowej w katalogu /application/cache/. Nie jestem teraz w stanie stwierdzić czy złą konstrukcję .htaccess posiadała oficjalna paczka z tego czasu czy to jest kwestia indywidualnych zmian. Ważne jest abyście sprawdzili swoje poprzednie produkcje i mieli to na uwadze zestawiając nowe (jednocześnie zmieniając .htaccess standardowo dostarczany z frameworkiem). W każdym razie zestawienie inne niż kierowanie wszystkiego (z pominięciem np. css/img/js itp.) na index.php może spowodować to, że ów katalog z cache będzie swobodnie dostępny z poziomu przeglądarki, a tym samym dostęp do loginu/hasła do bazy danych stoi otworem

ps. to też jeden z powodów dla którego zawsze sugeruję przenoszenie katalogów z aplikacją i frameworkiem POZA katalog główny (tzw. webroot) dostępny na zewnątrz. W Kohanie jest to bardzo proste do uzyskania: edytujemy plik index.php zmieniając $kohana_application, $kohana_modules i $kohana_system na odpowiednie ścieżki (np. "../enginemojejstrony/application").

Kilka dni temu pojawił się nowy skrypt, który powinien was zainteresować. Pisząc “was” mam na myśli tą część, która wielokrotnie wyrażała chęć obejrzenia czyjegoś projektu napisanego w Kohanie na forum.php.pl czy też na forum.kohanaphp.pl.

Otóż system wymiany linków e-weblink.com udostępnił skrypt e-webcities służący do kolokwialnie mówiąc nabicia sobie punktów w systemie (czytaj: powiększenia zaplecza, zindeksowania, zwiększenia site: itd.). Pominę cały ten aspekt SEO (zainteresowanych odsyłam do wpisów: “E-WebCities – czyli zaplecze na wyłączność” i “Zaplecze i moje w nim nowe trendy“) i skupię się na samym projekcie.

Demo skryptu znajduje się pod adresem ewebcites.info, skrypt wraz z instalacją e-weblinka dostępny jest po zalogowaniu się do systemu. Drobna sugestia: jeżeli przygotowujecie paczkę do masowego rozpowszechniania to zadbajcie o skasowanie zbędnych plików, a tych dostarczanych domyślnie wraz z Kohaną jest sporo (tutaj widać wersję 2.1 gdzie modułów jest kilka, ale już najnowsza wersja ma ich… 11! Swoją drogą developerzy Kohany powinni katalog /modules dołączać opcjonalnie). Poza skasowaniem katalogu /modules (tego czego nie używa się w projekcie, ale to chyba oczywiste ). Warto zrobić czystki w /system/libraries (szczególnie /drivers) i /system/i18n (w większości wypadków nie potrzebujemy 14 tłumaczeń). Autor zmodyfikował nieco core frameworka (m.in. widać zmiany w funkcji config::item) więc ostrożnie z adaptacją tego do swoich projektów opartych na oryginalnej Kohanie. I to w zasadzie tyle, nie ma co opisywać, lepiej samemu spojrzeć. Myślę, że ci którzy mają problem z załapaniem MVC i pisaniem w Kohanie będą usatysfakcjonowani nową pomocą Osobiście irytuje mnie używany tam sposób routingu (tyle pisaniny dla każdej akcji, mała elastyczność) ale to są już prywatne przyzwyczajenia – dyskusja na ten temat była by tak samo bez sensu jak przy tej czy stosować camelCase czy under_line

Jeżeli ktoś ma jakieś pytania to można zostawić w komentarzach – autor pewnie zajrzy i odpowie

Dzisiaj parę słów o bibliotece Validation i nowym komponencie FORge (Form Generation – na razie w SVN, będzie wraz z 2.1). Może na początek coś na temat “zwykłej” walidacji danych. Jakiś czas temu na jednym z blogów przeczytałem o Kohanie: “głupie zwalidowanie formularza wg oficjalnej strony wymaga jakiejś niesamowitej ilości kodu”. W pierwszej chwili zgłupiałem (bo prościej już chyba być nie może), dopiero po chwili dotarło do mnie, że jeden z poradników (polskie tłumaczenie) robi niedźwiedzią przysługę temu frameworkowi Autor coś tam nakombinował, namęczył się, zamieszał, a wszystko po to aby docelowo było łatwiej Nie jestem zwolennikiem takich rozwiązań więc daruje sobie moja ocenę tego, zamiast tego pokaże wam jak to można zrobić w najprostszy z możliwych sposobów.
(więcej…)

Zdumiewającą wiadomość ogłosił na swoim blogu jeden z developerów CI i pracownik EllisLab. Otóż poinformował, że NIE zanosi się na jakiekolwiek zmiany w kwestii przejścia na PHP5, co więcej, opierając się na jakiś (mniej lub bardziej wiarygodnych; dla mnie mniej) danych nt. migracji serwerów z php4 na php5 pozwolił sobie na żart, że w tym tempie to mogą o tym pomyśleć najwcześniej w 2010 r.

Powiem szczerze: te tłumaczenia są dla mnie co najmniej śmieszne. Nie wiem jaka była metodologia tych badań, ani z jakich hostingów oni korzystają ale mi nie zdarzyło się od na prawdę dłuższego czasu, aby na serwerze nie było php5. Jeżeli nie samo, jeżeli nie główne to zawsze jako dodatkowa opcja (sposób przestawienia wersji na całe konto albo po prostu osobne parsowanie rozszerzeń *.php i *.php5). Wystarczy przejrzeć oferty hostingowe, choćby na webhostingtalk.com, aby dojść do podobnych wniosków. Swoja drogą, widzę, że ów wpis ma raczej pozytywne komentarze Albo my żyjemy w innym świecie albo po prostu wszyscy przechodzą na Kohanę i z CI zostają już tylko zwolennicy php4

Skłamałbym mówiąc, że mnie to martwi. W ogóle. Raczej mnie rozbawiło, i to bardzo W sytuacji kiedy KohanaPHP czerpie z największych zalet CI, poprawia setki ograniczeń i błędów poprzednika, a jednocześnie korzysta z dobrodziejstw php5 (przecież tu nie chodzi o zmianę samego numerka i końca wsparcia dla php4!) to sytuacja staje się jasna.

RIP dziadku CodeIgniterze. Bardzo przyjemnie się z tobą pracowało. RIP.