Tomasz Kowalczyk

…czyli na co można się naciąć próbując stworzyć coś ciekawego w internecie. Programowanie webowe jest o tyle ciekawą dziedziną, że non stop czegoś trzeba się uczyć. Żywotność poszczególnych technologii jest praktycznie znana w momencie wypuszczenia ich na rynek. Oczywiście niektóre z nich są używane do dzisiaj, ale nie jest to już dawna forma, lecz próba dostosowania do realiów teraźniejszości, w związku z czym cały czas pojawiają się pewne “mankamenty” skutecznie utrudniające koderom życie. W niniejszym artykule opiszę sytuacje, przez które sam, w bólach i mękach przeszedłem znajdując rozwiązanie, czasem sam, czasem korzystając z wiedzy innego programisty. Ku przestrodze dla potomnych. ;]

• Właściwość ‘enctype’ znacznika ‘form’, czyli jak poinformować serwer, że chcemy mu coś przesłać.

Pewnego pięknego dnia przyszedłem do firmy i w planach miałem zrobienie modułu do uploadowania plików [duże, czyli >20MB PDFy] w aktualnie tworzonym projekcie. Ze szczerymi chęciami zabrałem się za kodowanie skryptu w PHP, potem za zrobienie formularza w XHTMLu. Kiedy stwierdziłem, że “RC1″ jest gotowe, zabrałem się za testowanie mojego “dzieła”. Jakież było moje zdziwienie, kiedy zamiast upragnionego PDFa w katalogu /upload/ dostałem jedynie komunikat:

Notice: Undefined index: file in [mój plik]

No cóż, przystąpiłem do goglowania. ;] Po przejrzeniu kilku wpisów na temat uploadowania plików na serwer stwierdziłem, że jednak nie tędy droga. Popatrzyłem na mój kod PHP - był ok. Nie był ok, jak się dowiedziałem od kolegi po fachu, mój kod html. Aby w ogóle dać możliwość uploadu, czyli przesłania pliku do /tmp/ na serwerze, potrzebna jest stosowna informacja w kodzie strony, że dana forma wysyła dane w różnych formatach [nie tylko tekstowym]:

enctype="multipart/form-data"

czyli pełna definicja znacznika form powinna brzmieć:

<form method="post" action="?action=upload" enctype="multipart/form-data"></form>

Nie muszę chyba dodawać, że sam bym się nie domyślił za Chińską Republikę Ludową. Problem się rozwiązał, ale tylko połowicznie. PHP nie miał już więcej do powiedzenia pomimo E_ALL dla error_reporting(); więc przeszedłem do kolejnego problemu, jakim był:

• 20MB, czyli kto zuploaduje więcej. Właściwość ‘upload_max_filesize’ w php.ini.

Mając na uwadze punkt poprzedni, ucieszyłem się, że teraz to już się pliki ładnie będą wrzucały. Nadzieje moje prysły, gdy zobaczyłem pusty katalog /upload/. W tym wypadku rozwiązanie było trochę prostsze - [kolega z firmy nadal był obok ;]] - błędny okazał się wpis w pliku php.ini, dotyczący maksymalnej wielkości uploadowanego pliku. No to do przodu, pomyślałem, no i tą wartość zmieniłem. Na szczęście to już pomogło, w każdym razie na localhoście. Aby zadziałało na serwerze globalnym, należało tą wielkość zmienić właśnie na nim. Jako, że do pliku php.ini nie mamy tam raczej dostępu, trzeba się posłużyć innymi metodami. W języku PHP istnieje funkcja ‘ini_set()’ która pozwala na operacje na pliku konfiguracyjnym interpretera. Aby serwer nie odrzucał plików nań wrzucanych, wpisałem do skryptów wrzucających pliki linijkę:

ini_set('upload_max_filesize', '50M');

jeżeli jest to operacja jednorazowa wystarczy edycja php.ini:

upload_max_filesize = 50M

każda z tych instrukcji ustawi maksymalnny rozmiar na 50MB. No to kolejny problem z głowy.

• “FCKeditor, the text editor for the Internet”, jak to ładnie brzmi…

…ale jak to się [nie]fajnie psuje i moje wrażenia na temat reakcji klienta w związku z obsługą “miniWorda”. Generalnie rzecz biorąc FCK jest bardzo fajne. Z jednej strony darmowe, z drugiej strony ładne, z trzeciej strony podoba się potencjalnym klientom, którym możliwość “wstawiania” wszystkiego bez znajomości HTMLa jest jak najbardziej na rękę. Tyle dobrego w sumie wystarczy, tylko jest jeden tyci problem - najpierw trzeba go dobrze skonfigurować. O ile ściągnięcie z netu nie jest zbyt wielką trudnością, o tyle doprowadzenie “od zera” kupy plików w katalogu /fckeditor/ do poprawnego działania jest już zadaniem na kilka godzin kodzenia, goglowania, wysyłania w powietrze niezliczonej ilości !@#$%^ tudzież innych słow dosadnie określających stan psychiczny programisty. Kiedy w końcu z poczuciem spełnienia misji powiesz “!@#$%^&, to działa!” już nie będziesz potem chciał niczego więcej, niż tylko kopiować całe drzewo katalogów do kolejnych projektów. Na razie zaś masz archiwum .tar.gz i masę roboty przed sobą. ;] Nie bój żaby, nie jest to takie trudne, ale potrafi na początku przenieść w stan “wyższego upojenia nerwowego”. Wracając do tematu problemów ze skonfigurowaniem FCK, największy problem sprawiło mi naprawianie tekstów wprowadzanych przez użytkownika. Dopóki wprowadzał dane w jednej linii, ciągłym tekstem, było ok. Wszystko zepsuło się w momencie naciśnięcia magicznego klawisza “Enter”. Jak za machnięciem różdżki, okno edytora znikło z miejsca, w którym powinno się według sekwencji kodu pojawić. Patrzę na log błędów WebDevelopera i otrzymuję bardzo fajny opis: “unterminated string literal” oznaczający ni mniej, ni więcej, że dane pobrane z bazy i wstawione do HTMLa gdzieś w tym kodzie namieszały. Wpisuję do gogli ujrzane wyrażenie, no i… nic ;] Nagle mnie oświeciło i wszedłem na forum FCK, tam znalazłem krótko wytłumaczone, iż każdą linię w JavaScripcie należy kończyć znakiem ‘\’ w przypadku tekstu wieloliniowego jakim ów wczytany był. Zauważyłem, że każda linia kończy się znacznikiem ‘</p>’ lub ‘<br />’. Napisałem więc funckję w PHP, która przerobiła mi wszystkie ‘znaki końca linii’ na te z dołączonym backslashem. Wyglądało to mniej więcej tak:

function addEndLineSign($str)
{
$str = str_replace('</p>', '</p>\\', $str);
$str = str_replace("<br />", "<br />\\", $str);
$str = substr($str, 0, strlen($str) - 1);
return $str;
}

Mam nadzieję, że przedstawione powyżej sytuacje pomogą rozwiązać niektóre przynajmniej problemy związane z tworzeniem stron internetowych. Będe wdzięczny za wszelkie komentarze do tego artykułu, być może masz jakiś problem a ja znam rozwiązanie?