mmCache na Home.pl

Jeśli ktokolwiek zastanawia się nad używaniem Turck mmCache, a przynajmniej jego wersji proponowanej przez Home.pl, to niech lepiej zastanowi się jeszcze kilka razy.

Problemy pierwszy raz pojawiły się jakieś pół roku temu, kiedy to przenosiłem serwis Teatru Muzycznego Capitol (ja odpowiadam tam tylko za system ekstranetowy, więc proszę mnie nie posądzać o autorstwo kodu HTML strony) na serwery Home.pl. Zwykle kod PHP szyfrujemy za pomocą ionCube, Home.pl nie udostępnia ichniego loadera, więc zmuszony byłem użyć wspieranego przez Home, darmowego mmCache.

Z początku wszystko wydawało się działać, problem pojawił się dopiero drugiego dnia, kiedy to ktoś z pracowników Teatru postanowił wygenerować sobie plik PDF z planem zajęć. Skrypt zadyszał ciężko, parsknął błędem i legł w konwulsjach cyfrowego bólu w ostatnich stadiach komputerowej agonii. Innymi słowy, nie działało. Winna okazała się biblioteka obsługi PDF, która działa doskonale, lecz tylko do momentu jej zakodowania przez mmCache.

Skończyło się więc na rozkodowaniu biblioteki, która i tak jest darmowa. Nic wielkiego. Problem powrócił jednak w lutym, kiedy to pisałem kolejne moduły dla Teatru i okazało się, że jakimś cudem encoder mmCache psuje obsługę tablic. Dynamicznie generowana tablica stringów przed zakodowaniem wyglądała tak:

array
(
	0 => "lorem",
	1 => "ipsum",
	2 => "dolor",
	3 => "sit",
	4 => "amet"
)

Po zakodowaniu zaś:

array
(
	0 => array
	(
		1 => "lorem"
	),
	1 => array
	(
		1 => "ipsum"
	),
	2 => array
	(
		1 => "dolor"
	),
	3 => array
	(
		1 => "sit"
	),
	4 => array
	(
		1 => "amet"
	)
)

Nie wiem, z czego to wynika, czy błąd leży po stronie mmCache, czy jego konkretnej konfiguracji na serwerach Home.pl. Skończyło się na przepisywaniu części kodu do postaci przewidywalnej w działaniu po potraktowaniu encoderem. Zastanówcie się więc przed używaniem tego wynalazku, tylko pamiętajcie, że ostrzegałem.