Envato Elements - pobieraj co chcesz, ile chcesz

Poprosił mnie znajomy o przygotowanie wtyczki do WordPressa na bazie jednego z opublikowanych poradników, bo chciał w niej zawrzeć pewne modyfikacje (dodatkowe opcje) i nie bardzo wiedział jak się do tego zabrać. Z racji tego, że była to dość specyficzna potrzeba, uznałem, że nie będę tworzył powiązanego z nią poradnika, a najszybciej będzie, jak po prostu mu to napiszę, zamiast tłumaczyć co i jak… Przygotowałem wtyczkę, wysłałem do znajomego, ten postanowił (słusznie) do niej zajrzeć, by zobaczyć co i jak zrobiłem. Przy tej okazji zwrócił mi uwagę, że choć wtyczka działa, to chyba znalazł w niej mały błąd…

Tag zamykający PHP i „blank line before XML declaration” (WordPress)

Zacznę od tego, że choć znam kilka języków programowania w stopniu być może nawet sporo większym niż podstawowy, to nigdy za programistę się nie uważałem. Raczej jestem administratorem czy wdrożeniowcem, czyli osobą, która kieruje pracami, by osiągnąć zamierzony efekt (taki menedżer projektów ze sporym bonusem). Dlatego tym bardziej dopuszczałem możliwość, że gdzieś jakiś błąd mogłem popełnić.

Po (bardzo) krótkiej wymianie zdań dowiedziałem się, na czym polega ów potencjalny błąd – zapomniałem o tagu zamykającym blok języka PHP. W większości poradników, które publikuje, kod PHP znajduje się między tagiem otwierającym i zamykającym blok języka PHP:

<?php
[jakiś kod PHP]
?>

Jest to zapis jak najbardziej prawidłowy, z którego sam często korzystam, stąd też pojawia się on „dla porządku” w poradnikach. We wspomnianej wtyczce zastosowałem jednak kod wg schematu:

<?php
[jakiś kod]

Tak więc kolega miał rację, przynajmniej częsciowo – tagu (taga? ;-)) zamykającego blok języka PHP faktycznie tam nie było, ale nie dlatego, że o nim zapomniałem, tylko było to celowe działanie.

W przypadku języka PHP tag zamykający blok kodu jest opcjonalny, czyli możemy go zastosować, ale nie musimy. Jeśli po kodzie PHP nie występują inne elementy (np. HTML), to nie tylko nie trzeba zamykać, ale w wielu przypadkach nawet lepiej tego nie robić. Dotyczy to sytuacji, gdy taki plik jest wczytywany przez inne pliki (np. funkcja include/include_once), czyli działa w pewnym sensie jako jeden z wielu wczytywanych modułów.

Takie działanie (brak tagu zamykającego) zabezpiecza nas m.in. przed tzw. „białymi/pustymi liniami”, które mogą się znaleźć w pliku PHP za znacznikiem ?>, i tym samym potencjalnie mogą wpłynąć na działanie strony. Czasem „tylko” od strony wyglądu, ale zdarza się, że takie linie potrafią przysporzyć sporo poważniejszych problemów, np. z generowaniem niepoprawnego pliku XML kanału RSS/feed w WordPressie (dość popularny błąd „blank line before XML declaration”), co może skutkować nieprawidłowym działaniem kanału RSS.

(!) Zgłoś błąd na stronie
Potrzebujesz profesjonalnej pomocy? Skontaktuj się z nami!

Spodobał Ci się artykuł? Zapisz się do naszego Newslettera - ZERO SPAMu, same konkrety, oraz dostęp do dodatkowych materiałów przeznaczonych dla subskrybentów!

Na podany adres e-mail otrzymasz od nas wiadomość e-mail, w której znajdziesz link do potwierdzenia subskrypcji naszego Newslettera. Dzięki temu mamy pewność, że nikt nie dodał Twojego adresu przez przypadek. Jeśli wiadomość nie przyjdzie w ciągu najbliższej godziny (zazwyczaj jest to maksymalnie kilka minut) sprawdź folder SPAM.

Patryk

CEO Webinsider.pl, a do tego CTO, CIO, CFO, CMO, CSO, COO i CRO ;-)
Pasjonat nowych technologii - od sprzętu po oprogramowanie, od serwerów po smartfony i rozwiązania IoT. Potencjalnie kiepski bloger, bo nie robi zdjęć "talerza" zanim zacznie jeść.

Dumny przyjaciel swoich psów :-)