kometa, typo3′n’tricks i upierdliwy mail();

tadaaam! kometa wylądowała!
na początku chciałbym po raz kolejny podziękować Świeżemu, bo to on odwalił tu kawał dobrej roboty. ja robiłem tylko to co zwykle – przeszkadzałem nowymi pomysłami, przekazywaniem kolejnych uwag klienta i dłubałem co nieco w typo ;)

to wręcz nie do wiary, ale dziś, dosłownie 20 minut temu, zakończyła się mozolna walka z flashem, typo3, no a przede wszystkim – ze zmiennymi czasem sugestiami klienta.
walka, która nauczyła nas najważniejszej rzeczy: grunt to dobry plan. ale plan zawsze może być lepszy ;)
walka, która potwierdziła nam ważną rzecz: baza bazie nie równa.
w końcu walka, którą by zakończyć, stoczyć musieliśmy jeszcze kilka mniejszych bitew.
w związku z dobrym nastrojem, który nastąpił po ostatecznej instalacji, wspominanej również we wcześniejszych wpisach, kobyły, pomyślałem sobie, że mógłbym napisać wreszcie coś „dla potomnych”. a zatem…

grunt to dobry plan. ale plan zawsze może być lepszy ;)
zgodnie z prawem murphy’ego. jeśli wydaje się, że wszystko jest ok – na pewno coś przeoczyliście. choćby nie wiem jak dobry plan gry rozpisać, zawsze znajdą się w nim luki. najważniejsze jednak – żeby luki te zapamiętać na przyszłość, bo podobno człowiek uczy się na błędach, by ich drugi raz nie popełniać ;) ot, kilka oczywistych słów „na zaś”.

typo3 i ogólne problemy z exportem/importem baz mysql.
wstukując kilka keywordsów w google, szybko można dojść do wniosku, że z przenoszeniem bazy mysql KAŻDY, miał lub ma problem. chyba tylko nieliczni, którzy wręcz instalację i konfigurację owych baz ręcznie przeprowadzali, mogą cieszyć się bezbolesną migracją danych. u mnie zonk pojawia się za każdym razem.. bo za każdym razem spotykam inną bazę docelową, w której niewiele zmienić można, a dziwnym trafem poznane do tej pory sztuczki kończą się kolejną serią przekleństw. być może nigdy więcej :D
dziś, ponieważ zmuszony zostałem do całkowicie ręcznego przeniesienia kilkuset rekordów w różnych językach, przekleństw było również kilkaset. do momentu, gdy trafiłem na trzy proste kwerendy sql.

SET CHARACTER SET XXX;
SET NAMES XXX;
SET SESSION character_set_server=XXX;

eksportujemy bazę „normalnie”, importujemy bazę „normalnie”, a w przypadku problemów wynikających z różnic w ustawieniu charsetu baz/tabel/kolumn – korygujemy wszystko w/w kwerendami, które dodać musimy do kodu naszej strony, zaraz po fragmencie łączącym z bazą. oczywiście zamiast XXX podajemy kodowanie źródłowego pola. tak tak, POLA, nie tabeli, nie bazy. jakkolwiek dziwnie to brzmi, tak to zadziałało ;) a co ma do tego wspomniane typo3? ot, tylko tyle, że dodanie czegokolwiek w kodzie, oznacza zmianę źródeł, na co oczywiście ochoty nikt nie ma, więc tu pojawia się kolejny problem. na moment. z pomocą przychodzi installtool, w którym po wybraniu all configuration odszukujemy pole [SYS][setDBinit] i tam wstawiamy naszą kwerendę. można też hardkorowo, nie korzystając z wygodnego formularza – do pliku localconf.php, dodać linijkę [tu się pewnie połamie na kilka]:

$TYPO3_CONF_VARS['SYS']['setDBinit'] =
'SET CHARACTER SET XXX;'.
chr(10).'SET NAMES XXX;'
.chr(10).'SET SESSION character_set_server=XXX;';

pamiętając rzecz jasna o odpowiednim wpisie zamiast XXX. metoda cudownie uzdrowiła kodowanie polskich znaków, a także wyświetlanie cyrylicy i niemieckich umlautów nie tylko w backendzie, ale i frontendzie typo, a dopisanie zapytań w pierwszej, bardziej „ogólnej”, formie, do odpowiedniego kodu php, pomogło przy wyświetlaniu tekstów z bazy typo3, wewnątrz silnika flashowego. pięknie.

problem z wysyłaniem poczty z poziomu phpowego mail().
kolejny punkt dzisiejszego programu. kolejny również dowód na to, że czasem kwestia nawet jednej literki pozwala zająć nam pół dnia. „zwyczajnie” i bez bajerów użyta funkcja mail(), na jednym serwerze działała, a na drugim nawet nie informując o błędzie po prostu wypinała się na nasze prośby wysłania prostego maila. tu także nie dokonałem rewolucyjnego odkrycia, ale jeśli informacja pojawi się częściej w necie – łatwiej będzie ją znaleźć, pozwalam więc sobie zamieścić lekarstwo na dolegliwość phpowej wysyłki poczty.
generalnie – problem mogą stanowić zakończenia linii w nagłówkach, lub same nagłówki. nawet jeśli phpinfo() pokazuje taki sam konfig maila jak na serwerze testowym – nie dajcie się zwieźć. gdy nie wiadomo o co chodzi, a mail nie wychodzi, warto sprawdzić inne zakończenie linii przekazywanych do mail() nagłówków: \r\n lub \n\n, tak samo, jak warto sprawdzić same nagłówki – nie każdy serwer [a raczej nie każda jego konfiguracja] pozwala na użycie nagłówka From:, czasami zamiast:

$naglowki = ...
$naglowki.= "From: Kubuś Puchatek <kubus@stumilowylas.com>";
...
mail($adresat, $temat, $wiadomosc, $naglowki);

trzeba użyć:

$naglowki = ...
$parametry = "-fkubus@stumilowylas.com";
...
mail($adresat, $temat, $wiadomosc, $naglowki, $parametry);

co prawda nie możemy w tej metodzie „ładnie” opisać maila np. imieniem i nazwiskiem, ale najważniejsze, że dzięki temu maila da się w ogóle wysłać. po szczegóły dot. samego mail() odsyłam do źródła [w zamieszczonych komentarzach, można znaleźć sporo pomocnych rozwiązań]. howgh. rzekłem.