XAMPP to popularne środowisko zapewniające szybką i prostą instalację serwera www, interpretera PHP i baz MySql w środowisku Windows. Jeśli jesteś początkującym deweloperem i korzystasz z popularnego pakietu XAMPP, to prędzej czy później będziesz chciał przenieść swoje dzieło na serwer produkcyjny. Wiele osób w podobnej sytuacji, dziwił się, czemu po przeniesieniu na produkcję aplikacja lub strona nie działają.

W tym artykule:

  • XAMPP – co to takiego?
  • Cztery problemy przy migrowaniu na produkcję
  • Jak pracować z XAMPP, żeby przenoszenie było łatwe i przyjemne.

XAMPP. Co to jest i jak programiści go używają?

W wielkim uproszczeniu, XAMPP stanowi bezpłatny, wieloplatformowy oraz zintegrowany pakiet zbudowany z bazy danych – MariaDB, kompatybilnej z MySQL, serwera www oraz interpreterów i ewentualnie dodatkowych komponentów.

To nic innego jak darmowy serwer WWW umożliwiający obsługiwanie serwisów internetowych. Ten program może być udostępniany na czterech platformach: Linux, Windows, OS X oaz Sun Solaris. XAMPP wyróżnia się bajecznie łatwą instalacją all-in-one. Jego głównym „konkurentem” jest – także bezpłatny – pakiet WAMPP, skierowany przede wszystkim do użytkowników Windows. Używałem obu rozwiązań – wydaje mi się, że to kwestia preferencji osobistych – mnie z XAMPP pracowało się po prostu wygodniej. Sam pakiet XAMPP możesz pobrać z oficjalnej strony projektu i jest to całkowicie bezpłatne.

XAMPP to wygodny panel do zarządzania serwerem www oraz MySql.

XAMPP to idealny obszar do rozległego działania programistów oraz testerów potrzebujących szybkiego i sprawnego przeanalizowania oraz zweryfikowania konkretnych skryptów na lokalnym komputerze. Potrzeba stosowania zewnętrznego serwera znika lub jest zminimalizowana. W skrócie – to oprogramowanie sprawiające, że Twój PC czy laptop zachowuje się podobnie jak serwer. Oczywiście w sensie programowym, bo sprzętowo nic się nie zmienia. Z perspektywy początkujących deweloperów jak najbardziej działanie XAMPP jest wystarczające oraz w pełni komfortowe. Pakiet jest wygodny. Zmiany nanoszone w kodzie od razu są widoczne w działaniu, wystarczy odświeżyć stronę, nie trzeba niczego kopiować na serwer.

Jeśli jesteś programistą to znasz to uczucie zbliżania się do końca projektu. Po wielu godzinach pracy, nadchodzi ten moment, kiedy osoba jak Ty (albo jak ja, kilka lat temu) – kopiuje pliki na „prawdziwy” serwer. Ot, na przykład taki hosting w cyberfolks.pl… wpisuje adres w pasek przeglądarki i … i nic! Albo – częściej – tajemnicze błędy na ekranie.

Z czego wynikają kłopoty z migracją ze środowiska developerskiego na produkcyjne? Poniżej, jako „weteran” XAMPP’a dzielę się z Tobą swoimi błędami i doświadczeniami. Mam nadzieję, że uznasz je za przydatne i dzięki temu wpisowi uda Ci nie powtórzyć moich błędów. No, to jedziemy:

XAMPP. Kod nie działa? Wielkość liter ma znaczenie!

By projekt w PHP czy MySQL właściwie działał również po przeniesieniu na produkcję, weź pod uwagę wielkość liter. Wbrew pozorom ma ona ogromne znaczenie dla poprawności pracy. Zalecam konsekwencję w używaniu wielkości znaków. Kluczowe jest stosowanie niezmiennie identycznego wzoru zapisu – z dużych, bądź małych liter – od początku do końca tak samo. Tak jak plik się nazywa, musi zostać wywołany w kodzie – i wielkość liter ma znaczenie.

Dzieje się tak, ponieważ systemy Windows i Linux różnie traktują odwołania do nazw plików pisanych wielkimi i małymi literami. System Windows, a więc ten, na którym prawdopodobnie rozwijasz swój projekt lokalnie, będzie działać równie dobrze nawet, jeśli np. nazwy plików są innymi literami niż wskazano to w kodzie. Przykładowo w kodzie masz wywołanie:

include('plik-dodatkowy.php');

a na serwerze plik ma nazwę ‚Plik-dodatkowy.php’. Różnica tkwi w pierwszej literze. W systemie Windows taki kod zadziała, w systemie Linux, a więc na większości produkcyjnych hostingów – niestety nie. Zazwyczaj taki błąd jest sygnalizowany informacją, że nie można znaleźć poszukiwanego pliku:

Warning: include(plik-dodatkowy.php): failed to open stream: No such file or directory in C:\xampp\htdocs\test\index.php on line 3

Warning: include(): Failed opening 'plik-dodatkowy.php' for inclusion (include_path='C:\xampp\php\PEAR') in C:\xampp\htdocs\test\index.php on line 3
 

Podobnie rzecz się ma z nazwami w poleceniach SQL. Nazwy np. tabel w bazie muszą być wywołane w kodzie tak samo, jak zostały zdefiniowane na serwerze. O ile domyślna instalacja XAMPP na Windows poradzi sobie nawet w razie konfliktu nazw, o tyle w wypadku hostingu produkcyjnego niemal na pewno rozbieżności w wielkości liter doprowadzą do błędów w działaniu aplikacji.

Te błędy są nieco trudniejsze do namierzenia. Przecież skoro działa „na deweloperce” to większość osób nie będzie w stanie zrozumieć, dlaczego nie działa „na produkcji”. Zależnie od tego, jak skonfigurujesz wyświetlanie błędów – błędy SQL mogą także nie wyświetlać się na ekranie w sposób w pełni czytelny. Jeśli chcesz wiedzieć więcej zapraszam do wpisu o błędach w PHP. Kiedy jednak masz pewność, że wszystko inne działa, a problemem są polecenia sql – koniecznie sprawdź wielkość liter w nazw tabel i pól.

XAMPP a wersja PHP na serwerze

Punkt drugi to wersja PHP. Przeważnie XAMPP jest zainstalowany z określoną wersją PHP, dlatego też warto wiedzieć jaka jest to wersja. Dzięki temu w razie wystąpienia ewentualnych trudności po przeniesieniu na serwer komercyjny możesz szybko i sprawnie zweryfikować, czy wersja na serwerze jest zgodna z tą w XAMPP.

Niektóre funkcje pojawiają się w określonych wersjach, inne przestają być wspierane. Najgorsza chyba z punktu widzenia diagnostyki sytuacja, to kiedy funkcja w jakiejś wersji PHP zachowuje się inaczej niż w wersji poprzedniej. Czyli niby działa, ale daje inny wynik.

Przykład
Funkcja mb_strtoupper() zamienia alfabetyczne litery ciągu (Unicode) na wielkie. Sama funkcja nie jest nowa, jednak wynik jej działania różni się między PHP 7.3 i poprzednimi wersjami. Chodzi o obsługę niektórych znaków, w szczególności w języku niemieckim. Dla niektórych może to mieć duże znaczenie w aplikacjach, a także w SEM/SEO, bo fraza „Straße” po przekształceniu w wielkie litery nie brzmi teraz „STRAßE” ale „STRASSE” i niektóre systemy mogą ją rozpoznać jako całkiem inne słowo niż do tej pory.

Tego typu zmiany w działaniu funkcji przy przechodzeniu między, pozornie bardzo podobnymi, wersjami PHP mogą powodować trudne do zdiagnozowania problemy. Dlatego pracując z XAMPP upewnij się, że na hostingu produkcyjnym oraz na Twoim lokalnym komputerze pracujesz w tej samej wersji PHP.

Co, jeśli ta wersja jest różna?

Zazwyczaj łatwiej jest zmienić tę wersję na serwerze. Dobre hostingi wspierają kilka wersji PHP, umożliwiają łatwe i szybkie zmienianie wersji PHP z poziomu panelu do zarządzania serwerem (w naszym wypadku: DirectAdmina). W pakiecie XAMPP domyślnie jest instalowana określona wersja PHP. Najłatwiej jest od razu pobrać XAMPP’a z właściwą wersją. Nie znam prostego, szybkiego sposobu na zmianę wersji na już działającym XAMPP’ie – w jego panelu sterowania nie ma takiej funkcji. Jest to zatem zadanie o wiele bardziej skomplikowane niż jedno kliknięcie w panelu.

Rekomenduję oczywiście pracę w najnowszej możliwej (stabilnej) wersji, wspieranej przez hosting. W chwili pisania tego artykułu na hostingu w cyberfolks.pl jest to PHP 7.4.

XAMPP – jak uzyskać dostęp do bazy danych?

Trzeci problem z jakim mogą spotkać się początkujący programiści ma z kolei związek z bazami danych. Warto pamiętać, aby po przenosinach projektu z serwera lokalnego w odpowiednich plikach konfiguracyjnych projektu przewidzieć odwołania do „nowej” bazy danych na serwerze produkcyjnym.

Bywa jednakże tak – zwłaszcza na dalszych etapach prac – że przydaje się posiadanie lokalnych plików oraz produkcyjnej bazy danych. Wówczas często rodzi się trudność związana z ograniczeniem wprowadzanym często przez firmy hostingowe. Przez to ograniczenie Twoja strona może się łączyć z bazą danych tylko, jeśli jest na tym samym serwerze.

Pliki znajdujące się na lokalnym komputerze nie będą do bazy dopuszczone. Firma hostingowa często domyślnie blokuje dostęp do bazy z hostów zewnętrznych. Jest to polityka dość sensowna, ograniczająca możliwość ataków na bazę. W tym wypadku utrudnia jednak pracę.

Aby sobie z tym poradzić, w panelu administracyjnym firmy hostingowej dopisz konkretny adres IP, jako dozwolony dla danej bazy danych. Alternatywnie zastosuj znak procent, który w MySQL oznacza dowolny ciąg znaków. Uważaj jednak, bo wówczas baza produkcyjna na serwerze firmy hostingowej będzie dopuszczała ruch z każdego adresu IP. To na pewno wygodne, ale niekoniecznie dobre z punktu widzenia bezpieczeństwa rozwiązana. Umiem sobie wyobrazić takie ustawienie na czas prac, kiedy jeszcze w systemie nie ma produkcyjnych danych. Zdecydowanie radzę jednak docelowo ograniczyć dostęp do bazy do localhost oraz ewentualnie adresu IP Twojego komputera, z którego pracujesz.

Oczywiście bazy danych MySql także mają swoje wersje, a w firmach hostingowych można spotkać takie mechanizmy jak Percona czy MariaDB. Są one jednak zasadniczo zgodne z tym, co masz dostępne w XAMPP. Podczas moich prac nie napotkałem żadnej sytuacji, w której to wersja silnika bazodanowego powodowałaby problemy przy przełączaniu między środowiskiem rozwojowym a produkcyjnym, tym niemniej może wynika to z dość podstawowych poleceń SQL, jakie stosuję w moich projektach. Zdecydowanie większy wpływ na działanie aplikacji ma w praktyce zachowanie zgodności wersji PHP.

XAMPP a… ukośniki! Serio!

Na koniec – co nie znaczy, że jest to najmniej ważne – ukośniki. Generalnie występują ich dwa typy –forward slash i back slash – pierwszy z nich oddziela ścieżki w Linuksie i adresach URL, drugi zaś w Windowsie. Slash w jedną bądź w drugą stronę ma zatem zasadnicze znaczenie.

Forward Slash „/”

Oddziela elementy adresu url, na przykład cyberfolks.pl/blog/wpis.

Używasz do ścieżek w systemie Linux.

Windows zazwyczaj radzi sobie z prawidłowym interpretowaniem do rozdzielania ścieżek.

Back Slash „\”

Oddziela folndery w systemach Windows, przykładowo: C:\Windows\

W programowaniu najczęściej używany jako znak ucieczki, do tzw. escapowania znaków specjalnych. Np. $a=”Cośtam\”więcej\” albo i mniej”; pozwoli na przechowanie cudzysłowia wewnątrz zmiennej $a;

Jeszcze więcej o XAMPP?

Miło mi, że jesteś w tym punkcie wpisu. Planuję kolejne publikacje na temat XAMPP, natomiast ich ukazanie się jest uzależnione od zainteresowania. Jeśli więc uważasz, że warto, że temat jest ciekawy lub przydatny – daj znać w komentarzu!

Powodzenia z Twoimi projektami 🙂 A może napotkałeś inne problemy podczas przenoszenia projektów ze środowiska XAMPP na serwer produkcyjne? Napisz w komentarzu, jakie są Twoje doświadczenia z rozwiązaniami typu XAMPP/WAMP Server. A może jako deweloper uważasz, że inni, zwłaszcza początkujący, mogą napotkać opisane sytuacje? Podziel się treścią w sieciach społecznościowych, koledzy na pewno będą Ci wdzięczni.

Zapraszam do dyskusji.

>
Artur Pajkert
Od 18 lat dzieli się wiedzą i poradami w sprawach e-marketingu i hostingu, jako menedżer, autor publikacji, prelegent, bloger, wykładowca akademicki.

2 odpowiedzi na "Xampp – Jak sprawić, żeby działało na produkcji…"

  1. Filip pisze:

    Z Xamppem miałem pierwszy raz do czynienia w technikum informatycznym. Może się to wydawać śmieszne, ale nie rozumiałem przez długi czas sensu używania tego narzędzia. Teraz regularnie używam do testowania WP i wtyczek lokalnie. Póki co bez żadnych problemów z ewentualnym przenoszeniem danych.

    1. Artur Pajkert pisze:

      Ja zacząłem używać go w epoce, kiedy internet mobilny nie był tak powszechny. Uruchomienie środowiska serwera www na laptopie dawało wówczas ogromną wygodę pracy nad projektami w dowolnym miejscu. Do dziś cieszę się łatwością, z jaką mogę posługiwać się lokalnym serwerem www. Dzięki za komentarz i… cieszę się, że w Twoim wypadku nie było problemów z migrowaniem projektów na produkcję 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Polecane dla Ciebie

Szukasz dalej?