Nette Documentation Preview

syntax
Hibaelhárítás
*************


A Nette nem működik, fehér oldal jelenik meg .[#toc-nette-is-not-working-white-page-is-displayed]
-------------------------------------------------------------------------------------------------
- Próbálja meg a `index.php` fájlban a `declare(strict_types=1);` után a `ini_set('display_errors', '1'); error_reporting(E_ALL);` címet beírni, hogy kikényszerítse a hibák megjelenítését.
- Ha továbbra is fehér képernyő jelenik meg, akkor valószínűleg hiba van a szerver beállításában, és az okot a szervernaplóban találja meg. A biztonság kedvéért ellenőrizze, hogy a PHP egyáltalán működik-e, ha megpróbál valamit kiírni a `echo 'test';` segítségével.
- Ha hibaüzenetet lát *Server Error: Sajnáljuk! ...*, folytassa a következő résszel:


Hiba 500 *Szerver hiba: Sajnáljuk! ...* .[#toc-error-500-server-error-we-re-sorry]
----------------------------------------------------------------------------------
Ezt a hibaoldalt a Nette jeleníti meg termelési üzemmódban. Ha a fejlesztői gépén látja, [váltson fejlesztői módba |application:bootstrap#Development vs Production Mode], és a Tracy részletes jelentéssel jelenik meg.

A hiba okát mindig megtalálhatja a `log/` könyvtárban. Ha azonban a hibaüzenetben a `Tracy is unable to log error` kifejezés szerepel, először határozza meg, hogy miért nem lehet a hibákat naplózni. Ezt megteheti például úgy, hogy ideiglenesen fejlesztői módba [kapcsol |application:bootstrap#Development vs Production Mode], és hagyja, hogy a Tracy az indítás után bármit naplózzon:

```php
// Bootstrap.php
$configurator->setDebugMode('23.75.345.200'); // az Ön IP-címe
$configurator->enableTracy($rootDir . '/log');
\Tracy\Debugger::log('hello');
```

A Tracy tájékoztatni fogja, hogy miért nem tud naplózni. Az ok lehet, hogy [nem elegendőek |#Setting Directory Permissions] az írási [jogosultságok |#Setting Directory Permissions] a `log/` könyvtárba.

Az 500-as hiba egyik leggyakoribb oka az elavult gyorsítótár. Míg a Nette okosan, automatikusan frissíti a gyorsítótárat fejlesztési módban, addig a termelési módban a teljesítmény maximalizálására összpontosít, és a gyorsítótár törlése minden kódmódosítás után az Ön feladata. Próbálja meg törölni a `temp/cache`.


404-es hiba, útválasztás nem működik .[#toc-error-404-routing-not-working]
--------------------------------------------------------------------------
Amikor minden oldal (a kezdőlap kivételével) 404-es hibát ad vissza, úgy tűnik, hogy a szerver konfigurációs problémája van a [szép URL-eknél |#How to Configure a Server for Nice URLs?].


A sablonok vagy a konfiguráció változásai nem tükröződnek .[#toc-changes-in-templates-or-configuration-are-not-reflected]
-------------------------------------------------------------------------------------------------------------------------
"Módosítottam a sablont vagy a konfigurációt, de a weboldal még mindig a régi verziót jeleníti meg." Ez a viselkedés a [termelési üzemmódban |application:bootstrap#Development vs Production Mode] fordul elő, amely a teljesítmény miatt nem ellenőrzi a fájlváltozásokat, és fenntartja a korábban létrehozott gyorsítótárat.

Annak érdekében, hogy elkerülje a gyorsítótár manuális törlését a termelő szerveren minden módosítás után, engedélyezze a `Bootstrap.php` fájlban a fejlesztési üzemmódot az IP-címe számára:

```php
$this->configurator->setDebugMode('your.ip.address');
```


Hogyan lehet letiltani a gyorsítótárat a fejlesztés során? .[#toc-how-to-disable-cache-during-development]
----------------------------------------------------------------------------------------------------------
A Nette okos, és nem kell kikapcsolni benne a gyorsítótárazást. A fejlesztés során automatikusan frissíti a gyorsítótárat, ha változás történik a sablonban vagy a DI konténer konfigurációjában. Ráadásul a fejlesztési mód automatikus felismeréssel aktiválódik, így általában nem kell semmit, [vagy csak az IP-címet |application:bootstrap#development-vs-production-mode] konfigurálni.

A router hibakeresése során javasoljuk a böngésző gyorsítótárának letiltását, ahol például az átirányítások tárolódhatnak: nyissa meg a Developer Tools-t (Ctrl+Shift+I vagy Cmd+Option+I), és a Hálózat panelen jelölje be a gyorsítótár letiltására szolgáló négyzetet.


Hiba `#[\ReturnTypeWillChange] attribute should be used` .[#toc-error-returntypewillchange-attribute-should-be-used]
--------------------------------------------------------------------------------------------------------------------
Ez a hiba akkor jelentkezik, ha a PHP-t a 8.1-es verzióra frissítette, de a Nette-et használja, amely nem kompatibilis vele. A megoldás tehát a Nette újabb verzióra való frissítése a `composer update` segítségével. A Nette a 3.0-s verzió óta támogatja a PHP 8.1-es verzióját. Ha régebbi verziót használ (ezt a `composer.json` oldalon találja meg), [frissítse a Nette-et |migrations:en], vagy maradjon a PHP 8.0-nál.


Címtárengedélyek beállítása .[#toc-setting-directory-permissions]
-----------------------------------------------------------------
Ha macOS-en vagy Linuxon (vagy bármely más Unix-alapú rendszeren) fejleszt, akkor be kell állítania a webszerver írási jogosultságait. Feltételezve, hogy az alkalmazásod az alapértelmezett `/var/www/html` könyvtárban található (Fedora, CentOS, RHEL).

```shell
cd /var/www/html/MY_PROJECT
chmod -R a+rw temp log
```

Egyes Linux rendszereken (Fedora, CentOS, ...) a SELinux alapértelmezés szerint engedélyezve lehet. Lehet, hogy frissítenie kell a SELinux házirendeket, vagy a `temp` és `log` könyvtárak elérési útvonalát a megfelelő SELinux biztonsági kontextussal kell beállítania. A `temp` és `log` könyvtárakat a `httpd_sys_rw_content_t` kontextusban kell beállítani; az alkalmazás többi részéhez -- főleg a `app` mappához -- a `httpd_sys_content_t` kontextus elegendő. Futtassa a szerveren root felhasználóként:

```shell
semanage fcontext -at httpd_sys_rw_content_t '/var/www/html/MY_PROJECT/log(/.*)?'
semanage fcontext -at httpd_sys_rw_content_t '/var/www/html/MY_PROJECT/temp(/.*)?'
restorecon -Rv /var/www/html/MY_PROJECT/
```

Ezután engedélyezni kell a SELinux booleant `httpd_can_network_connect_db`, hogy a Nette csatlakozhasson az adatbázishoz a hálózaton keresztül. Alapértelmezés szerint ki van kapcsolva. A `setsebool` parancs használható a feladat elvégzésére, és ha a `-P` opciót adjuk meg, akkor ez a beállítás az újraindítások során is megmarad.

```shell
setsebool -P httpd_can_network_connect_db on
```


Hogyan lehet megváltoztatni vagy eltávolítani a `www` címtárat az URL-ből? .[#toc-how-to-change-or-remove-www-directory-from-url]
---------------------------------------------------------------------------------------------------------------------------------
A Nette mintaprojektekben használt `www/` könyvtár a projekt úgynevezett nyilvános könyvtára vagy dokumentum-gyökere. Ez az egyetlen könyvtár, amelynek tartalma a böngésző számára elérhető. És ez tartalmazza a `index.php` fájlt, a belépési pontot, amely elindítja a Nette-ben írt webalkalmazást.

Ahhoz, hogy az alkalmazás a tárhelyen fusson, a tárhely konfigurációjában a document-root-ot erre a könyvtárra kell állítani. Vagy, ha a tárhelyen van egy előre elkészített mappa a nyilvános könyvtár számára más névvel (például `web`, `public_html` stb.), egyszerűen nevezze át `www/`.

A megoldás **nem** az, hogy a `www/` kivételével minden mappához való hozzáférést megakadályozzuk a `.htaccess` fájlban vagy az útválasztóban található szabályok segítségével. Ha a tárhelye nem teszi lehetővé a dokumentum gyökerének alkönyvtárba helyezését (azaz a nyilvános könyvtár feletti könyvtárak létrehozását), akkor más tárhelyszolgáltatást kell keresnie. Ellenkező esetben jelentős biztonsági kockázatoknak teszi ki magát. Ez olyan lenne, mintha olyan lakásban élne, ahol a bejárati ajtót nem lehet bezárni, és mindig nyitva van.


Hogyan konfiguráljunk egy kiszolgálót a szép URL-ekhez? .[#toc-how-to-configure-a-server-for-nice-urls]
-------------------------------------------------------------------------------------------------------
**Apache**: engedélyeznie és beállítania kell a mod_rewrite szabályokat a `.htaccess` fájlban:

```apacheconf
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !\.(pdf|js|ico|gif|jpg|png|css|rar|zip|tar\.gz)$ index.php [L]
```

Ha problémák merülnek fel, győződjön meg róla, hogy:
- a `.htaccess` fájl a document-root könyvtárban található (azaz a `index.php` fájl mellett).
- az [Apache feldolgozza a .htaccess fájlokat |#Test if .htaccess is working].
- a [mod_rewrite engedélyezve van |#Test if mod_rewrite is enabled]

Ha egy almappában állítod be az alkalmazást, akkor előfordulhat, hogy ki kell venned a `RewriteBase` beállításhoz tartozó sort, és a megfelelő mappára kell beállítanod.

**nginx**: a `try_files` direktívát kell használni a szerverkonfigurációban:

```nginx
location / {
	try_files $uri $uri/ /index.php$is_args$args;  # $is_args$args FONTOS!
}
```

A `location` blokkot pontosan egyszer kell definiálni a `server` blokk minden egyes fájlrendszeri elérési útvonalához. Ha már van `location /` blokk a konfigurációban, akkor a `try_files` direktívát adja hozzá a meglévő blokkhoz.


Tesztelje, hogy a `.htaccess` működik-e .[#toc-test-if-htaccess-is-working]
---------------------------------------------------------------------------
A legegyszerűbb módszer annak tesztelésére, hogy az Apache használja vagy figyelmen kívül hagyja-e a `.htaccess` fájlt, ha szándékosan megtörik. Tegye a `Test` sort a fájl elejére, és most, ha frissíti az oldalt a böngészőben, egy *Belső szerver hiba* üzenetet kell látnia.

Ha ezt a hibát látod, az tulajdonképpen jó! Ez azt jelenti, hogy az Apache elemzi a `.htaccess` fájlt, és találkozik az általunk oda beírt hibával. Távolítsa el a `Test` sort.

Ha nem lát *Belső szerverhibát*, akkor az Apache beállítása figyelmen kívül hagyja a `.htaccess` fájlt. Általában az Apache a hiányzó `AllowOverride All` konfigurációs utasítás miatt hagyja figyelmen kívül.

Ha saját maga hosztolja, akkor ezt elég könnyű kijavítani. Nyissa meg a `httpd.conf` vagy a `apache.conf` címet egy szövegszerkesztő programban, keresse meg a vonatkozó `<Directory>` szakaszt, és adjuk hozzá/változtassuk meg az irányelvet:

```apacheconf
<Directory "/var/www/htdocs"> # path to your document root
    AllowOverride All
    ...
```

Ha a webhelyét máshol tárolja, ellenőrizze a vezérlőpultját, hogy engedélyezheti-e ott a `.htaccess` címet. Ha nem, forduljon a tárhelyszolgáltatójához, hogy tegye ezt meg Ön helyett.


Tesztelje, hogy a `mod_rewrite` engedélyezve van-e .[#toc-test-if-mod-rewrite-is-enabled]
-----------------------------------------------------------------------------------------
Ha meggyőződött arról, hogy a [`.htaccess` működik |#Test if .htaccess is working], ellenőrizheti, hogy a mod_rewrite kiterjesztés engedélyezve van-e. Tegye a `RewriteEngine On` sort a `.htaccess` fájl elejére, és frissítse az oldalt a böngészőben.
Ha *Belső szerverhiba* jelenik meg, az azt jelenti, hogy a mod_rewrite nincs engedélyezve. Többféleképpen is engedélyezheted. Lásd a Stack Overflow-t, ahol különböző beállításoknál ez különböző módon történhet.


A hivatkozások a `https:` nélkül generálódnak. .[#toc-links-are-generated-without-https]
----------------------------------------------------------------------------------------
A Nette ugyanolyan protokollal generálja a linkeket, mint amilyet az aktuális oldal használ. Tehát a `https://foo` kezdetű linkeket generálja, és fordítva.
Ha egy HTTPS-csupaszító fordított proxy mögött áll (például Dockerben), akkor a konfigurációban be kell állítania [a proxyt |http:configuration#HTTP proxy], hogy a protokollfelismerés megfelelően működjön.

Ha Nginxet használ proxyként, akkor az átirányítást így kell beállítania:

```
location / {
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Forwarded-Proto $scheme;
	proxy_set_header X-Forwarded-Port  $server_port;
	proxy_pass http://IP-aplikace:80;  # IP or hostname of the server/container where the application is running
}
```

Ezután meg kell adnia az IP-proxyt és adott esetben a helyi hálózat IP-tartományát, ahol az infrastruktúrát futtatja:

```neon
http:
	proxy: IP-proxy/IP-range
```


A { } karakterek használata JavaScriptben .[#toc-use-of-characters-in-javascript]
---------------------------------------------------------------------------------
A `{` and `}` karakterek a Latte címkék írására szolgálnak. Minden (a szóköz és az idézőjel kivételével) a `{` character is considered a tag. If you need to print character `{` után (gyakran JavaScriptben), közvetlenül a `{` után szóközt (vagy más üres karaktert) tehetünk. Ezzel elkerüljük, hogy címkeként értelmezzük.

Ha olyan helyzetben kell ezeket a karaktereket kiírni, ahol címkeként értelmeznék, akkor speciális címkékkel kiírhatod ezeket a karaktereket - `{l}` a `{` and `{r}` a `}` számára.

```
{is tag}
{ is not tag }
{l}is not tag{r}
```


Megjegyzés: `Presenter::getContext() is deprecated` .[#toc-notice-presenter-getcontext-is-deprecated]
-----------------------------------------------------------------------------------------------------

A Nette messze az első PHP keretrendszer, amelyik áttért a függőségi injektálásra, és az előadótól kezdve rávezette a programozókat a következetes használatára. Ha egy prezenternek szüksége van egy függőségre, akkor [kérni fogja azt |dependency-injection:passing-dependencies].
Ezzel szemben az, ahogyan a teljes DI konténert átadjuk egy osztálynak, és az közvetlenül onnan húzza ki a függőségeket, antipatternnek számít (ezt hívják service locatornak).
Ezt a módot a Nette 0.x-ben használták a függőségi injektálás megjelenése előtt, és ennek maradványa a `Presenter::getContext()`, régen elavultnak jelölt metódus.

Ha egy nagyon régi Nette alkalmazást portolsz, akkor lehet, hogy még mindig ezt a módszert használja. Így a `nette/application` 3.1-es verziója óta a `Nette\Application\UI\Presenter::getContext() is deprecated, use dependency injection` figyelmeztetéssel, a 4.0-s verzió óta pedig azzal a hibával találkozik, hogy a metódus nem létezik.

A tiszta megoldás természetesen az, hogy áttervezzük az alkalmazást úgy, hogy a függőségeket függőségi injektálással adjuk át. Megoldásként hozzáadhatja saját `getContext()` metódusát az alap prezenterhez, és megkerülheti az üzenetet:

```php
abstract BasePresenter extends Nette\Application\UI\Presenter
{
	private Nette\DI\Container $context;

	public function injectContext(Nette\DI\Container $context)
	{
		$this->context = $context;
	}

	public function getContext(): Nette\DI\Container
	{
		return $this->context;
	}
}
```


{{leftbar: www:@menu-common}}

Hibaelhárítás

A Nette nem működik, fehér oldal jelenik meg

  • Próbálja meg a index.php fájlban a declare(strict_types=1); után a ini_set('display_errors', '1'); error_reporting(E_ALL); címet beírni, hogy kikényszerítse a hibák megjelenítését.
  • Ha továbbra is fehér képernyő jelenik meg, akkor valószínűleg hiba van a szerver beállításában, és az okot a szervernaplóban találja meg. A biztonság kedvéért ellenőrizze, hogy a PHP egyáltalán működik-e, ha megpróbál valamit kiírni a echo 'test'; segítségével.
  • Ha hibaüzenetet lát Server Error: Sajnáljuk! …, folytassa a következő résszel:

Hiba 500 Szerver hiba: Sajnáljuk! …

Ezt a hibaoldalt a Nette jeleníti meg termelési üzemmódban. Ha a fejlesztői gépén látja, váltson fejlesztői módba, és a Tracy részletes jelentéssel jelenik meg.

A hiba okát mindig megtalálhatja a log/ könyvtárban. Ha azonban a hibaüzenetben a Tracy is unable to log error kifejezés szerepel, először határozza meg, hogy miért nem lehet a hibákat naplózni. Ezt megteheti például úgy, hogy ideiglenesen fejlesztői módba kapcsol, és hagyja, hogy a Tracy az indítás után bármit naplózzon:

// Bootstrap.php
$configurator->setDebugMode('23.75.345.200'); // az Ön IP-címe
$configurator->enableTracy($rootDir . '/log');
\Tracy\Debugger::log('hello');

A Tracy tájékoztatni fogja, hogy miért nem tud naplózni. Az ok lehet, hogy nem elegendőek az írási jogosultságok a log/ könyvtárba.

Az 500-as hiba egyik leggyakoribb oka az elavult gyorsítótár. Míg a Nette okosan, automatikusan frissíti a gyorsítótárat fejlesztési módban, addig a termelési módban a teljesítmény maximalizálására összpontosít, és a gyorsítótár törlése minden kódmódosítás után az Ön feladata. Próbálja meg törölni a temp/cache.

404-es hiba, útválasztás nem működik

Amikor minden oldal (a kezdőlap kivételével) 404-es hibát ad vissza, úgy tűnik, hogy a szerver konfigurációs problémája van a szép URL-eknél.

A sablonok vagy a konfiguráció változásai nem tükröződnek

„Módosítottam a sablont vagy a konfigurációt, de a weboldal még mindig a régi verziót jeleníti meg.“ Ez a viselkedés a termelési üzemmódban fordul elő, amely a teljesítmény miatt nem ellenőrzi a fájlváltozásokat, és fenntartja a korábban létrehozott gyorsítótárat.

Annak érdekében, hogy elkerülje a gyorsítótár manuális törlését a termelő szerveren minden módosítás után, engedélyezze a Bootstrap.php fájlban a fejlesztési üzemmódot az IP-címe számára:

$this->configurator->setDebugMode('your.ip.address');

Hogyan lehet letiltani a gyorsítótárat a fejlesztés során?

A Nette okos, és nem kell kikapcsolni benne a gyorsítótárazást. A fejlesztés során automatikusan frissíti a gyorsítótárat, ha változás történik a sablonban vagy a DI konténer konfigurációjában. Ráadásul a fejlesztési mód automatikus felismeréssel aktiválódik, így általában nem kell semmit, vagy csak az IP-címet konfigurálni.

A router hibakeresése során javasoljuk a böngésző gyorsítótárának letiltását, ahol például az átirányítások tárolódhatnak: nyissa meg a Developer Tools-t (Ctrl+Shift+I vagy Cmd+Option+I), és a Hálózat panelen jelölje be a gyorsítótár letiltására szolgáló négyzetet.

Hiba #[\ReturnTypeWillChange] attribute should be used

Ez a hiba akkor jelentkezik, ha a PHP-t a 8.1-es verzióra frissítette, de a Nette-et használja, amely nem kompatibilis vele. A megoldás tehát a Nette újabb verzióra való frissítése a composer update segítségével. A Nette a 3.0-s verzió óta támogatja a PHP 8.1-es verzióját. Ha régebbi verziót használ (ezt a composer.json oldalon találja meg), frissítse a Nette-et, vagy maradjon a PHP 8.0-nál.

Címtárengedélyek beállítása

Ha macOS-en vagy Linuxon (vagy bármely más Unix-alapú rendszeren) fejleszt, akkor be kell állítania a webszerver írási jogosultságait. Feltételezve, hogy az alkalmazásod az alapértelmezett /var/www/html könyvtárban található (Fedora, CentOS, RHEL).

cd /var/www/html/MY_PROJECT
chmod -R a+rw temp log

Egyes Linux rendszereken (Fedora, CentOS, …) a SELinux alapértelmezés szerint engedélyezve lehet. Lehet, hogy frissítenie kell a SELinux házirendeket, vagy a temp és log könyvtárak elérési útvonalát a megfelelő SELinux biztonsági kontextussal kell beállítania. A temp és log könyvtárakat a httpd_sys_rw_content_t kontextusban kell beállítani; az alkalmazás többi részéhez – főleg a app mappához – a httpd_sys_content_t kontextus elegendő. Futtassa a szerveren root felhasználóként:

semanage fcontext -at httpd_sys_rw_content_t '/var/www/html/MY_PROJECT/log(/.*)?'
semanage fcontext -at httpd_sys_rw_content_t '/var/www/html/MY_PROJECT/temp(/.*)?'
restorecon -Rv /var/www/html/MY_PROJECT/

Ezután engedélyezni kell a SELinux booleant httpd_can_network_connect_db, hogy a Nette csatlakozhasson az adatbázishoz a hálózaton keresztül. Alapértelmezés szerint ki van kapcsolva. A setsebool parancs használható a feladat elvégzésére, és ha a -P opciót adjuk meg, akkor ez a beállítás az újraindítások során is megmarad.

setsebool -P httpd_can_network_connect_db on

Hogyan lehet megváltoztatni vagy eltávolítani a www címtárat az URL-ből?

A Nette mintaprojektekben használt www/ könyvtár a projekt úgynevezett nyilvános könyvtára vagy dokumentum-gyökere. Ez az egyetlen könyvtár, amelynek tartalma a böngésző számára elérhető. És ez tartalmazza a index.php fájlt, a belépési pontot, amely elindítja a Nette-ben írt webalkalmazást.

Ahhoz, hogy az alkalmazás a tárhelyen fusson, a tárhely konfigurációjában a document-root-ot erre a könyvtárra kell állítani. Vagy, ha a tárhelyen van egy előre elkészített mappa a nyilvános könyvtár számára más névvel (például web, public_html stb.), egyszerűen nevezze át www/.

A megoldás nem az, hogy a www/ kivételével minden mappához való hozzáférést megakadályozzuk a .htaccess fájlban vagy az útválasztóban található szabályok segítségével. Ha a tárhelye nem teszi lehetővé a dokumentum gyökerének alkönyvtárba helyezését (azaz a nyilvános könyvtár feletti könyvtárak létrehozását), akkor más tárhelyszolgáltatást kell keresnie. Ellenkező esetben jelentős biztonsági kockázatoknak teszi ki magát. Ez olyan lenne, mintha olyan lakásban élne, ahol a bejárati ajtót nem lehet bezárni, és mindig nyitva van.

Hogyan konfiguráljunk egy kiszolgálót a szép URL-ekhez?

Apache: engedélyeznie és beállítania kell a mod_rewrite szabályokat a .htaccess fájlban:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !\.(pdf|js|ico|gif|jpg|png|css|rar|zip|tar\.gz)$ index.php [L]

Ha problémák merülnek fel, győződjön meg róla, hogy:

Ha egy almappában állítod be az alkalmazást, akkor előfordulhat, hogy ki kell venned a RewriteBase beállításhoz tartozó sort, és a megfelelő mappára kell beállítanod.

nginx: a try_files direktívát kell használni a szerverkonfigurációban:

location / {
	try_files $uri $uri/ /index.php$is_args$args;  # $is_args$args FONTOS!
}

A location blokkot pontosan egyszer kell definiálni a server blokk minden egyes fájlrendszeri elérési útvonalához. Ha már van location / blokk a konfigurációban, akkor a try_files direktívát adja hozzá a meglévő blokkhoz.

Tesztelje, hogy a .htaccess működik-e

A legegyszerűbb módszer annak tesztelésére, hogy az Apache használja vagy figyelmen kívül hagyja-e a .htaccess fájlt, ha szándékosan megtörik. Tegye a Test sort a fájl elejére, és most, ha frissíti az oldalt a böngészőben, egy Belső szerver hiba üzenetet kell látnia.

Ha ezt a hibát látod, az tulajdonképpen jó! Ez azt jelenti, hogy az Apache elemzi a .htaccess fájlt, és találkozik az általunk oda beírt hibával. Távolítsa el a Test sort.

Ha nem lát Belső szerverhibát, akkor az Apache beállítása figyelmen kívül hagyja a .htaccess fájlt. Általában az Apache a hiányzó AllowOverride All konfigurációs utasítás miatt hagyja figyelmen kívül.

Ha saját maga hosztolja, akkor ezt elég könnyű kijavítani. Nyissa meg a httpd.conf vagy a apache.conf címet egy szövegszerkesztő programban, keresse meg a vonatkozó <Directory> szakaszt, és adjuk hozzá/változtassuk meg az irányelvet:

<Directory "/var/www/htdocs"> # path to your document root
    AllowOverride All
    ...

Ha a webhelyét máshol tárolja, ellenőrizze a vezérlőpultját, hogy engedélyezheti-e ott a .htaccess címet. Ha nem, forduljon a tárhelyszolgáltatójához, hogy tegye ezt meg Ön helyett.

Tesztelje, hogy a mod_rewrite engedélyezve van-e

Ha meggyőződött arról, hogy a .htaccess működik, ellenőrizheti, hogy a mod_rewrite kiterjesztés engedélyezve van-e. Tegye a RewriteEngine On sort a .htaccess fájl elejére, és frissítse az oldalt a böngészőben. Ha Belső szerverhiba jelenik meg, az azt jelenti, hogy a mod_rewrite nincs engedélyezve. Többféleképpen is engedélyezheted. Lásd a Stack Overflow-t, ahol különböző beállításoknál ez különböző módon történhet.

A Nette ugyanolyan protokollal generálja a linkeket, mint amilyet az aktuális oldal használ. Tehát a https://foo kezdetű linkeket generálja, és fordítva. Ha egy HTTPS-csupaszító fordított proxy mögött áll (például Dockerben), akkor a konfigurációban be kell állítania a proxyt, hogy a protokollfelismerés megfelelően működjön.

Ha Nginxet használ proxyként, akkor az átirányítást így kell beállítania:

location / {
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Forwarded-Proto $scheme;
	proxy_set_header X-Forwarded-Port  $server_port;
	proxy_pass http://IP-aplikace:80;  # IP or hostname of the server/container where the application is running
}

Ezután meg kell adnia az IP-proxyt és adott esetben a helyi hálózat IP-tartományát, ahol az infrastruktúrát futtatja:

http:
	proxy: IP-proxy/IP-range

A { } karakterek használata JavaScriptben

A { and } karakterek a Latte címkék írására szolgálnak. Minden (a szóköz és az idézőjel kivételével) a { character is considered a tag. If you need to print character { után (gyakran JavaScriptben), közvetlenül a { után szóközt (vagy más üres karaktert) tehetünk. Ezzel elkerüljük, hogy címkeként értelmezzük.

Ha olyan helyzetben kell ezeket a karaktereket kiírni, ahol címkeként értelmeznék, akkor speciális címkékkel kiírhatod ezeket a karaktereket – {l} a { and {r} a } számára.

{is tag}
{ is not tag }
{l}is not tag{r}

Megjegyzés: Presenter::getContext() is deprecated

A Nette messze az első PHP keretrendszer, amelyik áttért a függőségi injektálásra, és az előadótól kezdve rávezette a programozókat a következetes használatára. Ha egy prezenternek szüksége van egy függőségre, akkor kérni fogja azt. Ezzel szemben az, ahogyan a teljes DI konténert átadjuk egy osztálynak, és az közvetlenül onnan húzza ki a függőségeket, antipatternnek számít (ezt hívják service locatornak). Ezt a módot a Nette 0.x-ben használták a függőségi injektálás megjelenése előtt, és ennek maradványa a Presenter::getContext(), régen elavultnak jelölt metódus.

Ha egy nagyon régi Nette alkalmazást portolsz, akkor lehet, hogy még mindig ezt a módszert használja. Így a nette/application 3.1-es verziója óta a Nette\Application\UI\Presenter::getContext() is deprecated, use dependency injection figyelmeztetéssel, a 4.0-s verzió óta pedig azzal a hibával találkozik, hogy a metódus nem létezik.

A tiszta megoldás természetesen az, hogy áttervezzük az alkalmazást úgy, hogy a függőségeket függőségi injektálással adjuk át. Megoldásként hozzáadhatja saját getContext() metódusát az alap prezenterhez, és megkerülheti az üzenetet:

abstract BasePresenter extends Nette\Application\UI\Presenter
{
	private Nette\DI\Container $context;

	public function injectContext(Nette\DI\Container $context)
	{
		$this->context = $context;
	}

	public function getContext(): Nette\DI\Container
	{
		return $this->context;
	}
}