PHP: Błąd "Strict Standards: Redefining already defined constructor for class".
Podczas pisania pracy inżynierskiej natknąłem się na kilka ciekawych miejsc w kodzie, “produkujących” nieznane mi do tej pory błędy. Być może miałem świadomość ich istnienia, ale nie udało mi się jeszcze ich “popełnić”. W dzisiejszym wpisie chciałbym przedstawić Wam kolejny problem, tym razem dotyczący pewnych starszych mechanizmów języka PHP. Zapraszam do lektury. Wstęp: “obiektowość” PHP4. Zarówno wpis z wtorku, traktujący problemach związanych głównie z zagapieniem się programisty, jak i dzisiejszy wyjaśniający nieco dziwne podejście PHP do wprowadzonego przez niego w wersji piątej modelu obiektowości to konsekwencja całkiem sporej bazy kodu, jaki powstał podczas implementacji mojego frameworka.
PHP: Błąd "Can't use function return value in write context".

W pracy programisty czasem zdarzają się sytuacje, kiedy pomyłka nie wynika z niewiedzy ani braku doświadczenia osoby piszącej, ale zwykłego zagapienia się i postawienia “innego znaczka” w miejsce tego poprawnego. Tego typu błędy potrafią być bardzo uciążliwe, ponieważ wydaje nam się, że napisaliśmy wszystko poprawnie i bezskutecznie szukamy błędu wpatrując się w kilka linijek, które po prostu “muszą działać”. W dzisiejszym wpisie chciałbym przedstawić problem, który może utrudnić pracę, szczególnie, jeśli jesteśmy już zmęczeni i nie dostrzegamy wszystkich szczegółów na ekranie.

Błąd: Can’t use function return value in write context.

Weźmy pod uwagę poniższy kod:

[WampServer] Błąd: The configuration file contains a syntax error on line n: [EParseError] Invalid Section tag.

Jakiś czas temu miałem nieodpartą chęć spróbowania nowych funkcjonalności, jakie wprowadzono w PHP 5.3. Przestrzenie nazw oraz late static binding, to tylko niektóre z bardzo przydatnych nowości - na pewno doceni to niejeden programista. Jednak ze względu na fakt, że życie w moim [naszym? ;]] zawodzie nie jest usłane różami, nawet sama aktualizacja instalacji serwera lokalnego przysporzyła trochę problemów. Jednym z nich jest błąd w plikach konfiguracyjnych, którego naprawę opiszę dzisiaj.

Problem.

Dzisiejszy post traktuje o bardzo “brzegowej” sytuacji, która w wielu przypadkach uniemożliwia pracę serwera lokalnego opartego o instalację pakietu WampServer.

[PHP] Błąd: Call-time pass-by-reference has been deprecated.
Od pewnego czasu korzystam z pewnej bardzo ciekawej aplikacji pomagającego w zarządzaniu projektami. Redmine, bo tak jej “na imię” spełnia praktycznie wszystkie moje wymagania w tym zakresie, poza faktem, że jej wydajność jest “mocno średnia” [jest napisana w Ruby on Rails]. Dzisiaj jednak siadając przy komputerze stwierdziłem, że spróbuję czegoś nowego. Ze względu na to, że miałem przez chwilę styczność z polecanym przez jednego z kolegów OpenGoo zaprosiłem “na warsztat” właśnie ten “kawałek kodu”.
[PHP, (My)SQL] Systemy uprawnień na stronach internetowych, część 0×02: Poziomy użytkowników.

Przyznaję bez bicia, że od ostatniego wpisu w tej serii upłynęło [zbyt] wiele czasu, za co ponoszę winę jedynie ja, ponieważ dopisywałem po jedno - dwa zdania co jakiś czas, ale ogólnie post “wisiał” na liście szkiców i “grzał ławkę”, nie mogąc się doprosić o solidne dokończenie i wejście na “boisko” strony głównej niniejszego bloga. W związku z tym postaram się dzisiaj i za tydzień zamieścić ostatnie części, tak, aby można było zamknąć temat. Przy tworzeniu kolejnej tego typu serii będę musiał chyba od razu napisać wszystkie części i po prostu publikować je w pewnych odstępach czasu, bo w tym tempie to kolejny wpis ukazałby się pewnie w listopadzie. ;] Ale do rzeczy: w jednym z poprzednich wpisów omówiliśmy najprostszy system zarządzania uprawnieniami, czyli autoryzację na podstawie flagi dostępu do danej sekcji strony. Dzisiaj rozszerzymy to rozwiązanie pozwalając na większą kontrolę i możliwość konfiguracji miejsc, do których ma dostęp nasz użytkownik.

Na czym to polega?

Opisany wcześniej sposób autoryzacji nie jest optymalny, ponieważ w podstawowej wersji pozwala na podzielenie użytkowników na jedynie dwa typy - tych którzy mają dostęp do treści “ukrytych” i tych, którzy muszą się “obejść smakiem”. Wprowadzanie kolejnych kolumn opisanych jako obszary dostępu także nie zdaje egzaminu - przy rozrastającym się systemie musielibyśmy stworzyć tabelę posiadającą kilkadziesiąt, jeśli nie kilkaset kolumn w stylu “allow_[nazwa obszaru]“. Tutaj z pomocą przychodzi nowy pomysł - poziomy użytkowników.

[PHP] Zapisywanie zserializowanych obiektów do sesji i błąd __PHP_Incomplete_Class.

W kwestii obsługi sesji i rodzaju zapisywanych w niej danych programiści PHP dzielą się na dwa skrajne fronty: tych, którzy preferują zapis wyłącznie typów prostych i tych, którzy nie widzą problemu w trzymaniu w niej całych obiektów. Ja stoję murem za typami prostymi, ponieważ wydaje mi się bardziej optymalne zapisywanie tylko niezbędnych informacji, na podstawie których ewentualne obiekty można odtworzyć, pozwala to też na zmniejszenie obciążenia serwera, bo odczytanie sesji wymaga deserializacji [odserializowania? deserializowania? kolejne "ciężkopolskie" słowo...] i parsowania o wiele mniejszego pliku. Jakkolwiek byśmy jednak do tego nie podchodzili, dzisiejszy wpis także może być argumentem in plus dla zapisywania wyłącznie zmiennych typów prostych, ponieważ jak mówi stare programistyczne porzekadło: "Serializujesz obiekty [do sesji]? No to masz problem!". ;]

Problem.

Oczywiście dla równowagi mogę powiedzieć, że osoby podzielające moje zdanie na ten temat także nie należą do tych, które nie mają żadnych problemów z zarządzaniem sesjami, jednak na pewno nie są to problemy aż takiego kalibru / typu. Co mam więc tym razem na myśli? Rozważmy następującą sytuację [zmienne proste]:

[Symfony] Błąd: "You must be in a symfony project directory".

Zaliczyłem już większość przedmiotów i coraz wyraźniej widzę, że chyba w sesji będę mógł w końcu odpocząć. Zostały jednak jeszcze dwa projekty do zrobienia, co zajmuje całkiem sporo czasu. Najgorsze jest to, że te projekty nie są specjalnie trudne, po prostu nie mogę się zmusić, żeby popracować dłużej i bardziej produktywnie. W każdym razie cały czas “dłubię” we frameworku Symfony, więc niech nie zdziwi Was kilka kolejnych wpisów na ten sam temat - na pewno kiedyś Wam się przydadzą. ;] Dzisiaj także ze względu na ograniczony czas porada będzie krótka i prosta. Ale już w lutym obiecuję być bardziej produktywny [oczywiście jeśli będę przy komputerze] i dokończyć te wpisy, które cierpliwie czekają jako szkice. Ale do dzieła:

Problem.

Struktura katalogów wygląda następująco: framework zainstalowany jest w drzewie /lib/vendor projektu, a do katalogu głównego zostały skopiowane pliki symfony i symfony.bat z drzewa /lib/vendor/symfony/data/bin, żeby było łatwiej wywołać polecenia obsługi. Zechciałem sobie nieco bardziej ułatwić życie zmieniając nazwę skryptu:
mv symfony.bat sf.bat
jednak docelowy dostęp przez [kropka] [slash] [S] [Tab] nie działał, ze względu na obecność pliku symfony. Zmieniłem więc nazwę głównego skryptu:
mv symfony _symfony
i przerobiłem skrypt batch: