Pomocnik webmastera

Pisząc skrypt w języku PHP nie zawsze jesteśmy pewni efektów. Czasami w najmniej spodziewanym momencie może się pojawić błąd. Oto przykładowy skrypt:

$b=0;
$a=100/$b;

Oczywiście na ekranie pojawi się komunikat błędy podobny do tego: Warning: Division by zero in /home/user/public_html/katalog/err.php on line 3

Oczywiście jest to celowy przykład błędu. Zazwyczaj jest tak, że wartość zmiennej b nie jest na sztywno przypisana, ale np. jest pobierana z bazy i masz pewność, że nigdy nie będzie zerem, ale na skutek kilku nieprzewidzianych okoliczności, jednak jej wartość wynosi zero i pojawia się owy błąd z dzieleniem przez zero.

Najprościej by było przed dzieleniem dać jakiegoś if’a w celu zabezpieczenia się przed taką sytuacją, ale tutaj znów nie zawsze da się przewidzieć takie sytuacje. Również testując własny kod nie zawsze się wyłapie wszystkie błędy. Niestety, ale wypluwane błędny na ekran nie wyglądają zbyt profesjonalnie. Często jest tak, że twórca aplikacji nic nie wie o pojawiających się sporadycznie błędach do czasu, aż ktoś mu nie napisze maila. Jednak internauci nie zawsze są skłonni napisać e-maila do administratora z informacją o napotkanym błędzie i często okazuje się, że administrator serwisu o owym błędzie dowiaduje się np. pół roku po napisaniu skryptu bo coś tam przez przypadek zaglądnął na stronę i akurat mu się pojawił błąd.

Można jednak bardzo łatwo w PHP dodać własną obsługę błędów. Co byś powiedział, gdyby w razie wystąpienia takiego błędu został wysłany Tobie raport wprost na skrzynkę e-mail? Wystarczy tylko napisać jedną prostą funkcję i nakazać interpreterowi PHP, aby w razie wystapienia błędu owa funkcja została wywołana. Czytaj dalej »

Wczoraj na jednym hostingu zainstalowałem klasę phpmailer. Wyrzucało jakieś błędy. Po krótkiej analizie okazało się, że pliki php są domyślnie interpretowane przez php4. Miałem do wyboru dwie opcje:

• znaleźć jakąś starszą wersję klasy phpmailer kompatybilną z php4 (co jest głupotą, bo prędzej czy później na serwerze domyślnie zostanie włączona obsługa php5, więc nie ma sensu instalować przestarzałych bibliotek)
• zmusić jakoś serwer do tego, aby pliki z rozszerzeniem php był interpretowane domyślnie przez interpreter php5

Wybrałem to drugie rozwiązanie. Okazało się, że wystarczy do pliku .htaccess dopisać aż jedną linijkę Czytaj dalej »

Czasami pisząc pewne aplikacje są przedstawiane dane tabelaryczne. Np. roczne obroty. W takich danych są 2 kolumny: rok i obrót. Jednak dane tabelaryczne nie są tak czytelne, jak wykres. Można pokusić się o napisanie w PHP jakiejś funkcji generującej wykres jako plik graficzny (ot zrobienie prostego wykresu słupkowego chyba nie jest jakieś skomplikowane), ale znalazłem fajnego flashowego gotowca. Poniżej jest zrzut ekranu przykładowego wykresu:

Od razu widać, jaką tendencję mają obroty i wykres jest dużo czytelniejszy od tabelki. Czytaj dalej »

Na czas ładowania strony internetowej wpływa wiele różnych czynników takich jak:

• szybkość serwera
• wydajność aplikacji np. nieoptymalne zapytania do bazy danych MySQL będą powodowały wydłużenie się ładowania strony
• wielkość plików: dopóki przeglądarka nie pobierze wszystkich plików, strona nie zostanie w pełni wyświetlona. Wiadomo: łącza mają ograniczoną przepustowość i im większy jest plik do pobrania (plik html, plik graficzny, plik ze skryptem), tym dłużej się plik pobiera

W tym wpisie skupie się na trzecim punkcie. O optymalizacji plików graficznych już pisałem w notce: Jak zmniejszyć rozmiar grafiki nawet o 40% ?

Tym razem skupie się nad plikami JavaScript. Jak wiadomo, skrypty mają to do siebie, że są dość rozwlekłe. Stosując komentarze, wcięcia, nadmiarowe białe znaki powodujemy, że rozmiar pliku szybko rośnie. Owszem, nie odradzam stosowania komentarzy, wcięć, białych znaków. Te zabiegi mają na celu zwiększyć czytelność kodu (kosztem rozmiaru pliku). Jednak można pójść na pewien kompromis: można trzymać na dysku „obszerną” wersję skryptu, a na serwer wrzucać plik „po kompresji”. Nawet wręcz zalecam trzymanie na dysku oryginalnego pliku sprzed kompresji, gdyż edytowanie takiego pliku po kompresji nie należy do rzeczy przyjemnych Tutaj wada jest w pewnym sensie zaletą: kompresja plików javascript utrudnia ich użycie przez osoby postronne (więc jeśli nie chcesz, aby ktoś używał Twoich autorskich skryptów, to je skompresuj

Jednym z wielu programów kompresujących pliki JavaScript jest JSMin. Przykładowy skrypt zajmujący 1004 bajty został skompresowany do 440 bajtów.

Jeszcze na koniec jedna uwaga: zanim „skompresujesz” plik, upewnij się, że trzymasz na dysku jego pierwotną kopię (sprzed kompresji). Dlaczego? Otóż czasami plik po skompresowaniu może się dziwnie zachowywać (na stronie JSMin został opisany specyficzny przypadek, gdy kompresja „uszkadza” pliki), więc warto mieć możliwość wrócenia do punktu wyjścia!

Ostatnio miałem ciekawy problem do rozwiązania. Otóż w formularzu zamówienia klient podawał imię, nazwisko i adres. Musiałem sprawdzić ile procentowo osób, to kobiety. Wiadomo, jeśli by się okazało, że zamówienia składają głównie kobiety, to można pomyśleć o jakiś bonusach, które szczególnie się spodobają kobietom (np. aby nie oferować w ramach bonusu do zamówienia jakiegoś typowo męskiego upominku).

Baza danych wyglądała tak, że były kolumny id_zamówienia, imie, nazwisko, adres, kod pocztowy, miasto, kraj itp. Nie miałem w bazie danych kolumny płeć. Ale jest pewien ciekawy trik: Czytaj dalej »

Pisząc skrypt często istnieje potrzeba wysłania wiadomości e-mail. Nawet nie mam tutaj na myśli pisania prostych systemów do mailingu, ale zwykłą aplikację. Ot choćby np. prosta aplikacja gdzie użytkownik zakłada konto. Zazwyczaj przychodzi do niego wiadomość z prośbą o kliknięcie w link weryfikacyjny, potem podziękowanie za rejestrację, link do resetowania hasła również przychodzi na e-maila.

W wielu kursach php często podaje się wygodną funkcję mail. Ma ona jedną zaletę: jest prosta
mail("", "Temat", "Tresc", "Dodatkowe naglowki");

W ten sposób można szybko napisać prostą funkcję wysyłającą e-maile. Jednak gdy chcemy wysyłać e-maile w HTMLu, albo z załącznikami, albo jedno i drugie to robi się problem. Bo trzeba bawić się w tworzenie wielu dodatkowych nagłówków. Czytaj dalej »

Jedną z ważniejszych rzeczy jest organizacja. Załóżmy, że podejmujesz pracę nad jakimś większym projektem. Z pewnością będziesz pomiędzy sobą z zleceniobiorcą wysyłał sporo „papierków” (mam tutaj na myśli większe projekty tworzone przez np. pół roku a nie jakiś 100 linijkowy skrypt wykonujący jakąś jedną prostą czynność). No i u mnie często sytuacja wyglądała tak, że dany plik zapisywałem na pulpicie, czasem na pendrive. Mając 2 komputery można naprawdę się nieźle pogubić i np. za jakiś czas zacząć analizować starszą wersję dokumentu. Dlatego ważne jest, aby już na początku na np. dysku C:\ założyć folder NazwaProjektu a w nim różne podfoldery i tylko i tam przechowujemy wszelkie dokumenty związane z projektem. Ja w tamtym folderze mam następujące podfoldery:

• Dokumentacje – trzymam tam różnego rodzaju dokumentacje np. projekt bazy danych, dokumentacja API mojego modułu współpracującego z innym modułem mojego projektu, informacja jak zainstalować mój moduł itp.
• Content – trzymam tam różnego rodzaju treści. Tworząc np. moduł Programu Partnerskiego oprócz tworzenia kodu należy też na stronie wprowadzić jakieś treści np. FAQ, regulamin, treść ofertowa na stronie głównej
• Grafika – jako że nie jestem grafikiem, więc robotę się zleca podwykonawcy. Trzymam tam wszelkiego rodzaju pliki otrzymane od grafika
• Baza wiedzy – różnego rodzaju pomysły (w postaci zwykłych plików DOC lub ODT), jakieś raporty, artykuły mogące być inspiracją przy wprowadzaniu jakiś usprawnień w przyszłości
• Backupy – starsze wersje modułu (czasem się przydaje, jak np. coś w nowszej wersji nie działa, to mogę szybko rzucić okiem na starszą wersję modułu czy przez przypadek w nowszej wersji z wadliwej funkcji np. nie usunąłem jakiejś linii)
• Testy – pisząc większy projekt często jest tak, że się zleca testy np. znajomym (opracowuję scenariusz testowy w którym dokładnie opisałem co mają obklikać a dane osoby obklikują i piszą swoje uwagi) Następnie analizuję dokumenty, oczywiste usterki poprawiam, a te mniej oczywiste często są powodem dyskusji podczas których kilkukrotnie wysyłamy sobie dany dokument z kolejno dopisanymi przez siebie komentarzami (jest to oczywiste, że nie zawsze w 100% zrozumiem co miał na myśli tester, czasem jego uwaga może być dyskusyjna itp.)
• Todo – mój ulubiony folder zawierający listę zadań do zrobienia
• Inne – pozostałe pliki nie pasujące do powyższych kategorii

Oczywiście ta struktura folderów może u Ciebie być nieco inna. Ja podałem tylko uśredniony przykład z kilku moich projektów. Dzięki tej metodzie mam na dysku względny porządek i nie marnuję czasu na szukanie jakiegoś dokumentu czy też nie muszę się zastanawiać, która wersja danego dokumentu jest najnowsza). Warto jest również pliki datować tj. zawrzeć w nazwie datę np. todo-10-06-2010.odt dzięki czemu szybko znajdziesz najaktualniejszy plik). Wysyłając pliki pomiędzy sobą (np. raport ze scenariusza testów, który wysyłasz do testera, on do Ciebie i tak kilka razy) warto jest włączyć rejestrator zmian, wtedy od razu widać, kto co w danym dokumencie dopisał

Ten wpis powstał na bazie moich doświadczeń podczas pisania większych skryptów w PHP. Postaram się tutaj udzielić kilka słów odnośnie tego, jak należy pisać skrypty w PHP, aby później było jak najmniej pracy przy ewentualnej rozbudowie. Jako przykłady ilustrujące omawiane zagadnienia dość często będę się odwoływał do PP Mapa Zdrowia, który wdrożyłem. Czytaj dalej »

Bardzo wygodną funkcją w języku PHP jest funkcja print_r. Funkcja ta wyświetla „w czytelny sposób” zawartość obiektu, bądź tablicy (bądź zwykłej zmiennej, ale do wyświetlenia zmiennej wystarczy zwykła instrukcja echo).

Przykładowo mając taki kawałek kodu:

<?php
$a[0][0]='0x0';
$a[0][1]='0x1';
$a[1][0]='1x0';
$a[1][1]='1x1';
print_r($a);
?>

funkcja wyświetli w przeglądarce:
Array ( [0] => Array ( [0] => 0x0 [1] => 0x1 ) [1] => Array ( [0] => 1x0 [1] => 1x1 ) )

Niezbyt czytelnie, bo zamiast znaczników <br> są używane entery i dopiero po zaglądnięciu do źródła zobaczymy ową tablicę wyświetloną w czytelniejszy sposób:

Array
(
    [0] => Array
        (
            [0] => 0x0
            [1] => 0x1
        )

    [1] => Array
        (
            [0] => 1x0
            [1] => 1x1
        )

)

Jak widzisz, od razu jest to o wiele czytelniejsze, chociaż niezbyt wygodne jest zaglądanie do źródła! Jednak funkcja print_r ma dodatkowo drugi parametr (jego brak oznacza, że jest on ustawiony na false), który oznacza, czy funkcja ma zwracać wartość! Tą wartością jest owy string! Czyli można nieznacznie podrasować naszą funkcję, aby wyświetlała ową zawartość tablicy w dużo „czytelniejszy” sposób:

<?php
$a[0][0]='0x0';
$a[0][1]='0x1';
$a[1][0]='1x0';
$a[1][1]='1x1';
$output = print_r($a, true);
$output = str_replace(" ", "&nbsp;", $output);
$output = nl2br($output);
echo($output);
?>

Jak widzisz, mała rzecz, o której nie każdy wie, a naprawdę ułatwia pracę!

Przeglądając blog Nowy Subiektyw natrafiłem na ciekawy wpis. Otóż autor bloga podał link do ciekawego narzędzia on-line, które optymalizuje pliki graficzne (GIF, JPG i PNG o rozmiarze masymalnie 350KB). Narzędzie nazywa się PunyPNG. Reklamują się, że zmniejsza rozmiar plików średnio o 40% Testowałem na niektórych plikach i faktycznie niektóre pliki są optymalizowane o owe 40% (bez utraty jakości), a niektóre są gorzej (pewnie dlatego, że już wcześniej były zoptymalizowane).

Narzędzie umożliwia zaznaczenie kilku plików na raz i można pobrać od razu jeden plik ZIP ze wszystkimi wrzuconymi plikami po zoptymalizowaniu!!  Po zarejestrowaniu się zyskasz dodatkowo możliwość korzystania z API (ale dziennie można wtedy zoptymalizować 50 plików każdy maksymalnie 150 KB).

Wniosek? Narzędzie jest banalne w obsłudze, faktycznie optymalizuje pliki graficzne. Warto jest nim „przelecieć” jakieś większe pliki graficzne, gdyż zaoszczędzisz w długiej perspektywie sporo transferu!