Zprovoznění Nette na hostingu Endora

Pár poznámek pro rozpohybování Nette Frameworku na hostingu Endora.

Edit (2014–06–11): na konec článku přidána sekce o adresářové struktuře.

Edit (2013–06–23): Vzhledem k některým změnám, které na Endoře proběhly a proběhnou, se stává následující odstavec a kód zastaralým a neaktuálním. Část o routování by ale měla platit i nadále. Konkrétně došlo na Endoře k výměně eAcceleratoru za Zend Optimizer Plus a od 1. 7. 2013 dojde k nasazení PHP-FPM, takže přestane fungovat i nastavení PHP direktiv pomocí php_flag, php_value a php_admin_value v .htaccess.

1) 500 Server Error

Tato část už neplatí! První věc, která nás po nahrání na server čeká, je vyřešení chyby „500 Server Error“ – jedná se o frameworkem vyhozenou vyjímku, která je zachycená Laděnkou a zalogována. Pokud nahlédneme do souboru error.log, dočteme se zde o něco o neplatném callbacku (Invalid Callback). Framework si prostě nějak na Endoře nerozumí s eAcceleratorem. Proto eAccelerator vypneme v souboru .htaccess:

# kvůli chybě Error 324
php_flag allow_call_time_pass_reference ON

# vypnutí eAccelerator
php_flag eaccelerator.enable 0
php_flag eaccelerator.optimizer 0

2) Routování

Nevím jak na hlavní doméně, ale pokud na Endoře používáte Nette na subdoméně, nebude Vám fungovat routování – HTTP požadavky nebudou vůbec přesměrovány na soubor index.php. Řešením je odkomentovat (případně dopsat) v .htaccess řádek s # RewriteBase /. V souboru .htaccess nám tedy vznikne asi takovýto kód:

...

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# front controller
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !\.(pdf|js|ico|gif|jpg|png|css|rar|zip|tar\.gz)$ index.php [L]
</IfModule>

...

Adresářová struktura

Doplněno 11. června 2014. I když to není takový problém, někomu může dělat potíže rozběhat projekt na Endoře (hlavně na subdoménách), kvůli odlišné adresářové struktuře.

Na Endoře si můžete vybrat mezi 3 způsoby, jak se váš web bude v případě subdomén a obecně všech požadavků chovat:

1. výchozí, všechny požadavky míří do adresáře web, pokud bychom přistupovali např. na adresu fotografie.domena.cz, dojde k nasměrování takového požadavku do složky web/fotografie. K obsahu ve složce fotografie se samozřejmě dostaneme také na adrese domena.cz/fotografie
2. požadavky jsou nasměrovány do adresáře web, při přístupu k subdoméně je požadavek nasměrován do složky sub (např. fotografie.domena.cz ⇒ sub/fotografie)
3. systém se o subdomény nestará a všechny požadavky směruje do složky web, kde si s nimi může majitel webu udělat, co chce (např. vytvořit dynamické subdomény pomocí .htaccess).

Tak a teď to vezmeme postupně. Nebudu se věnovat výchozímu způsobu obsluhy subdomén, protože jsem ho nikdy nepoužíval, ale postup by se měl v mnohém shodovat s ostatními způsoby.

Požadavky do složky sub (varianta 2)

V zásadě máte 2 možnosti. Přizpůsobit adresářovou strukturu svého projektu Endoře, nebo použít klasickou Nette strukturu.

Přizpůsobená struktura

Strukturu si můžeme obecně přizpůsobit následovně:

app    => sub/.tajne/app
temp   => sub/.tajne/temp
log    => sub/.tajne/log
vendor => sub/.tajne/vendor
www    => sub/moje-subdomena

Do složky .tajne se díky té tečce na začátku, nikdo nedostane z venčí i bez blokování přístupu přes .htaccess.

Na lokálním počítači to může pro konkrétní projekt vypadat třeba takto:

projekt/.projekt/app/
projekt/.projekt/log/
projekt/.projekt/temp/
projekt/.projekt/vendor/
projekt/nazev-subdomeny/

V index.php a bootstrapu je samozřejmě potřeba změnit cesty k jednotlivým složkám/souborům.

Pak stačí jen v .htaccess odkomentovat řádek s RewriteBase (viz výše) a vše šlape jak má.

Mimochodem, není potřeba zachovávat tuto strukturu na lokálním počítači při vývoji. Mnohdy tvořím aplikaci za použití klasické Nette struktury a tu pak při nahrávání na server přizpůsobuji konkrétnímu hostingu za pomoci jednoduchého skriptu, který přesune a přejmenuje složky, upraví cesty v index.php a dalších souborech a odkomentuje v případě potřeby RewriteBase.

Klasická struktura

Není problém použít ve složce sub klasickou Nettí strukturu, po nahrání na server to bude vypadat takto:

sub/subdomena/app
sub/subdomena/log
sub/subdomena/temp
sub/subdomena/vendor
sub/subdomena/www

V souboru sub/subdomena/www/.htaccess stačí odkomentovat RewriteBase (viz výše) a ve složce sub/subdomena vytvořit nový .htaccess, který se nám bude starat o přesměrování požadavků do složky subdomena/www. Ten může vypadat třeba takto:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^subdomena\.domena\.cz$
RewriteRule ^$ www/ [L]
RewriteCond %{HTTP_HOST} ^subdomena\.domena\.cz$
RewriteRule (.*) www/$1 [L]

Kód jsem převzal ze stránky http://pla.nette.org/cs/faq#…, jen jsem změnil tvar domény (subdomena\.domena\.cz).

Všechny požadavky do složky web (varianta 3)

V tomto případě používám svůj .htaccess, který se mi stará o nasměrování subdomény do správné složky (web/<subdomena>_root) a upravenou Nette strukturu, podobné té u varianty 2. Celé to pak vypadá takto:

web/subdomena1_root   -> subdoména 1 s Nette aplikací
      index.php       -> obsahuje upravené cesty do Nette adresářů (app, vendor,...)
      .htaccess       -> .htaccess z Nette, RewriteBase nechávám ZAkomentovaný
web/subdomena1_data   -> složka, kde jsou všechny aplikační soubory pro subdoménu 1
      app/
      temp/
      log/
      vendor/
web/subdomena2_root   -> subdoména 2
web/www_root          -> obsah hlavního webu (www.domena.cz)
web/.htaccess         -> .htaccess pro dynamické subdomény

Neměl by být problém i v této variantě použít klasickou Nette strukturu, postup bude podobný jako u 2. varianty (viz výše).

Tak to je asi všechno :)