phpFashion

Na navigaci | Klávesové zkratky

Rubrika PHP

Co nevíte o output bufferingu v PHP

A co se ani v dokumentaci nedočtete, včetně záplaty na bezpečnostní díru a rady, jak zrychlit odezvu serveru a naopak ji nezbrzdit.

Output buffering umožňuje, aby výstup PHP skriptu (především funkcí echo) nebyl okamžitě odeslán do prohlížeče nebo terminálu, ale byl uchováván v paměti (tj. bufferu). Což se hodí k celé řadě věcí.

Zabránění vypisování na výstup:

ob_start();  // zapne output buffering
$foo->bar();  // veškerý výstup jde pouze do bufferu
ob_end_clean();  // buffer smaže a ukončí buffering

Zachytávání výstupu do proměnné:

ob_start();  // zapne output buffering
$foo->render();  // výstup jde pouze do bufferu
$output = ob_get_contents();  // obsah bufferu uloží do proměnné
ob_end_clean();  // buffer smaže a ukončí buffering

Dvojici ob_get_contents() a ob_end_clean() lze nahradit jedinou funkcí ob_get_clean(), z jejíhož názvu se sice vytratilo end, ale skutečně output buffering i vypíná:

$output = ob_get_clean();  // obsah bufferu uloží do proměnné a vypne buffering

V uvedených příkladech se obsah bufferu na výstup vůbec nedostal. Pokud jej naopak na výstup poslat chci, namísto ob_end_clean() jej ukončím funkcí ob_end_flush() . Pro současné získání obsahu bufferu, odeslání na výstup a ukončení bufferování existuje opět zkratka (i včetně chybějícího end v názvu): ob_get_flush().

Buffer lze kdykoliv vyprázdnit i bez nutnosti jej ukončit, a to pomocí ob_clean() (smaže jej) a nebo ob_flush() (pošle jej na výstup):

ob_start();  // zapne output buffering
$foo->bar();  // veškerý výstup jde pouze do bufferu
ob_clean();  // smažu obsah bufferu, ale buffering zůstává aktivní
$foo->render(); // výstup jde stále do bufferu
ob_flush(); // buffer posílám na výstup
$none = ob_get_contents();  // obsah bufferu je nyní prázdný řetězec
ob_end_clean();  // vypne output buffering

Do bufferu se posílá i výstup zapisovaný na php://output, naopak buffery lze obejít zápisem na php://stdout (nebo do STDOUT), což je k dispozici pouze pod CLI, tedy při spouštění skriptů z příkazové řádky.

Zanoření

Buffery je možné zanořovat, takže zatímco je jeden buffer aktivní, dalším voláním ob_start() se aktivuje buffer nový. Tedy ob_end_flush() a ob_flush() neposílají obsah bufferu na výstup, ale do nadřazeného bufferu. A teprve když žádný nadřazený není, posílá se obsah na skutečný výstup, tj. do prohlížeče nebo terminálu.

Proto je důležité buffering ukončit, a to i v případě, že v průběhu nastane výjimka:

ob_start();
try {
    $foo->render();
} finally {  // finally existuje od PHP 5.5
    ob_end_clean(); // nebo ob_end_flush()
}

Velikost bufferu

Buffer může také zrychlit generování stránky tím, že se do prohlížeče nebude odesílat každé jednotlivé echo, ale až větší objem dat (například 4kB). Stačí na začátku skriptu zavolat:

ob_start(null, 4096);

Jakmile velikost bufferu překročí 4096 bajtů (tzv. chunk size), automaticky se provede flush, tj. buffer se vyprázdní a odešle ven. Téhož se dá dosáhnout i nastavením direktivy output_buffering. V CLI režimu se ignoruje.

Ale pozor, spuštění bufferingu bez uvedení velikosti, tedy prostým ob_start(), způsobí, že se stránka nebude neodesílat průběžně, ale až se vykreslí celá, takže server bude naopak působit velmi líně!

HTTP hlavičky

Output buffering nemá žádný vliv na odesílání HTTP hlaviček, ty se zpracovávají jinou cestou. Nicméně díky bufferingu je možné odeslat hlavičky i poté, co se vypsal nějaký výstup, jelikož se stále drží v bufferu. Ovšem jde o vedlejší efekt, na který neradno spoléhat, protože není jistota, kdy výstup překročí velikost bufferu a odešle se.

Bezpečnostní díra

Při ukončení skriptu se všechny neukončené buffery vypíší na výstup. Což lze považovat za nepříjemnou bezpečnostní díru, pokud si například v bufferu připravujete citlivá data, která nejsou určená pro výstup a dojde přitom k chybě. Řešením je použít vlastní handler:

ob_start(function () { return ''; });

Handlery

Na output buffering lze navázat vlastní handler, tj. funkci, která obsah paměti zpracuje před odesláním ven:

ob_start(
    function ($buffer, $phase) { return strtoupper($buffer); }
);
echo 'Ahoj';
ob_end_flush(); // na výstup se dostane AHOJ

I funkce ob_clean() nebo ob_end_clean() vyvolají handler, ale výstup zahodí a ven neposílají. Přičemž handler může zjistit, která funkce je volána a reagovat na to. Používá se k tomu druhý parametr $phase, což je bitová maska (od PHP 5.4):

  • PHP_OUTPUT_HANDLER_START při otevření bufferu
  • PHP_OUTPUT_HANDLER_FINAL při ukončení bufferu
  • PHP_OUTPUT_HANDLER_FLUSH při volání ob_flush() (ale nikoliv ob_end_flush() nebo ob_get_flush())
  • PHP_OUTPUT_HANDLER_CLEAN při volání ob_clean(), ob_end_clean()ob_get_clean()
  • PHP_OUTPUT_HANDLER_WRITE při automatickém flush

Fáze start, final a flush (resp. clean) mohou klidně nastat současně, rozliší se pomocí binárního operátoru &:

if ($phase & PHP_OUTPUT_HANDLER_START) { ... }
if ($phase & PHP_OUTPUT_HANDLER_FLUSH) { ... }
elseif ($phase & PHP_OUTPUT_HANDLER_CLEAN) { ... }
if ($phase & PHP_OUTPUT_HANDLER_FINAL) { ... }

Fáze PHP_OUTPUT_HANDLER_WRITE nastává jen tehdy, pokud má buffer velikost (chunk size) a ta byla překročena. Jedná se tedy o zmíněný automatický flush. Jen pozor, konstanta PHP_OUTPUT_HANDLER_WRITE má hodnotu 0, proto nelze použít bitový test, ale:

if ($phase === PHP_OUTPUT_HANDLER_WRITE) { .... }

Handler nemusí podporovat všechny operace. Při aktivaci funkcí ob_start() lze jako třetí parametr uvést bitovou masku podporovaných operací:

  • PHP_OUTPUT_HANDLER_CLEANABLE – lze volat funkce ob_clean() a související
  • PHP_OUTPUT_HANDLER_FLUSHABLE – lze volat funkci ob_flush()
  • PHP_OUTPUT_HANDLER_REMOVABLE – buffer lze ukončit
  • PHP_OUTPUT_HANDLER_STDFLAGS – je kombinací všech tří flagů, výchozí chování

Tohle se týká i bufferingu bez vlastního handleru. Například pokud chci zachytávat výstupu do proměnné, nenastavím flag PHP_OUTPUT_HANDLER_FLUSHABLE a buffer tak nebude možné (třeba omylem) poslat na výstup funkcí ob_flush(). Nicméně lze tak učinit pomocí ob_end_flush() nebo ob_get_flush(), takže to poněkud ztrácí smysl.

Obdobně by měla absence flagu PHP_OUTPUT_HANDLER_CLEANABLE zamezit mazání bufferu, ale opět to nefunguje.

A nakonec absence PHP_OUTPUT_HANDLER_REMOVABLE činní buffer uživatelsky neodstranitelný, vypne se až při ukončení skriptu. Příkladem handleru, který je vhodné takto nastavit, je ob_gzhandler, který komprimuje výstup a tedy snižuje objem a zvyšuje rychlost datového přenosu. Jakmile se tento buffer otevře, odešle HTTP hlavičku Content-Encoding: gzip a veškerý další výstup musí být komprimovaný. Odstranění bufferu by rozbilo stránku.

Správné použití je tedy:

ob_start(
    'ob_gzhandler',
    16000, // bez chunk size by server data neodesílal průběžně
    PHP_OUTPUT_HANDLER_FLUSHABLE // ale ne removable nebo cleanable
);

Komprimaci výstupu můžete aktivovat také direktivou zlib.output_compression, která zapne buffering s jiným handlerem (netuším, v čem konkrétně se liší), bohužel chybí příznak, že má být neodstranitelný. Protože je vhodné komprimovat přenos všech textových souborů, nejen v PHP generovaných stánek, je lepší kompresi aktivovat přímo na straně HTTP serveru.




Dibi 3.0 je venku, Texy na cestě

Zmodernizoval jsem kód knihoven Dibi a Texy, třídy přenesl do jmenných prostorů a využil syntaxe PHP 5.4. Zároveň jsem doplnil mechanismus, aby knihovny fungovaly i s existujícím kódem, který používá původní názvy tříd.

Výsledkem je Texy 2.8 (release notes) a Dibi 3.0 (release notes).

Dibi mělo nést původně označení 2.4, protože krom vnitřního refactoringu jsem nechtěl přidávat nebo měnit jakoukoliv funkčnost, jako u Texy 2.8, ale nakonec jsem pár vychytávek přidal a výsledkem je právě verze 3.0:

  • nové výjimky Dibi\ConstraintViolationException, ForeignKeyConstraintViolationException, NotNullConstraintViolationExceptionUniqueConstraintViolationException
  • MySQL: sloupec TIME se převádí na objekty DateInterval namísto DateTime (BC break)
  • SqlsrvDriver: doplněna podpora pro LIMIT & OFFSET
  • vylepšen Dibi\Fluent při použití limit & offset

Zmizely ovladače pro SQLite 2 a MsSqlDriver, které nejsou od PHP 5.3 podporované, a MsSql2005Driver se nyní jmenuje SqlsrvDriver (funguje i starý název). Statická třída dibi zůstává mimo jmenné prostory. Pokud si píšete vlastní ovladač, došlo ke změně v rozhraní u metod escape() & unescape() (viz).

Minimální požadovaná verze PHP je 5.4.4, obě knihovny jsou plně funkční i pod PHP 7. Minifikovaná verze je ve formě archívu PHAR.

Dibi postupně pokrývám testy. Jelikož nepoužívám MS SQL Server, je tento driver víceméně v rukou komunity. Pokud jej používáte, zkuste prosím zjistit, proč neprocházejí testy používané pro jiné servery a co je potřeba změnit.

Velmi pozvolna vzniká i Texy 3.0, ze kterého zmizí dnes už překonané funkce, jako je třeba podpora jiného kódování než UTF-8, jiného formátu než HTML5 atd.


Jak vyvíjet komfotrněji?

Nová verze Nette 2.3.7 přináší spoustu vylepšení, jedno z nich si ale rychle zamilujete. Jsou to chybové hlášky, které se vám pokusí napovědět, pokud uděláte překlep.

Určitě jste už někdy narazili na podobnou chybu:

Chcete v šabloně vykreslit komponentu a ona prý neexistuje. Může to mít celou řadu příčin, od nějakého opomenutí na straně presenteru, až po chybu v šabloně. Nebo se komponenta jmenuje jinak?

Nejhorší ze všeho jsou triviální přelkepy, které nevidíte, takže několikrát prověříte všechny možnosti a strávíte na tom dost času, než chybu odhalíte.

Nejnovější verze Nette má ale šikovnější chybovou hlášku:

Did you mean ‚signInForm‘? Aha! Hned je jasné, že na vině byl překlep a můžete ho rovnou opravit.

Pokud jste se někdy dlouze zasekli na velikosti písmenek, tj. že vám {control MyComponent} hlásil chybu Component with name ‚MyComponent‘ does not exist, o to více oceníte dovětek did you mean ‚myComponent‘?.

Pojďme k Nette\Database. Chybka v názvu databázového sloupce? Opět ji dostanete na stříbrném podnose:

Mimochodem, stejná feature bude i v příští verzi dibi, kterou prosím před vydáním otestujte.

Nette napovídá překlepy v názvech funkcí, metod, proměnných atd. Pokud vyvíjíte v IDE, neměly by se vám podobné chyby stávat, na druhou stranu málokteré IDE dokáže plnohodnotně napovídat třeba v šablonách. Ať už se spletete v názvu filtru nebo makra:

Případně v názvu proměnné:

Hláškou did you mean novinky zvyšující pohodlí nekončí. Nette vás nově upozorní na celou řadu dalších, dříve špatně odhalitelných, chyb. Jako například chybějící []

$myForm->onSuccess = [$this, 'myFormSucceeded'];
// namísto správného
$myForm->onSuccess[] = [$this, 'myFormSucceeded'];

nebo chybějící ()

{foreach $form->getErrors as $error}
// namísto správného
{foreach $form->getErrors() as $error}

či docela nebezpečné opomenutí, jelikož $user->isLoggedIn je vždy truthy:

{if $user->isLoggedIn} ... něco tajného ... {/if}
// namísto správného
{if $user->isLoggedIn()} ... něco tajného ... {/if}

To nyní povede k varování Did you forget parentheses after isLoggedIn?

Poznámka: pokud záměrně píšete v kódu metodu bez závorek, tj. $cb = $obj->getItems, protože chcete využít vlastnosti Nette\Object, která takto do $cb uloží callback na metodu getItems, a objeví se varování, použijte prosím standardní PHP zápis, tj. $cb = [$obj, 'getItems']. Při korektních běžných použitích se varování nezobrazuje.

Dále Latte vás upozorní, když použijete modifikátor na místě, kde se ignoruje, jako například:

{if $var |filter}

Did you mean „komfortněji“?

Nová verze Nette je tu od toho, aby vám usnadnila a zpříjemnila vývoj. A jak je to napovídání boží si doopravdy uvědomíte, až to vyzkoušíte.


Chrome a nekonečné přesměrování

Chrome 44 (beta) odesílá nově hlavičku HTTPS: 1, která může způsobovat problémy.

Na některých hostinzích (z těch co používám třeba WebSupport už to opravili) si pak PHP myslí, že požadavek je pod šifrovaným spojením HTTPS. Tj. proměnná $_SERVER['HTTPS'] === 'on'.

U aplikací v Nette, které neběží pod https, to pak způsobí nekonečný redirect. Aplikace si prostě myslí, že k ní přistupujete přes URL https://example.com a přesměrovává na http://example.com.

Můžete to vyzkoušet z příkazové řádky pomocí:

curl -I --header "HTTPS: 1" http://example.com`

Že je hlavička HTTPS: 1 problematická se už ví, takže je možné, že se změní a do Chrome nedostane. Každopádně jako rychlý workaround, aby nedocházelo ke smyčce přesměrování v betaverzi Chrome, je přidat na začátek bootstrap.php:

unset($_SERVER['HTTPS']);

Zároveň je dobré si uvědomit, že na některých hostinzích lze detekci šifrovaného spojení velmi snadno ošálit.

Doplnění: Chrome 45 už hlavičku HTTPS: 1 neodesílá.


Jak na převod array() na [] v Gitu

Jak jsem v projektech, které používají PHP 5.4 a vyšší, převáděl starou syntaxi pro zápis polí array() na novou [].

Samotný převod PHP souborů je úplně jednoduchý. Stačí použít PHP 5.4 Short Arrays Converter a v repozitáři zavolat:

php /php54-arrays/convert.php .

Nástroj zamění syntax ve všech souborech *.php a *.phpt v aktuálním adresáři a také ve všech podadresářích. Změněné soubory jsem pak komitnul (příklad).

Oříšek je ale rebasování dalších větví na takto změněný master.

Nakonec jsem na to šel přes filtry. Ale plně zautomatizovat se mi to nepovedlo.

Nejprve je vhodné všechny větve rebasovat na master těsně před samotnou změnou syntaxe.

Poté jsem si vytvořil filtr nazvaný phparray, který bude on-the-fly překládat v PHP souborech [] na array() při checkoutu a obráceně při komitování. Tedy aby slučování probíhalo při použití staré syntaxe, ale komitnulo se s novou.

Filtr se vytvoří v souboru .git/config, v mém případě to vypadalo takto:

[filter "phparray"]
    clean = c:/php/php.exe w:/php54-arrays/convert.php
    smudge = c:/php/php.exe w:/php54-arrays/convert.php -r
    required

Aby se filtr při slučování používal (ale i při každém checkoutu, cherry-picku atd), je nutné doplnit do .git/config ještě následující:

[merge]
    renormalize = true

Filtr se bude aplikovat na soubory *.php a *.phpt, což se definuje v souboru .git/info/attributes (nepoužívejte .gitattributes, protože jde o dočasnou záležitost a nechceme ji komitovat):

*.php filter=phparray
*.phpt filter=phparray

Teď by ve větvi mělo fungovat git rebase master. Bez konfliktů, které by bylo nutné ručně řešit. Jenže ouha, konflikty se mi vytvářely (na Windows; je možné, že na Linuxu to půjde) a když jsem je chtěl řešit v TortoiseGit, objevovala se hláška, že na souboru .git/index.lock je zámek atd. Zkoušel jsem experimentovat s dalšími nastaveními pro merge, ale bez výsledku.

Zkusil jsem dělat rebase ručně: což znamená nejprve větev resetnout na master (git reset master --hard) a pak jednotlivé komity přidávat pomocí git cherry-pick <hash>. Nedělal jsem to z příkazové řádky, ale pomocí TortoiseGit. I nadále mi hlásil, že některé soubory neumí automaticky sloučit a je vyžadován ruční zásah, ale vždy stačilo soubor rozkliknout do TortoiseGitMerge a rovnou stisknout Mark as resolved.

Bylo to otravné, ale fungovalo to a postupně jsem „rebasoval“ všechny větve. Poté jsem filtr z .git/config a .git/info/attributes smazal.

Proč to nešlo úplně automaticky, nemám páru, nicméně bylo snazší hodinu klikat, než dva dny studovat Git.


PHP 5.4 Short Arrays Converter

Command-line script to convert between array() and PHP 5.4's short syntax []. It uses native PHP tokenizer, so conversion is safe. The script was successfully tested against thousands of PHP files.

Download from GitHub

To convert all *.php and *.phpt files in whole directory recursively or to convert a single file use:

php convert.php <directory | file>

To convert source code from STDIN and print the output to STDOUT use:

php convert.php < input.php > output.php

To convert short syntax [] to older long syntax array() use option --reverse:

php convert.php --reverse [<directory | file>]

Composer: jak na různé varianty instalace

Composer, nejdůležitější nástroj pro PHP vývojáře, umožňuje 3 způsoby, jak instalovat balíčky:

  • lokální composer require vendor/name
  • globální composer global require vendor/name
  • jako projekt composer create-project vendor/name

Lokálně

Lokální instalace se používá nejčastěji. Mám projekt, ve kterém chci třeba použít Tracy, tak v kořenovém adresáři projektu zadám:

composer require tracy/tracy

a Composer zaktualizuje (nebo vytvoří) soubor composer.json a stáhne Tracy do podsložky vendor. Zároveň vygeneruje autoloader, takže v kódu jej stačí inkludovat a můžu rovnou Tracy použít:

require __DIR__ . '/vendor/autoload.php';
Tracy\Debugger::enable();

Nástroje

Diametrálně odlišná situace nastává tehdy, pokud místo knihovny, jejíž třídy ve svém projektu používám, instaluji nástroj, který jen spouštím z příkazové řádky.

Příkladem může být třeba ApiGen pro generování přehledných API dokumentací. V takovém případě se použije třetí způsob:

composer create-project apigen/apigen

Composer vytvoří novou složku (a tedy i nový projekt) apigen a do ní stáhne celý nástroj a nainstaluje jeho závislosti.

Bude mít vlastní composer.json a vlastní podsložku vendor.

Tímto způsobem se instaluje i třeba Nette Sandbox nebo CodeChecker. Nikoliv však testovací nástroje jako je Nette Tester nebo PHPUnit, protože jejich třídy naopak v testech používáme, voláme Tester\Assert::same() nebo dědíme od PHPUnit_Framework_TestCase.

Bohužel Composer umožňuje instalovat nástroje jako je ApiGen i pomocí composer require a nevypíše ani žádné varování.

Což je totéž, jako když donutíte dva vývojáře, kteří se ani neznají a kteří pracují na úplně jiném projektu, aby sdíleli společnou složku vendor. Na to se dá říci:

  • Proboha proč by to měli dělat?
  • Vždyť to přece nemůže fungovat!

Ano, není žádný rozumný důvod to dělat, nic to nepřinese, naopak to přestane fungovat v momentě, kdy dojde ke kolizi používaných knihoven. Je to jen otázka času, stavění domečku z karet, který se dřív nebo později sesype. Jeden projekt bude vyžadovat knihovnu XY ve verzi 1.0, druhý ve verzi 2.0 a v tu chvíli to přestane fungovat.

Globálně

Rozdíl mezi variantou 1) a 2), tj. mezi composer require a composer global require, je pak v tom, že nepůjde o dva cizí vývojáře, ale o deset cizích vývojářů a deset nesouvisejících projektů. Tedy je to nesmysl na druhou.

Totiž composer global je špatné řešení úplně vždy, neexistuje use case, kdy by bylo vhodné jej použít. Byl jsem zvědavý, jak se mohlo něco takového dostat do Composeru, a vypadá to, nepletu-li se, že tento nesmysl přidal můj oblíbený troll :-)

(Jako ukázku si můžete globálně nainstalovat dg/composer-global-is-useless. Poté už nepůjde globálně nainstalovat ani PHPUnit.).

Rekapitulace

  • composer require vendor/name pokud chcete používat třídy knihovny
  • composer global require vendor/name nikdy!
  • composer create-project vendor/name pro nástroje volané jen z příkazové řádky

Poznámka: npm používá odlišnou filosofii danou možnostmi JavaScriptu a každou knihovnu instaluje jako „samostatný projekt“, s vlastním adresářem vendor (resp. node_modules). Ke konfliktu verzí tak dojít nemůže. V případě npm naopak platí, že globální instalace nástrojů, jako je například LESS CSS, jsou velmi užitečná a příjemná věc.


Jak na GitHub a pull request z příkazové řádky

Tuhle jsem zveřejnil skript na cherry-pickování přímo z GitHubu, který dodnes používám, ale bylo otravné tím stahovat celé pull requesty, pokud obsahovaly víc komitů. Takže jsem ho naučil stahovat je na jeden zátah. Opět stačí jako argument uvést URL:

php pullpick.php https://github.com/nette/tracy/pull/58

Oproti cherry-picku je potřeba navíc zjistit zdrojový repozitář a větev, k čemuž použijeme GitHub API. Skript vypadá takto:

<?php
$url = @$_SERVER['argv'][1];

if (!preg_match('#github.com/([^/]+)/([^/]+)/pull/(\w+)#', $url, $m)) {
    die('Invalid URL');
}

list(, $name, $repo, $pull) = $m;

$context = stream_context_create(array('http' => array('user_agent' => 'Me')));
$info = file_get_contents("https://api.github.com/repos/$name/$repo/pulls/$pull", false, $context);
$info = json_decode($info);
if (!isset($info->head->repo->clone_url, $info->head->ref)) {
    die('Missing repo info.');
}
passthru("git checkout -b pull-$pull master");
passthru("git pull --no-tags {$info->head->repo->clone_url} {$info->head->ref}");

Pull request se stáhne do nové větve s názvem jako pull-123.

Mám i skript na vytvoření nového pull requestu. Spustíte jej ve větvi, ze které chcete PR vytvořit, bez parametrů. On větev pushne do vašeho forku a poté otevře prohlížeč s formulářem pro vytvoření pull requestu:

<?php
$remote = 'dg'; // tady dejte název 'remote' vedoucí k forku na GitHubu

exec('git remote -v', $remotes);

$repo = null;
foreach ($remotes as $rem) {
    if (preg_match('#^' . preg_quote($remote) . '\tgit@github.com:(.+)\.git \(#', $rem, $m)) {
        $repo = $m[1];
        break;
    }
}

if (!$repo) {
    die('Not Github repo');
}

exec('git rev-parse --abbrev-ref HEAD', $branch);
$branch = $branch[0];
if (!$branch) {
    die('Unable to retrieve branch name');
}

echo "Pushing to $repo & $branch\n";
exec("git push --set-upstream $remote $branch");

$url = "https://github.com/$repo/compare/$branch?expand=1";
exec('start "" ' . $url); // tohle otevře prohlížeč pod Windows. Pro jiné OS si upravte.

phpFashion © 2004, 2017 David Grudl | o blogu

Pokud není uvedeno jinak, podléhá obsah těchto stránek licenci Creative Commons BY-NC-ND Creative Commons License BY-NC-ND

Ukázky zdrojových kódů smíte používat s uvedením autora a URL tohoto webu bez dalších omezení.