Mariusz Tarnaski "MariuszT"

Ponad 5 milionów sprzedanych kopii mówi samo za siebie. Minecraft to był strzał w dziesiątkę. Prosta gra, bez jasno określonego celu ale z losowym generatorem map i z bardzo bogatymi możliwościami budowania. To wystarczyło aby odnieść ogromny sukces i zgarniać kolejne nagrody.

O Minecraft można pisać bardzo dużo. Dyskutować czy pikselowata grafika to jej zaleta czy wada. Czy granie w MC to zwykła strata czasu i tania rozrywka dla dzieci czy może łatwy sposób na odprężenie i pobudzenie swojej kreatywności. Opinie są bardzo różne ale społeczność Minecraft już wielokrotnie udowadniała, że ta gra ma w sobie potencjał.

Jako sympatyk Minecrafta postanowiłem otworzyć własny serwer. A było to w maju 2011 Z braku czasu i z powodu zbyt ambitnego podejścia do wszystkiego co robię, oficjalnie serwer wystartował dopiero w lutym 2012. Z tego miejsca chciałbym wszystkich serdecznie zaprosić na craftlandia.pl.

Pewnie będę co jakiś czas pisał o postępach na serwerze ale postaram się skupić na aspektach technicznych i biznes planie a nie na samej grze. Tak, ten pomysł ma swój biznes plan Wierzę, że gra ma potencjał zarobkowy, nie tylko dla jej twórców Minęło wiele miesięcy od momentu gdy pierwszy raz wstępnie przemyślałem cały system zarabiania i mimo upływu czasu, nadal wierzę, że to może się opłacać. Wkrótce okaże się czy bardzo się myliłem

A jaka jest Wasza opinia o Minecraft?

Temat narzędzi wspomagających budowanie stron www po stronie klienta gościł już na moim blogu. Chociażby w październiku pisałem o Bootstrap od Twittera. Do tej pory nie znałem jednak HTML5 Boilerplate.

Jak zaczynacie budować nową stronę? Ja mam przygotowany gotowy wzór. Plik z podstawowym szkieletem strony, wpisanymi meta tagami, które uznaję za potrzebne oraz niewielką strukturę katalogów i kilka plików np. do resetu styli CSS czy do obsługi przezroczystych PNG (kiedyś, teraz już nie ). Pewnie każdy z Was ma coś podobnego. Jeżeli nie gotową paczkę to chociaż swój ulubiony model, który kopiujecie z jednego projektu do drugiego.

To jest oczywiście sensowny sposób, po co za każdym razem robić coś od nowa, powtarzać tą samą pracę. Można jednak pójść o krok dalej i zamiast korzystać z własnego rozwiązania, użyć np. HTML5 Boilerplate, który został opracowany i przetestowany przez wiele tęgich głów i na pewno spisze się lepiej niż samodzielnie przygotowany wzór dokumentu.

Najważniejsze cechy HTML5 Boilerplate:

• HTML5 to przyszłość
• Ale nie zapominamy nawet o takich starociach jak IE6
• Kod dostosowany do urządzeń mobilnych
• Użyto normalize.css zamiast resetu stylów
• Użyto respond.js dla CSS3 Media Queries
• Rekomenduje i współpracuje z Google Chrome Frame dla starszych wersji IE
• Użyto modernizr do detekcji możliwości przegladarki
• Wsparcie cachowania CSS i JS
• Poprawia bezpieczeństwo PHP np. wyłącza register_globals lub usuwa nagłówek HTTP-X-Powered-By informujący o wersji PHP
• Udostępniono ustawienia dla serwerów Apache, ngnix itp. dodające obsługę popularnych typów MIME, włączających kompresję gzip itd.
• i wiele, wiele więcej

To naprawdę tylko drobna lista wszystkich właściwości. W HTML5 Boilerplate jest mnóstwo drobnych udogodnień o których sami na pewno nie pamiętalibyśmy. Koniecznie przeczytaj dokumentację, przejrzyj pliki. Znajdziesz tam również wiele linków do materiałów dodatkowych takich jak integracje biblioteki z CakePHP, Zend Framework, WordPress czy Django. Fani WordPressa znajdą dodatkowo listę gotowych skórek opartych o HTML5 Boilerplate.

Do tego wszystkiego mamy prosty skrypt do zbudowania własnej biblioteki tylko z tymi elementami, które potrzebujemy i w takiej postaci jaka nam odpowiada. A jeżeli to nie wystarcza to skorzystaj z Initializr gdzie masz szereg dodatkowych opcji.

HTML5 Boilerplate robi ogromne wrażenie. Włożono w niego mnóstwo pracy, ilość wiedzy jaka była do tego potrzebna jest imponująca. Samemu nie jesteśmy w stanie zrobić tego lepiej. Żałuję, że nie wiedziałem o HTML5 Boilerplate wcześniej, użyłbym go do ostatniego projektu, przetestował w praktyce. Ale mój następny projekt będzie już korzystał z możliwości tej biblioteki.

CSS Media Types w CSS2 pozwala na proste zdefiniowanie który plik stylów CSS ma zostać zastosowany na konkretnym urządzeniu. Można mieć osobne style dla przeglądarki, osobne do druku a jeszcze inne na przykład dla urządzeń do czytania braillem. Przydatne, ale można lepiej.

W CSS3 rozbudowano ten mechanizm, powstało CSS3 Media Queries. Możemy definiować osobne style na podstawie takich czynników jak wymiary ekranu czy jego orientacja.

Tak wygląda to na przykładzie:

Powyższy kod oznacza, że style z pliku style.css zostaną zastosowane tylko dla urządzenia z ekranem o minimalnych rozmiarach 1024x500px.

Istnieją alternatywne zapisy. Wewnątrz dokumentu CSS:

Jako @import:

Możliwości jest wiele, zachęcam do przejrzenia tego dokumentu.

Wsparcie przeglądarek

Oczywiście, jak zawsze, pojawia się pytanie jak jest z obsługą tej technologii w różnych przeglądarkach. I oczywiście, jak zawsze, odpowiedź brzmi, że wszędzie jest dobrze oprócz Internet Explorer Dopiero w IE 9 wprowadzono obsługę Media Queries.

Z tego powodu powstała biblioteka js Respond. Niewielki pliczek, który magicznie powoduje, że nasze reguły (tylko min-width i max-width dla wszystkich typów mediów) zaczynają działać w starszych wersjach IE. Jak sam autor twierdzi, "biblioteka jest napisana w taki sposób, że prawdopodobnie powinna łatać inne przeglądarki, które nie obsługują Media Queries".

Wcześniej, aby wszystko działało jak należy, trzeba było dodawać komentarz przy naszych regułach. Teraz biblioteka stosuje wyrażenia regularne dzięki czemu automatycznie rozpoznaje nasze reguły. Musimy tylko dołączyć respond.js do naszego dokumentu, nic więcej.

Alternatywą jest css3-mediaqueries-js. Bardziej rozbudowany skrypt (na tą chwilę 15,6KB), który podobno działa ze wszystkimi regułami Media Queries. Co oczywiste, działa wolniej od respond.js, zwłaszcza przy rozbudowanych regułach. Nie działa z importowanymi arkuszami (@import), nie parsuje również atrybutów media dla tagów <link> i <style>.

Czy używać CSS3 Media Queries? Zdecydowanie tak! Reguły te dają wspaniałe możliwości i są obsługiwane przez większość przeglądarek, zarówno na desktopach jak i na urządzeniach mobilnych. Dla IE też są rozwiązania a użytkownicy z wyłączoną obsługą JS są sami sobie winni

Pisałem już o stylach resetujących domyślny CSS przeglądarki. I to nie raz. Czy to jednak jedyny sposób aby wszystkie przeglądarki wyświetlały Twoją stronę jednakowo?

Całkowity reset styli CSS do standardowych wartości jest często krytykowany za niewłaściwe podejście. Zdaniem niektórych, lepiej byłoby zmieniać tylko to co powinno być zmienione. Stworzyć reguły naprawiające tylko te ustawienia i tylko w tych przeglądarkach gdzie faktycznie jest coś nie tak. Ta idea przyświeca twórcom normalize.css.

Takie podejście jest trudniejsze do zrealizowania ale zdaniem niektórych, wydajniejsze i bardziej poprawne.

Podstawowe zalety normalizacji:

• Współpraca z przeglądarkami na urządzeniach mobilnych
• Reguły dostosowane do HTML5
• Mniej styli, mniejsza objętość
• Podczas debugowania nie mamy takiego bałaganu (kto pracował z Firebugiem i zwykłym resetem ten wie o czym mowa)
• Brak idiotycznych reguł opisujących, że koło jest naprawdę okrągłe
• Można się czegoś nauczyć, wiele pomocnych komentarzy przy stylach

Sami musimy zdecydować co nam lepiej odpowiada. Z pewnością normalizacja jest teraz bardziej trendy od resetu

Certyfikaty to dobra rzecz, potwierdzają Twoją wiedzę. Jestem skłonny zaryzykować twierdzenie, że dla każdego normalnego pracodawcy jeden konkretny certyfikat może być więcej wart niż studia, nawet w oczekiwanym kierunku.

Problemem natomiast jest wybranie, który certyfikat chcemy zdobyć. Strona w3schools.com osiągnęła mistrzostwo w pozycjonowaniu przez co pojawia się na czołowych pozycjach W Google dla wielu zapytań o HTML, CSS a nawet PHP i MySQL. Nazwa nie pozostawia złudzeń, że to wszystko musi mieć coś wspólnego z konsorcjum W3C.

W3Schools oferuje na swojej stronie możliwość zdania płatnych, certyfikowanych egzaminów. Jest w czym wybierać. Na tą chwilę (grudzień 2011) mamy testy z HTML, CSS, JavaScript, jQuery, XML, ASP i PHP. Każdy za 95 dolarów (kiedyś było taniej ).

Na pierwszy rzut oka, wygląda atrakcyjnie. Wczytajmy się jednak w szczegóły.

• Po pierwsze, egzamin zdajemy online. Każdy rozgarnięty w tej chwili sobie myśli "Ej! To co z wiarygodnością?". Wiarygodność ma zapewnić ktoś od Ciebie Ktoś kto w teorii ma nad Tobą stać i patrzeć czy rozwiązujesz test samodzielnie a potem podpisać się pod certyfikatem. Od Ciebie zależy czy to będzie Twój kumpel z podwórka czy np. Twój szef ze znanej i szanowanej firmy IT. Oczywiście Twój Anioł Stróż mógłby Ci wystawić zwykłą rekomendację i miałaby taką samą moc no ale wtedy W3Schools by nie zarobiło
• Test to 70 pytań wielokrotnego wyboru lub pytań TAK/NIE, limit czasu to 70 minut. Ja mam alergię na takie testy ale zdaję sobie sprawę, że to najprostsza i najszybsza forma egzaminu i może być nawet skuteczna o ile pytania są sensowne. W tym przypadku jednak nie są. Pytania są banalne. Tzn. nie wiem jakie są bo oczywiście nie przystąpiłem do żadnego testu ale są testy przykładowe i ich poziom woła o pomstę do nieba.
• Jeżeli nie zdasz (minimum 75% poprawnych odpowiedzi) lub chciałbyś poprawić swój wynik to masz jeszcze jedną próbę. Jak rozumiem, w cenie.
• W3Schools nie ma żadnego związku z konsorcjum W3C. Żadnego!

To wszystko powoduje, że nikt o zdrowych zmysłach nie weźmie pod uwagę tych certyfikatów. Więcej! Może uznać Cię za cwaniaka, który przyszedł go oszukać lub głupka, który dał się na tą farsę nabrać.

Do w3schools.com jest wiele więcej zarzutów. Społeczność webmasterska wyłapała wiele nieścisłości i błędów we wskazówkach tam umieszczonych. W swej złości stworzyli stronę w3fools.com gdzie bezwzględnie wytykają wszystkie grzechy autorów kursów.

Przy okazji, jakie certyfikaty warto zrobić?

Ja znam jeden dobry, certyfikat od Zend. W świecie PHP (w tej chwili certyfikat jest z PHP w wersji 5.3) nie ma cenniejszego certyfikatu. Osoby mocno związane z Zend Framework mogą też pomyśleć o certyfikacie z tego frameworka. Być może inne firmy egzaminują również z innych frameworków, CMS'ów itd.

Na pewno warto zastanowić się nad certyfikatami z bezpieczeństwa lub z baz danych. Szczegółów jednak nie podam bo ich nie znam Szukajcie przede wszystkim takich egzaminów, które mają błogosławieństwo od firm autorów oprogramowania.

Zdecydowanie nie warto podpierać się jakimikolwiek kursami i egzaminami z HTML i CSS. Wystarczy zrobić swoje portfolio i niech jego źródło mówi za nas. Miałbym również duże wątpliwości czy warto inwestować w coś co potwierdzi naszą znajomość Flasha i AS3. Natomiast jeżeli ktoś pracuje bardzo dużo z JavaScript to pewnie jakiś certyfikat byłby bardzo mile widziany (ale już nie z jQuery, to za proste!). Tylko czy coś takiego istnieje?

Domeny z narodowymi znakami są już dłuższy czas dostępne ale nie przyjęły się za bardzo, przynajmniej nie w Polsce. Nie usprawiedliwia to jednak programistów, którzy o nich zapominają. Może to nam wygenerować poważne problemy.

Kilka dni temu musiałem poprawić pewien mały skrypcik. Administrator może podać adres, który potem jest używany w przekierowaniu PHP. Zwykłe, banalne header():

I nagle zaskoczenie. Ten kod w Firefox i Safari (z Chrome i Operą było wszystko OK, IE nie testowałem) nie działa gdy zmienna $address to adres domeny z polskimi znakami diakrytyzowanymi!

Oczywiście pierwsza (i słuszna) myśl to przekodowanie takiej domeny do pierwotnej postaci. Jak powszechnie wiadomo, za tymi ładnymi narodowymi literkami kryją się okropne, niezrozumiałe krzaczki. Domena gżegżółka.pl tak naprawdę wygląda tak: xn--gegka-2ta76cmoc.pl. Do konwersji służy algorytm o nazwie Punycode.

Jeżeli masz PHP w wersji co najmniej 5.3 to rozwiązanie jest banalne. Masz dostępne dwie funkcje służące do konwersji z UTF8 do ASCII i z ASCII do UTF8.

Poniżej PHP 5.3 musisz posiłkować się zewnętrznymi bibliotekami. Najpopularniejsza z nich ma swoją stronę domową tutaj natomiast tutaj jest źródło do ściągnięcia.

Konwersja z UTF8 do ASCII:

Otrzymamy:
http://www.xn--gegka-2ta76cmoc.pl

Konwersja z ASCII do UTF8:

Otrzymamy:
http://www.gżegżółka.pl

Jeżeli spróbujemy poddać konwersji normalną domenę, nie IDN, to nic się nie stanie więc funkcje/metody są bezpieczne i można ich używać na wszystkich domenach, bez dodatkowego rozróżniania. Pamiętaj tylko aby mieć adres w UTF8.

Niektórzy twierdzą, że e-maile w ogóle nie powinny występować w postaci HTML. E-mail to ma być prosta, tekstowa wiadomość, od wszystkiego innego są strony www. Trudno odmówić temu rozumowaniu logiki. Zwłaszcza, gdy dostajemy kolejną reklamę przeładowaną grafiką. Mnie osobiście podobają się jednak ładne, dobrze zorganizowane e-maile, bez bajerów i innych wodotrysków. To cieszy oko i ułatwia korzystanie. Chciałbym budować maile używając HTML'a i CSS'a. Ale...

Najważniejszych przeglądarek internetowych mamy kilka, każda w kilku wersjach. Potrafi to przyprawić o ból głowy. Na szczęście już całkiem nieźle radzą sobie z obsługą standardów. Natomiast klientów pocztowych są dziesiątki a może nawet setki! Po pierwsze, trzeba je podzielić na klienty desktopowe i webowe. Tych pierwszych jest mniej ale i tak wiele. Tych drugich jest zatrzęsienie i nie ma tu żadnych reguł, każdy dostawca poczty często robi wszystko po swojemu.

Efekt jest opłakany. Zbudować dzisiaj atrakcyjny e-mail w HTML/CSS, który byłby prawidłowo wyświetlany we wszystkich popularnych klientach jest co najmniej ogromnym wyzwaniem. Prym wśród najpopularniejszych wiedzie... Gmail! Rozumiem, że to w trosce o swoich użytkowników ale ich klient wycina ze źródła prawie wszystko.

No ale dość tych gorzkich żali Czas na jakieś wskazówki. Oto co należy robić a czego bezwzględnie unikać przy budowaniu kolejnego newslettera:

• Używaj UTF-8.
• Cofnij się o 8 lat w rozwoju i do zbudowania głównej struktury użyj tylko tabelek.
• Cofnij się o 10 lat w rozwoju i nie wstydź się tagów typu <center />.
• Możesz używać styli CSS tylko w postaci inline czyli przypisanych bezpośrednio do tagów w atrybucie style="". Nic innego nie zadziała.
• Gdzie tylko możesz, używaj starych atrybutów zamiast CSS np. width="". A najlepiej oba.
• Zapomnij o pozycjonowaniu absolutnym. Najlepiej zapomnij o jakimkolwiek pozycjonowaniu.
• Zapomnij o tłach obrazkowych. Gdziekolwiek i bez względu na użytą metodę. Tekstu nad obrazek po prostu nie wstawisz, koniec kropka. Zostaje Ci tło jako kolor.
• Lepiej zrobić wszystko na konkretne wymiary i podawać je gdzie się da. Procenty lub pomijanie podawania niektórych wymiarów może się skończyć rozjechaniem całego szablonu.
• Marginesy zewnętrzne i wewnętrzne? Niestety, nie możesz.
• Nawet width i height mogą nie zadziałać na innych elementach niż tabelki i ich komórki.
• W sekcję <head /> możesz wpisać tag odpowiedzialny za kodowanie znaków. I to też tylko dla świętego spokoju. Nic więcej nie umieszczaj bo i tak wytną.
• Nie dodawaj niczego bezpośrednio do tagu <body /> bo i tak zostanie to usunięte.
• Jeżeli chcesz dać np. kolor tła dla całej wiadomości to użyj jakiegoś kontenera (np. <div />) i daj mu szerokość 100%. Wysokość zawsze dostosuje się do zawartości, inaczej się nie da.
• Dla swojego dobra powielaj gdzie się da ustawienia dla czcionki itp. bo nigdy nie wiadomo dla którego elementu nasz klient pocztowy postanowi zresetować te wartości do tych domyślnych.
• JavaScript? Najprostsza droga do katalogu "Spam" (I moim zdaniem dobrze, obsługa JS to byłaby już jednak przesada).

To lista najtwardszych zasad, którymi musisz się kierować ale ograniczeń jest oczywiście dużo więcej. Każdy znający HTML/CSS łatwo odpowie sobie, które jeszcze rzeczy nie zadziałają skoro nawet tak podstawowe metody wymienione wyżej sprawiają ogromne problemy.

Na szczęście są strony, które kontrolują sytuację i sprawdzają za nas co wolno a czego trzeba się wystrzegać.
Pierwsza z polecanych przeze mnie witryn to www.campaignmonitor.com/css/. W ładny i przystępny sposób prezentuje ograniczenia klientów pocztowych. Na górze, w prawej ramce, mamy linki do obszerniejszego raportu, obejmującego 24 klienty (stan na grudzień 2011).
Druga strona to www.email-standards.org. Prezentuje dokładne recenzje wielu popularnych klientów. Niestety nie w tak przystępnej formie jak powyższa strona ale też przydatne.

Radzę wziąć sobie te zasady do serca i pilnować grafika jeżeli takowego masz w zespole bo i bez jego finezyjnych wygibasów w Photoshopie, możesz spędzić kilka godzin nad przygotowaniem jego wizji w formie wiadomości e-mail. Znam z doświadczenia

Bloga założyłem z kilku powodów:

• aby mieć coś swojego, bardzo prywatnego, na własnych i tylko własnych zasadach i co nie musi zarabiać na siebie
• aby mieć miejsce gdzie mogę napisać o swoich wszystkich przemyśleniach, pochwalić się czymś, polecić coś, podzielić się czymś z innymi
• aby pomóc innym w problemach przez które sam przebrnąłem

Wszystkie cele zostały osiągnięte Problem sprawia mi jedynie ostatni podpunkt...

Lubię pomagać. Naprawdę. Muszę trzymać się jednak pewnych zasad bo inaczej pomoc odbywałaby się kosztem mojej pracy i moich dochodów z niej. Dlatego przyjąłem, że na sprawy związane bezpośrednio lub nawet pośrednio z wpisami na moim blogu odpowiadam TYLKO na blogu. Dlaczego?

Dlaczego nie przez komunikator? Bo wtedy rozmówcy wydaje się, że od chwili gdy się do mnie odezwał powinienem się skupić tylko i wyłącznie na jego problemie. Zasypie mnie setką pytań, sam nie zastanowi się nawet chwili nad rozwiązaniem bo przecież łatwiej napisać dwa zdania na GG i niech inny się głowi. Takie rozmowy ciągną się w nieskończoność, pytań przybywa i nie można się skupić na niczym innym.

Dlaczego nie przez e-mail? Ta droga komunikacji jest przyjemniejsza bo to ja decyduję kiedy zajmę się daną sprawą. Przy okazji wymaga trochę więcej wysiłku aby napisać sensowny e-mail co daje pewne szanse, że zgłaszający podjął chociaż małe próby samodzielnego rozwiązania problemu. Nadal jednak to nie jest najlepsza forma z prostej przyczyny: często przychodzi mi odpowiadać wielokrotnie na te same pytania.

Dlaczego komentarze? Bo z jednej strony skorzystanie z nich jest tak proste i szybkie jak z komunikatora a z drugiej wymusza zadanie sensownego pytania (a więc zastanowienie się nad problemem). Ja mogę na to pytanie odpowiedzieć w wolnym czasie. A co najważniejsze, odpowiedź widzą inni! I o to się tak naprawdę rozchodzi. Następny pytający być może przejrzy komentarze i tam znajdzie odpowiedź na trapiący go problem lub w ostateczności zada pytanie a ja go odeślę do gotowej odpowiedzi.

Na stronie Kontakt umieściłem wyraźny komunikat:

Masz pytanie związane z jakimś tematem, który poruszyłem na blogu? Pisz TYLKO w komentarzach. Jeżeli zignorujesz moją prośbę to bądź pewien, że ja zignoruję Ciebie.

I co? I... Musiałbym brzydko odpowiedzieć Oczywiście całe tabuny ludzi jakimś magicznym sposobem zupełnie nie dostrzegają tych dwóch zdań. Pewnie nawet jakbym sprawił aby ten napis migał to znalazłby się taki co akurat mrugał jak napis się pojawiał i dlatego go nie zobaczył...

Wylewam tu swoje żale bo po raz kolejny poświęciłem komuś czas, mimo, że zignorował moje prośby, nie uszanował mojej woli i nie zadał sobie trudu aby samemu poszukać rozwiązania. A na koniec nie usłyszałem nawet głupiego "dziękuję". Nic, ani słowa. Tak jakby pomaganie było moim obowiązkiem.

W związku z tym, ogłaszam oficjalnie, że od teraz wprowadzam w życie zasadę z powyższego komunikatu. Do tej pory byłem wyrozumiały ale tym wpisem usprawiedliwiam się i oczyszczam swoje sumienie Chociaż wiem, że Ci na których narzekam i tak nie przeczytają tych słów

Ale żeby nie było tak nudnie i marudnie to napiszcie w komentarzach jak to jest z Wami? Często ludzie oczekują od Was pomocy gdy dowiadują się, że jesteście jakoś związani z IT? Jak sobie z tym radzicie?

Obsługa standardów w przeglądarkach nadal nie jest na takim poziomie jakiego byśmy oczekiwali. Przezornie nie wykorzystujemy wielu możliwości CSS3 bo "znowu rozwali się w IE i będę miał przez to tylko problemy". Jest jednak grupa efektów, które działają we wszystkich (lub prawie wszystkich) przeglądarkach i jedyny problem z ich zastosowaniem jest taki, że w różnych programach interpretowane są różne reguły.

Pomocną dłoń wyciąga do nas autor css3please.com. Na tej stronie znajdziemy kilka interesujących efektów CSS3 w wersjach na różne przeglądarki. Wszystko jest ładnie opisane, ciągle aktualizowane a obsługę ułatwiają nam skrypty JS. Warto przejrzeć reguły umieszczone na stronie, zapamiętać i wracać regularnie. Polecam!

Skuszony wieloma rekomendacjami i niskimi cenami, postanowiłem skorzystać z oferty hostingowej linuxpl.com. Podstawowym plusem jest także możliwość zmiany wersji PHP na 5.3. Ta wersja pojawiła się dwa i pół roku temu a do tej pory nie jest dostępna na większości hostingów :/

Na linuxpl.com dostajemy również dostęp do SSH, co bywa dla mnie czasami zbawienne. W ustawieniach zmieniłem wersję PHP na 5.3 i z poziomu SSH chciałbym uruchamiać skrypty także pod tą wersją. Niestety, bez względu na ustawienia w panelu, komenda "php skrypt.php" pod SSH zawsze chce korzystać z PHP w wersji domyślnej dla linuxpl.com czyli PHP 5.2. Dokonałem tego odkrycia podczas gorączkowych przygotowań do uruchomienia lastdeal.pl więc postanowiłem nie czekać na support i rozwikłać zagadkę sam.

Nie da się na linuxpl.com sprawić aby zwykłe "php skrypt.php" działało w wersji innej niż PHP 5.2. Można jednak podać ścieżkę do innej wersji PHP. Jest to kłopotliwe bo trzeba wpisać za każdym razem długie ścieżki ale przynajmniej w ogóle się da. Swoją drogą niektóre (większość?) skrypty mają "na sztywno" wpisane samo "php coś tam" i trzeba będzie niestety je zedytować przed uruchomieniem.

Nie przedłużając, oto gotowa recepta.

Po zalogowaniu na SSH musisz zejść "niżej" w strukturze katalogów, wyjść ze swojego konta. Najlepiej "cd /". Binarka PHP w wersji 5.3 znajduje się tutaj: "./usr/local/php5.3/bin/php". Zamiast wpisywać "php skrypt.php" musisz wpisywać "./usr/local/php5.3/bin/php ./home/twoje_konto/domains/twoja_domena/public_html/skrypt.php".

Próbowałem zrobić symboliczny link aby chociaż trochę skrócić ścieżki ale niestety, nie powiodło się. Tam gdzie mam uprawnienia do tworzenia linków, tam nie zadziała ta binarka PHP. Trzeba zejść niżej, wyjść z własnego konta. A tam znowu nie mam już uprawnień...

Gdy była chwila spokoju, napisałem zapytanie do supportu. Potwierdzili to co sam znalazłem, dodając jedną wskazówkę:

jezeli chce pan uzyc swojego php.ini to komenda

/usr/local/php5.3/bin/php -c /usr/local/directadmin/data/users/lastdeal/php/lastdeal.pl/php.ini skrypt.php

Mam nadzieję, że ten wpis zaoszczędzi komuś trochę czasu i nerwów