W związku z kolejną długą przerwą od wpisów, myślę, że tym z Was, którzy czytują mnie jakoś w miarę regularnie (są tacy? :P) należy się kilka wyjaśnień. Przyczyn takiego stanu rzeczy jest kilka, jedną na pewno jest fakt, że ostatnio ciężej jest mi się zmotywować i opisać jakiś temat na blogu - tak zwana prokrastynacja. Ponadto od kilku tygodni pracuję z kolegą nad kolejnym projektem - mam nadzieję pochwalić się nim już niedługo.

Chciałem jednak jednoznacznie przedstawić, jak wygląda sprawa kilku moich wcześniejszych "projektów", ponieważ już kilka osób się mnie o to pytało.

Sobak's Blog
Blog jak najbardziej jest kontynuowany. Nie planuję go zamykać czy coś w tym stylu. Obecny deficyt nowych wpisów, mam nadzieję, będzie tymczasowy. Co więcej, z blogiem (a raczej ogólnie stroną) łącze pewne przyszłe plany, które siłą rzeczy wiążą się z kolejnym projektem…

IronCMS 2
Przestój prac rzeczywiście występuje, publiczne informacje o postępie zatrzymały się na drugiej becie. Mimo tego, jest on dla mnie ważnym projektem i cały czas planuję go dokończyć. Aktualnie po prostu wskoczył na drugie miejsce w kolejce - za projekt, o którym wspomniałem na początku notki.

BrzydkiKod
Planowałem większą rewolucję wraz z uruchomieniem nowej wersji strony, ale ostatnio natknąłem się na projekt nospora - pr0.nospor.pl, który całkowicie wyczerpuje formułę pomysłu, który zacząłem realizować. W związku z tym, myślę że nie ma obecnie szans na kontynuację tej inicjatywy - jeśli już, to po prostu podeślę ze zbiorów coś do "konkurencji".

XNova/Blackout
Ktoś to jeszcze pamięta? ;) Ja praktycznie zapomniałem, ale pewna osoba mi przypomniała, więc warto rzecz wyjaśnić. Sprawa obecnie wygląda tak: projekt tego typu może zostać zrealizowany, jednak nie będzie to na pewno przeróbka XNovy, tylko coś pisanego od zera (bardzo możliwe, że z wykorzystaniem części rozwiązań z dostępnych silników). Trzeba jednak pamiętać że to co mam w kolejce spokojnie wystarczy mi na długi czas.

Zakładka projekty
Projekty jako zbiór doczekały się już kilku przeprowadzek. Swego czasu istniał dla nich osobny skrypt, potem zostały zwykłymi podstronami w WordPressie. Na nowej stronie moduł projektów będzie integralną częścią systemu, jednak będzie cechował się specyficznymi możliwościami, innymi od zwykłych podstron i dostosowanymi do wymagań. Krótko mówiąc: staram się połączyć zalety obu rozwiązań.

Jeśli chodzi o zawartość zakładki to część ze skryptów zostanie zakończona na obecnym etapie. Inne natomiast (główne klasy PHP) będą stale aktualizowane, bo zdaję sobie sprawę, że kurz już na nich osiadł no i jakość kodu nie jest najlepsza, dużo się w nim od tamtego czasu pozmieniało.

Jeśli ktoś z Was chce, abym wyjaśnił jeszcze jakąś kwestię o której zapomniałem to piszcie w komentarzach :)

Każdy, kto korzystał z WordPressa i ma w zwyczaju patrzeć jak jego strona wygląda "pod maską", z pewnością zauważył, że tytułowy CMS nie generuje najlepszego jakościowo kodu. Wynika to głównie z jego rozszerzalności i uniwersalności, ale nie oznacza to, że w prosty sposób nie możemy pozbyć się części nadmiarowego kodu HTML i CSS.

Usuwanie odwołania do RSD (Really Simple Discovery)
Mowa o następującym kodzie w nagłówku strony:

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://example.com/xmlrpc.php?rsd" />

Jest on używany przez klienty protokołu XML-RPC, np. Windows Live Writer. Jeżeli nie używasz go lub wspomniane nazwy po prostu nic Ci nie mówią, prawdopodobnie możesz bez obaw usunąć ten kod ze swojej sekcji head.

Jak to zrobić? To bardzo proste, dzięki wbudowanemu w WordPressa systemowi akcji, który pozwala także na ich usuwanie. Najlepszym sposobem będzie dodanie następującego kodu na koniec pliku functions.php w katalogu Twojego szablonu (wp-content/themes/Twoj_Theme/functions.php). Jeżeli plik o tej nazwie nie istnieje we wspomnianej lokalizacji, należy go utworzyć i wstawić poniższy kod w jego treść:

<?php
remove_action('wp_head', 'rsd_link');

Usuwanie odwołania do WLW (Windows Live Writer)
Odpowiada za niego następujący kod HTML w nagłówku bloga:

<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://example.com/wp-includes/wlwmanifest.xml" />

Jego przeznaczenie jest takie jak powyższego, co widać dokładnie po nazwie :) Jeśli chcesz go usunąć, to analogicznie do functions.php w katalogu Twojego szablonu (więcej wyżej) dodaj kod:

remove_action('wp_head', 'wlwmanifest_link');

Usuwanie wersji WordPressa (meta generator) Mówię oczywiście o tym:

<meta name="generator" content="WordPress X.X.X" />

Ten kod jest najprawdopodobniej zbędny. Skorzystać z niego będą prawdopodobnie tylko roboty przeszukujące sieć pod kątem starych wersji WordPressa, które będą podatne na ataki. Nic nie stoi więc na przeszkodzie, aby i jego usunąć. Na koniec wspomnianego pliku functions.php dodajemy kod:

remove_action('wp_head', 'wp_generator');

Linki relacyjne i nawigacyjne do wpisów
Wiele blogów generuje kod na kształt poniższego:

<link rel='index' title='Strona główna' href='http://example.com' />
<link rel='start' title='Pierwszy wpis' href='http://example.com/pierwszy-wpis/' />
<link rel='prev' title='Post poprzedni' href='http://example.com/post-poprzedni/' />
<link rel='next' title='Post następny' href='http://example.com/post-nastepny/' />

Na początku warto zaznaczyć, że ten kod może być często przydatny, korzystają z niego niektóre przeglądarki, aby ułatwić nawigację pomiędzy kolejnymi artykułami na stronie (np. Opera). Jeśli jednak uważasz, że takie rozwiązanie jest Ci niepotrzebne, możesz je usunąć dodając do functions.php:

remove_action('wp_head', 'start_post_rel_link'); // Odniesienie do pierwszego wpisu
remove_action('wp_head', 'index_rel_link'); // Odniesienie do strony głównej
remove_action('wp_head', 'adjacent_posts_rel_link'); // Odniesienia do postów sąsiednich (poprzedni, następny)

Cały plik functions.php
Czyli opcja dla leniwych

<?php
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
remove_action('wp_head', 'wp_generator');
remove_action('wp_head', 'start_post_rel_link');
remove_action('wp_head', 'index_rel_link');
remove_action('wp_head', 'adjacent_posts_rel_link');

Wyjaśnienie na koniec
Możesz też sobie zadać pytanie: dlaczego nie usunąć podanych fragmentów wprost z kodu WordPressa zamiast używać funkcji remove_action()? Odpowiedź jest bardzo prosta: przedstawione wyżej rozwiązanie nie narusza w żaden sposób rdzenia skryptu, w związku z czym zmiany nie zostaną utracone np. przy aktualizacji. Umożliwia też ono łatwe cofnięcie zmian - wystarczy usunąć odpowiednie wywołanie funkcji remove_action()

Mam nadzieję, że przedstawiona krótka porada przyda się Wam. Zawsze to zaoszczędzone kilka bajtów transferu :)

To znowu ja, powracający po chwilowej ciszy jaka zapadła na moim blogu. Można odczuć wrażenie, że ostatnie wpisy robią się lekko monotematyczne i w sumie jest to zgodne z prawdą. Bowiem dziś, równo po dwóch tygodniach od wydania na świat pożarcie testerom pierwszej bety IronCMS 2… pojawia się druga beta.

Wersja ta niesie ze sobą ponad 50 poprawek i nowych możliwości w odniesieniu do poprzedniej. Jestem bardzo zadowolony z pierwszych betatestów - pozwoliły mi wyłapać dużo błędów i zasugerować sporo zmian na lepsze. Nie wszystko zostało jeszcze ukończone, ale widzę duży progress względem poprzedniej wersji.

Właśnie dlatego chciałem znów złożyć małe podziękowania, należą się one (w kolejności ilości zgłoszonych błędów/propozycji tym razem): Kadetowi, Volixowi, Rapidwolfowi, Soanvigowi i Rodkanowi.

Nie ma co przeciągać. Osoby chętne do testowania zapraszam do kontaktu (zakładka w menu lub komentarz pod tym wpisem), odezwę się na podany adres email i pociągniemy ustalenia dalej.

Do usłyszenia! :)

Wszelkie wiadomości związane z nową wersją IronCMS (seria 2.x) na moim blogu ostatnio przycichły, można było się domyślać, że jest to kolejny projekt, z jakim rozmyśliłem się po kilku tygodniach pracy (na moim blogu można znaleźć takich kilka ;)). W tym momencie mogę jednak (z nieskrywanym zadowoleniem) ogłosić, że właśnie ukończyłem pierwszą betę IronCMS 2.

Ciężko mi nawet określić ile czasu nad nią pracowałem. Pamiętam, że minimum 2 razy porzucałem cały dotychczas napisany kod, aby rozpocząć od nowa (raz na dalekim etapie). Nie potrafię też powiedzieć czy zabieg się opłacił - widzę jednak efekt. Można powiedzieć, że skrypt jako tako działa. Na pewno jest w nim dużo błędów, ponadto trzeba wziąć pod uwagę, że w tej wersji umyślnie wielu rzeczy nie skończyłem - po prostu. Bo mogę :) Będę je dorabiał stopniowo, jak na razie jestem po prostu zadowolony, że udało mi się skończyć jakiś wyraźny etap.

Cyferki

Teraz nadszedł czas na troszkę nudnych liczb. Poniżej przedstawiam statystykę linii kodu źródłowego - z podziałem na moją własną robotę oraz pełny skrypt wraz z bibliotekami zewnętrznymi (mój skrypt korzysta m.in. z parsera BBCode od Wookieba oraz GeSHi do kolorowania składni).

Kod PHP (całość)
13 353 linijki kodu (dodatkowo 1472 puste linie i 2542 linie komentarzy) - łącznie 17 367 linii.

Kod PHP (własny)
4772 linie kodu (dodatkowo 724 puste linie i 134 linie komentarzy) - łącznie 5 360 linii.

Duża rozbieżność pomiędzy ilością kodu własnego i tego ze źródeł zewnętrznych wynika ze stopnia rozbudowania i elastyczności bibliotek - mówiąc inaczej: duża ilość kodu nie jest wykorzystywana obecnie przez CMS - przykład: kolorowania składni dla wielu języków zawartych w GeSHi).

Chciałem pokusić się też o statystykę dla kodu CSS/JavaScript, ale do stworzenia szablonu strony został użyty Twitter Bootstrap, więc sytuacja wygląda jak wyżej, po pierwsze: ogromna ilość kodu nie jest jeszcze (albo nigdy nie będzie) używana, a po drugie, ciężko było by mi rozdzielić ile z tego kodu to moje dodatki/modyfikacje, a ile jest dziełem autorów Bootstrapa/szablonu na nim opartego. Mogę tylko powiedzieć, że skrypt został uzbrojony w 8141 linii czystego kodu CSS, bez rozdzielania na autorów.

Testy

Zgodnie ze wcześniejszymi zapowiedziami, aktualnie kod źródłowy skryptu nie będzie dostępny publicznie. Nie chcę po prostu Was straszyć moimi wymysłami, dam sobie jeszcze trochę czasu na wprowadzenie wielu istotnych poprawek. Właśnie dlatego, w tej chwili rozpoczną się pierwsze betatesty IronCMS-a. Wszystkich zainteresowanych testowaniem zapraszam do kontaktu.

Screeny?

Czyli jak pokazać coś, tak, aby nie wyjawić nic :) (Kliknij na obrazek, aby przejść do pełnych wymiarów).

Co my tu mamy? Na pierwszym screenie jawi nam się duże zdjęcie w topie (nie moje) i kawałek podstrony (moje), na drugim znajduje się panel administracyjny pokazany poprzednio, a więc jak najbardziej nic nowego.

Zakończenie?

Co na koniec? Jak zwykle podziękowania. Z tego miejsca podziękowania wędrują do (w porządku alfabetycznym, żeby mnie nie pogryziono): CapaciousCore, m4tx'a, Marcina, Rhino, Rodkana, Thelleo, Volixa i wszystkich innych, którzy pomagali mi na rozmaite sposoby w osiągnięciu celu.

Być może część z Was zauważyła już, że w górnym (a w zasadzie aktualnie jedynym) menu strony pojawiła się nowa zakładka. Jej nazwa, to nic nikomu niemówiący BrzydkiKod. Cóż to znowu za poroniony pomysł zrodził się w Sobaczym umyśle?

Otóż, przeglądając ForumWeb natknąłem się na post osoby, która szukała pomocy z niedziałającym kodem. Sytuacja stara jak świat, kod też nie należy wcale do najgorszych jakie widziałem. Tym razem jednak wpadłem na pomysł. Postanowiłem zachować sobie ten kod na pamiątkę (na zasadzie: "Nie, Sobak, tak tego nie rób"). Jednak stwierdziłem, że skoro już i tak zachowuję kod na pamiątkę, to czemu nie podzielić się nią z innymi?

Właśnie w ten sposób powstała ta podstrona. Jako składnica kodów, które w jakiś sposób mnie zaintrygowały i w pewnym sensie nauczka dla potencjalnych następców. Zaznaczam też, że nie zamierzam tam publikować ocen większych skryptów, to ma być coś na wzór spinnetów… tylko, że zrobionych nie tak jak trzeba.

Jeszcze krótki disclaimer: strona nie powstała, aby ośmieszyć lub oczernić kogokolwiek. Bazuje ona na materiałach, do których uzyskałem legalny dostęp. Żeby nie było, że zamierzam się dowartościowywać czyimiś błędami, to na wspomnianej liście znajdą się także moje genialne wymysły ;)

Amen.

Uwaga: ten wpis jest ciężki do czytania, zaplątany, niepoukładany i w zasadzie nie ma celu poza przekazaniem kilku luźnych przemyśleń. 

Dziś uderzam do Was z takim zbiorem przemyśleń zapoczątkowanych jednym konkretny wydarzeniem. Mój kolega, Soanvig, zwrócił mi uwagę na fakt, że strona hostingu YoYo.pl nie odpowiada. Nawet nie wyobrażacie sobie jak bardzo ucieszyłem się z tego faktu :D To nie jest tak, że ja nie lubię YoYo.pl, nieee… ja po prostu nie znoszę większości stron na nim hostowanych.

Co mi w nich przeszkadza? Czy to, że są na słabym poziomie? Nie, bo to można spokojnie powiedzieć o mojej stronie, tak jak o każdej innej. Rozchodzi mi się o to, że yoyo.pl stało się niesamowitym wysypiskiem. Miejscem, które nie było sprzątane od lat. Pamiętam, że koło 1,5-2 lat temu nudząc się, z pomocą kolegi napisałem listę ponad 100 stron w domenie yoyo.pl, które ewidentnie łamały ich regulamin. Dodatkowo: do każdej z wymienionych stron podałem punkt regulaminu, na podstawie którego powinna zostać usunięta. Całą listę wysyłałem do nich chyba trzykrotnie - oczywiście z odpowiednim odstępem czasowym. Reakcji nie ma do dziś, jak nie trudno się domyślić.

Lista 100 stron może brzmi w jakiś sposób imponująco, jednak tego samego dnia, gdy ją stworzyłem, w serwisie YoYo założono ponad 350 nowych stron. Teraz pomyślcie: ile z nich przetrwa więcej niż miesiąc? Obstawiam, że niewiele. Ile z nich zostanie skasowane, gdy właściciele zrezygnują z pomysłu prowadzenia strony? Pewnie żadna… Tutaj warto też wspomnieć o tym, że większość z tego co zawarłem na liście wysłanej do YoYo, to były strony gdzie instalacja nie została dokończona lub była nieprawidłowa i strona sypała błędami PHP, tak więc nie ma mowy o tym, aby taki materiał mógł być jakoś przydatny.

I to jest według mnie istota problemu. Zalew informacji w internecie jest ogromny, ale dużo z tego chaosu rodzi się ponieważ… ludzie po prostu po sobie nie sprzątają. Z drugiej strony wiele firm poważnie utrudnia usuwanie tego, co raz już się do internetu wrzuciło. Właśnie dlatego nie obraziłbym się gdyby tak duży gracz jak YoYo zniknął. Ciekawe o ile odetchnąłby index polskich stron w Google? :D

To tyle ze zbioru luźnych przemyśleń. Mam nadzieję, że ten output z mojego mózgu w jakikolwiek sposób nadaje się do czytania. Tymczasem YoYo.pl nie odpowiada już kolejną godzinę (z błędu 503 przerzuciło się w międzyczasie na błąd 504 - jakaś inkrementacja czy co? xD czekam na 666). Ponadto zauważyłem że należące niegdyś do nich forum WebTips.pl przekierowuje na całkiem inny adres - nie wiem czy to nowa sytuacja czy coś starszego, ale mam nadzieję, że cała konstrukcja wkrótce runie.

PS: O YoYo pisałem już w kontekście bugu na ich stronie.

Zgodnie z zapowiedzią, dzisiejszy wpis będzie nakreślał aktualny stan prac nad IronCMS-em 2. Nie chciałbym, aby projekt sprawiał wrażenie porzuconego, bo tak zdecydowanie nie jest.

W wyniku kilku dyskusji i przemyśleń postanowiłem zmienić drastycznie jeden z aspektów skryptu – aktualnie jestem na etapie wdrażania prostego systemu szablonów na potrzeby CMS-a. Przyjął on formę znaną z wielu frameworków webowych (nie tylko PHP) i obecnych tam widoków. Mówiąc krótko i zwięźle – pliki szablonów są pisane z użyciem PHP (i w przyszłości kilku rozsądnych helperów ułatwiających pracę). Powodów, dla których odrzuciłem koncepcję użycia rozbudowanego systemu szablonów z dedykowaną składnią (np. Smarty, Twig) jest kilka, ale to może przedstawię przy innej okazji.

Co jeszcze zmieniło się w CMS-ie od ostatniego wpisu o nim? Przede wszystkim zostały ukończone kolejne kluczowe elementy – system komentarzy jest gotowy niemalże w połowie, funkcja bloga na której chciałem się skupić została już prawie ukończona. Skończone zostało dodatkowe kilka podstron, widocznych zarówno dla odwiedzającego stronę jak i dla administratorów. Gotowy jest praktycznie cały panel administracyjny.

Powyższy screenshot pokazuje z grubsza jego wygląd i układ. Wspomniany wcześniej system szablonów obejmie także panel administracyjny, tak więc nic nie będzie stało na przeszkodzie, aby przygotować alternatywne wersje panelu administracyjnego – np. wersję lite czy mobilną.

Aktualnie kluczowymi elementami do ukończenia są: system komentarzy,poprawki do parsera BBCode oraz wspomniany system zmiany szablonów. Po wykonaniu tej pracy ukaże się wersja beta, przeznaczona do skatowania przez grono zażartych testerów. Dopiero po tym rozpocznie się faza wdrażania mojego potworka na sobak.pl :)

Korzystając z okazji chciałbym pozdrowić Thelleo, który intensywnie rozwija swój system zarządzania treścią - LunaCMS.

Witajcie, w dzisiejszym wpisie chciałbym przedstawić Wam jedno z narzędzi przydatne przy tworzeniu projektów (i to nie tylko typowo webowych). Bohaterem dzisiejszego wpisu będzie TypeFriendly, czyli generator dokumentacji, manuali czy podręczników.

TypeFriendly to skrypt PHP działający w konsoli (CLI), napisany przez Tomasza „Zyxa” Jędrzejewskiego. Jest dostępny jako open source. Autor przedstawił inne podejście do tworzenia dokumentacji niż autorzy np. phpDocumentatora (phpDoc). Zamiast bazowania na setkach komentarzy porozrzucanych po plikach PHP i opisujących poszczególne zmienne, funkcje, metody czy klasy, TypeFriendly generuje dokumentację na bazie plików w specjalnym formacie – jednakże tworzonych w całości przez użytkownika. To powoduje, że może być on wykorzystywany nie tylko do PHP lub w ogóle nie do programowania – można w nim po prostu stworzyć dowolny podręcznik.

Materiał wejściowy dla skryptu to zbiór plików *.txt o ustandaryzowanych nazwach i zawartości opisywanej za pomocą składni Markdown z pewnymi ulepszeniami i dodatkami. Autor bardzo intuicyjnie przewidział tworzenie poszczególnych rozdziałów z nieskończoną ilością zagnieżdżeń, tworzenie linkowania pomiędzy nimi oraz takich elementów jak spisu treści. Większość elementów nawigacyjnych jest generowana automatycznie na podstawie pewnych szczególnych tagów dodawanych do każdego pliku oraz nazw tych plików.

Składnia Mardown została wzbogacona o możliwości, które mogą okazać się przydatne przy tworzeniu różnego rodzaju manuali – między innymi automatyczne kolorowanie kodu z użyciem GeSHi czy wstawianie różnego rodzaju wskazówek, ostrzeżeń czy informacji do tekstu.

Skrypt wspiera bezproblemowo opcję tworzenia dokumentacji w wielu językach. Dużym plusem jest też fakt, iż na bazie tego samego materiału wejściowego (czyli zbioru odpowiednich plików *.txt) TypeFriendly jest w stanie wygenerować kilka rodzajów podręczników (różniących się głównie nawigacją pomiędzy poszczególnymi częściami) oraz kilka ich formatów – aktualnie dostępna jest możliwość generowania osobnych rozdziałów w osobnych plikach lub wygenerowanie wszystkiego w jednym duży pliku HTML.

Żeby nie rozpisywać się już zbytnio, o tym co niepotrzebne – skrypt został zaopatrzony w bardzo dobrą dokumentację – wygenerowaną oczywiście w nim samym ;) Z własnego doświadczenia mogę powiedzieć, że jego użytkowanie nie wymaga dużego nakładu pracy, a efekty bardzo szybko się zwracają w postaci uporządkowanych i estetycznych podręczników.

Skrypt i wspomniana dokumentacja jest dostępna do pobrania na stronach grupy Invezzia zajmującej się jego tworzeniem i rozwojem.

Mam nadzieję, że ta lekko chaotyczna prezentacja skryptu zachęciła Was do skorzystania z niego. Jeśli ktoś zakładał tworzenie dokumentacji dla swojego projektu, to przedstawione rozwiązanie ułatwi i przyspieszy ten proces.

Ostatnio znów zrobiło się ciszej z nowymi wpisami - tym razem powodem jednak nie było lenistwo, a przynajmniej nie w czystej postaci ;) Od dłuższego czasu pracuję nad nowym skryptem - tak tak, tytuł to nie żart - ci z Was, którzy pamiętają mój projekt o nazwie [IronCMS][portfolio-ironcms] mogą być lekko zaskoczeni, ale to prawda - aktualnie tworzę drugą wersję tego skryptu o jakże odkrywczej nazwie - IronCMS 2.

Różnic w odniesieniu do poprzedniej gałęzi będzie sporo - całkowicie napisany od nowa kod źródłowy, ale także kilka zmian w podejściu. Pierwsza i zasadnicza - skrypt nie będzie dostępny publicznie… przynajmniej na razie :) Przed ewentualnym wydaniem zostanie na pewno dobrze przetestowany i poddany próbie bojowej (już wkrótce więcej o tym). Do ewentualnego wydania na światło dzienne kod zachowam dla siebie, jednak będę się starał Was informować o ważniejszych zmianach w nim - to będzie także sposób na motywację dla mnie.

Wstępna data premiery wersji 2.0 jest już wyznaczona, jednak nie chcę jej jeszcze podawać, aby nie czuć się zobligowany żadnymi terminami. Przed premierą na pewno odbędzie się minimum 10 dni zamkniętych betatestów, w których poprawię najważniejsz znalezione błędy. Po premierze zaś, zbiorę wnioski wynikające po używaniu CMS-a w praktyce i niedługo po niej prawdopodobnie zacznę przygotowywać kolejną wersję z adekwatnymi poprawkami.

Jeśli chodzi o zastosowane rozwiązania, to od wydania ostatniej wersji IronCMS-a minęło prawie półtora roku (27.06.2011 - [wersja 1.2.1][ironcms-121]). Sądzę, że przez ten czas zebrałem jednak trochę nowych doświadczeń, z których będę mógł skorzystać przy swojej pracy.

Myślę, że dziś to będzie na tyle - nie chcę przeciągać tego wpisu bez potrzeby. Przed premierą powinien się ukazać jeszcze minimum jeden wpis o IronCMS-ie w wersji 2.0  - prezentacja screenów czy coś - zwyczajna marketingowa papka :D

Pozdrawiam.

[ironcms-121] [portfolio-ironcms]: https://sobak.pl/projects/iron-cms/

Witajcie po bardzo długiej przerwie. W wyniku kilku spraw nie mogłem znaleźć weny i czasu na naskrobanie czegoś na bloga. Nadszedł czas troszkę to nadrobić - zacznę, mam nadzieję, konkretnie.

Dziś na warsztat pójdzie sprawdzanie typu pliku na podstawie jego MIME. Jak dobrze wiadomo, sprawdzanie po rozszerzeniu jest niepewną i ryzykowną formą - rozszerzenie można zmienić, a nieraz (wskutek takiej czy innej konfiguracji serwera) można wykonać plik zamaskowany rozszerzeniem .jpg jako normalny plik PHP. Potencjalnych skutków chyba nie trzeba opisywać ;) Przechodząc do rzeczy:

1) Korzystając z klasy Fileinfo
To rozszerzenie PHP powstało właśnie do tego celu i jest aktualnie najlepszą metodą na osiągnięcie naszego celu. Poniżej krótki i treściwy przykład działania klasy.

<?php 
$file1 = 'image.png'; // Faktyczny obrazek w PNG
$file2 = 'kod.png'; // Plik PHP ze zmienionym rozszerzeniem

$finfo = new finfo(FILEINFO_MIME);

echo $finfo->file($file1, FILEINFO_MIME_TYPE); // Wyświetli: image/png
echo $finfo->file($file2, FILEINFO_MIME_TYPE); // Wyświetli: text/x-php

W tym miejscu już doskonale widać przewagę tego rozwiązania nad sprawdzaniem rozszerzenia pliku - oszust został zdemaskowany.

2)  Poprzez funkcję mime_content_type
Uwaga, ten sposób jest gorszy! Wspomniana funkcja została zdeprecjonowana, więc nie powinno się jej używać. Jednakże dosyć często zachodzi sytuacja, w której na serwerze nie jest dostępna pierwsza metoda (klasa fileinfo), a możemy użyć owej funkcji - dlatego o niej wspominam.

<?php
echo mime_content_type('php.gif'); // Wyświetli: image/gif

3) Sprawdzanie typu pliku po jego zawartości Każdy typ pliku zawiera na swoim początku zestaw charakterystycznych dla niego kilku bajtów. Sprawdzając je, możemy określić typ pliku - należy jednak wspomnieć, że to właśnie z tej metody korzystają powyższe rozwiązania, więc zabawę z ręczną jej implementacją możemy rozpocząć gdy jesteśmy zdesperowani i nie mamy żadnej z powyższych możliwości.

Poniżej krótki przykład, pobranie trzech pierwszych bajtów pliku, skonwertowanie ich do postaci heksadecymalnej i porównanie ich z bajtami charakterystycznymi dla pliku MP3

<?php
$file = fopen('plik.mp3', 'r');
$bytes = bin2hex(fread($file, 3));

if($bytes == '494433') {
    // Sprawdzany plik jest plkiem MP3
}
else {
    // Inny plik
}

fclose($file);

Dużą listę takich charakterystycznych bajtów możecie znaleźć tutaj, można też skorzystać z serwisu FileExt.com.

Mam nadzieję, że komuś przydał się ten wpis. Dziękuję za uwagę :)