Pojďte otestovat Nette 2.4 RC
- David Grudl
- Nette Core | 8218
Včera vyšla první testovací verze nového Nette 2.4!
Přináší řadu novinek, nicméně k těm se dostanu až v příštím příspěvku. Verze 2.4 je trošku jiná, než předchozí:
- 2.4 bude poslední v řadě 2.x
- měla by být na 99 % kompatibilní s 2.3, nicméně generuje řadu deprecation notices, viz níže
- vyžaduje PHP 5.6
- nebudou žádné setinkové verze
Smyslem Nette 2.4 je na další roky zajistit podporu pro řadu 2.x a zároveň připravit uživatele na některé změny, které přijdou s Nette 3. Proto je minimální verzí PHP právě 5.6, které sice ještě dnes není úplně všude, ale pro příští roky nemá smysl podporovat nic staršího (support PHP 5.5 končí v červenci 2016). Pokud zatím na hostingu 5.6 nemáte, s přechodem na Nette 2.4 klidně počkejte.
Před testováním nebo nasazováním doporučuji nejprve vypnout hlášení chyb E_USER_DEPRECATED. Zapněte jej, až když vše bude fungovat.
$configurator->enableDebugger();
error_reporting(~E_USER_DEPRECATED);
Verzování
Nette je tvořeno sadou samostatných komponent, které mají vlastní verzování. Vycházejí tedy nové verze jednotlivých komponent, které si můžete libovolně namixovat, a s nástupem Composeru postupně ztratilo smysl vydávat verze Nette jako celku. Proto vyšla jen jedna verze 2.4 (obdobně i 2.3.10 a 2.2.13 jsou poslední balíčky „celého“ Nette).
Uživatelé Composeru jednotlivé balíčky zaktualizují příkazem
composer update
i pokud používají metabalíček
nette/nette
. A jestli s Composerem dosud nekamarádíte, můžete
stahovat Nette jako archívy, které
se budou lišit datem sestavení a verze v něm obsažených komponent
zjistíte v souboru version.txt
.
Deprecation notices
Nette 2.4 by mělo být téměř úplně kompatibilní s 2.3 (změny jsou vypsány níže), nicméně v některých situacích generuje upozornění, pokud používáte funkčnost, se kterou se do budoucna nepočítá, nebo dochází k chybě, která dříve procházela. Tyto upozornění lze samozřejmě potlačit zavináčem, pokud třeba nechcete kompatibilitu řešit hned, ale je dobré jim věnovat pozornost kvůli dopředné kompatibilitě s Nette 3.
Jde zejména o tyto situace:
Nette\Object
Třída Nette\Object má novějšího a dosti jednoduššího brášku
v podobně traity Nette\SmartObject
. Ten se liší v několika
věcech:
- podporuje emulované
properties jen pokud je na třídě zapsaná anotace
@property typ $nazev
. - nepodporuje extension methods
- nepodporuje getReflection
- nepodporuje získávání metod jako
$this->formSubmitted
(je třeba nahradit za klasický callback[$this, 'formSubmitted']
.
Samotná třída Nette\Object se nijak nezměnila a pokud od ní dědíte, nic se pro vás nemění. Co je ale podstatné, že třídy frameworku teď místo dědění od Nette\Object používají tuto novou traitu, a proto některé konstrukce mohou generovat upozornění (zdůrazňuji, že stále fungují, traita SmartObject plně emuluje chování Nette\Object, jen navíc vygeneruje upozornění).
Samozřejmě cílem je, aby uživatel pokud možno na žádné upozornění
nenarážel a všechno fungovalo jako dosud. Analyzoval jsem kód stovek
knihoven používajících Nette, pokusil se doplnit všechny smysluplné
anotace @property
a přidal podporu extension methods pro
formulář Form, protože tam se používají drtivě nejvíc.
Teď je důležité, abyste se zapojili do testování a odhalili,
kde se ještě upozornění objevují. V případě okrajových
situací bude vhodnější, pokud si opravu uděláte přímo v kódu (např.
nahradit property $obj->name
za metodu
$obj->getName()
apod), ale běžně se vyskytující situace
bych chtěl podchytit přímo v kódu Nette, aby se varování
nevyhazovaly.
Je proto opravdu důležité se co nejdřív pokusit otestovat vaše aplikace s Nette 2.4
Latte
V Latte se nově objevuje upozornění, pokud
- konstrukcí
{foreach $langs as $lang}
přepíšete parameter šablony$lang
- použijete již zastaralou vykříčníkovou konvenci
{!$name}
namísto preferovaného{$name|noescape}
- použijete v šabloně
<?php ?>
nebo{? ...}
namísto{php ...}
- použijete u bloku či include filtr, který je pro jiný content type (vysvětlení)
- použijete
|nosafeurl
místo novějšího|nocheck
- použijete makro
{includeblock}
, které nahrazuje podobné makro{import}
(importuje jen bloky a ne obsah okolo) - dojde k chybě „Incompatible context“ při používání bloků v jiném kontextu (například uvnitř HTML atributu bez uvozovek), než v jakém byl definován (například v běžném HTML textu).
- přistupujete k proměnné $template kvůli volání filtrů, což lze
nyní udělat přímo v šabloně pomocí výrazu
($var|trim)
nebo v PHP kódu generovaným makrem pomocícall_user_func($this->filters->trim, $val, ...)
. - přistupujete k proměnné $template kvůli proměnné, což nahraďte
za
$this->getParameter('xyz')
- přistupujete k interní podtržítkové proměnné jako
$_control
,$_form
atd.
Pokud na cokoliv narazíte a nebudete si vědět co s tím, napište.
Bootstrap
Takzvané sekce (production, development) v rámci jednoho konfiguračního souboru se už docela dávno ukázaly jako ne příliš pružné řešení a s příchodem Nette 2.0 byly nahrazeny za dvojici konfiguračních souborů config.neon a config.local.neon. V Nette 3.0 se už s jejich podporou nepočítá, proto verze 2.4 při jejich použití vyhodí upozornění.
Taktéž mám za to, že dědičnost služeb se v praxi neuplatnila a lepší je sáhnout po decoratoru, tudíž je deprecated, ale pokud se mýlím a v praxi ji používáte, dejte vědět.
Statement::setEntity() je deprecated.
Formuláře
Negativní validační pravidla jsou deprecated. Alternativou
~Form::FILLED
je Form::BLANK
, nebo
~Form::EQUAL
můžete nahradit za Form::NOT_EQUAL
.
Nette před vykreslením formuláře upozorní, pokud nad nějakým prvkem
použijete addRule()
(tedy je efektivně povinný), ale zapomněli
jste jej označit jako povinný pomocí setRequired()
.
Další
Nette\Utils\Html::add()
se mění na addHtml()
resp. addText()
.
V PhpGenerator metody
setDocuments(), getDocuments() a addDocument()
nahradily obdobné
setComment(), getComment() a addComment()
,
Změny ve 2.4
Ve verzi 2.4 je i několik změn v chování:
Application
U parametrů typu bool použitých v render/action metodách (tj. s výchozí hodnotou TRUE nebo FALSE) a persistentních parametrech se nyní rozlišuje mezi FALSE a NULL, tj. pokud parametr v URL není uveden, jeho hodnota je nyní NULL, dříve byla FALSE. Viz nette/application#107.
Route i SimpleRouter nyní generují v URL stejné HTTP/HTTPS schéma,
s jakým se přistupuje ke stránce. Routy, které vyžadují určitý
protokol, se dají napsat se schématem např.
Route('http://domain.cz/<presenter>')
, čímž zmizel smysl
flagu SECURED
a potažmo Route::$defaultFlags
, které
je deprecated. Podrobněji
tady.
Třída, kterou vrací Presenter::getReflection()
, již není
potomkem Nette\Reflection\ClassType
a taktéž
getReflection()->getMethod()
není potomkem
Nette\Reflection\Method
. Využívání featur původních předků
povede k upozornění. Výjimkou jsou metody hasAnnotation
a
getAnnotation
, které by měly nadále fungovat. Nicméně
getAnnotation()
neparsuje text uvedený za názvem anotace, jako
např. abc
v @param abc
, parsuje totiž jen text
uvedený v závorkách @param(abc)
.
Formuláře
Interní parametr do
se nyní u formulářů posílaných přes
POST jmenuje _do
, aby nedocházelo ke kolizi, a zároveň by
nemělo docházet k mixováním formulářových prvků s persistentními
parametry.
Třída BaseControl už přímo definuje getControlPart() a getLabelPart() a
standardně vracejí totéž, co getControl() a getLabel(). Makra
<tag n:name>
už rovnou používají tyto -part metody. Pokud
tyto metody definujete, bude potřeba případný parametr označit jako
nepovinný (= NULL)`
DefaultFormRenderer nyní správně vkládá do skupiny i vnořené komponenty (dříve se vnořené komponenty vykreslily až na konci formuláře), viz nette/forms#96.
Už se nepoužívá interní proměnná $_form
, kterou někdy
bylo potřeba ručně předávat do inkludovaných šablon, což už není
potřeba, nebo kvůli snippetům uvnitř formulářů, což nyní povede
k chybě (např.
end() expects parameter 1 to be array, null given
). Takže pokud si
kvůli snippetům předáváte do šablony
$template->_form = $form
, můžete to nahradit za
$template->getLatte()->addProvider('formsStack', [$form])
,
nicméně jde stále jen o obezličku, korektní je použít
{snippetArea xyz}
a ten invalidovat společně se snippetem.
Validátory Form::EMAIL
, URL
a INTEGER
automaticky mění HTML atribut type na email
, url
resp. number
.
Pokud používáte vlastní TemplateFactory, aplikujte do ní změny vytvořené v originální továrně.
setRequired(FALSE)
nyní udělá prvek volitelný, tj. pokud
není vyplněn, neaplikují se validační pravidla. Lze tím nahradit větve
addCondition($form::FILLED)
.
Nezapomeňte zaktualizovat netteForms.js
Latte
Filtry, které mají být aplikovány na blok textu ({block}
nebo {_}...{/_}
) či {include}
, musejí jako první
parametr přijímat objekt Latte\Runtime\FilterInfo, viz třeba https://github.com/…/Filters.php#…
{contentType}
je povolené pouze v hlavičce šablony a
v elementu <script>
kvůli nette/latte#71.
Jinak Latte doznalo poměrně zásadních změn pod kapotou, s maximálním úsilím o zpětnou kompatibilitu, ale pokud jste spoléhali na nějaké podtržítkové nebo jiné interní proměnné, nemusí fungovat.
Otestujte své projekty!
Zapojte se prosím do testování Nette 2.4, ať podchytíme všechna varování, kterých se lze zbavit a přechod na novou verzi je co nejjednodušší. Ostrá verze by pak mohla vyjít za měsíc.
Kromě fóra můžete použít i diskusní kanál Gitter, naopak issue tracker na Githubu pro tyto případy prosím nepoužívejte.
Aby vám Composer nainstalovat vývojové verze balíčků, doplňte do
composer.json "minimum-stability": "dev"
(viz
také).
(Post budu průběžně doplňovat).
- Joe Kolář
- Člen | 13
Čas ve svatém týdnu jsem věnoval nette2.4, zatím jsem narazil na tyto záležitosti:
- emulované properties mi fungují pouze s type hintem – je to záměr?
- neaktuální, dg
- U Utils/Html dostávám
Expanded attribute "data" is deprecated.
, je nutno tedy přepsat na explicitnídata-
nebo existuje alternativa? - Mám v presenteru persistentní parametr a aby se mi korektně generovaly
URL, měl jsem v cílovém presenteru (s persistentním parametrem) něco jako
public function renderDefault(Entity $entity) {}
a při generování URL jsem poté nemusel předávat explicitně entitu. To mi ovšem po upgradu na 2.4 končí chybouMissing parameter $entity required by Presenter::renderDefault()
, po odstranění metodyrenderDefault
opět funguje korektně. Je to záměr?
- enumag
- Člen | 2118
- neaktuální, dg
- Že parsování anotací nyní funguje se závorkami jsem dnes také zjistil
když jsem se snažil vyřešit kompatibilitu jedné knihovny. Nevadilo by mi to
kdyby alespoň existovala možnost čím to nahradit. Tu jsem však nenašel
takže budu si muset napsat vlastní parsovací funkci, což trochu bolí,
protože asi nebudu sám. Vzhledem k tomu, že nette/reflection je deprecated
bych rád znovu navrhl přesunutí Nette\DI\PhpReflection do nette/utils a
odstranění
@internal
. Plus bych právě zde chtěl nějakou možnost na parsování anotací jako@param
(PhpReflection::parseAnnotation neumí vrátit pole je-li anotace vícekrát takže jde použít na@var
a@return
, ale ne na@param
).
- castamir
- Člen | 629
Upozorňuju na BC break u DefaultFormRenderer
– ve verzi
2.4 se nyní správně vkládají do skupiny i vnořene komponenty (dříve
tomu tak nebylo a vnořené komponenty pak byly vykresleny až na konec
formuláře a poslední skupinu). https://github.com/…f843c08b16c7
- ptacek.pavel
- Člen | 27
Instalace composerem
Trošku jsem bojoval s composerem abych to rozchodil – možná se bude hodit i vám.
Pokud máte projekt, který jste vyrobili pomocí
composer create-project nette/sandbox <tvujProjekt>
, a
composer update
vám nenainstaluje žádné 2.4.0 komponenty, pak
postupujte takto:
- do
composer.json
doplňte"minimum-stability": "RC",
- u všech nette komponent, změňte znaménko z
~
na^
Můj composer.json před úpravama:
"require": {
"nette/application": "~ 2.3.6",
"nette/bootstrap": "~ 2.3.0",
...
composer.json po úpravě:
"minimum-stability": "RC",
"require": {
"nette/application": "^ 2.3.6",
"nette/bootstrap": "^ 2.3.0",
...
… pak už stačí akorát composer update
a do projektu vám
nalítnou 2.4 komponenty! Pokud je chcete odebrat, stačí vyzmizíkovat
„minimum-stability“ – a projekt se vám automaticky naupgraduje, až
vyjde nette 2.4 stable.
Dev stability
edit: David doporučuje testovat v DEV stabilitě, protože
některé věci tam už mají fixy. Dev můžete zapnout buď pro všechny
komponenty přes "minimum-stability": "dev",
– ale pozor, takhle
vám comoposer naupdatuje všechny komponenty na dev!
Alternativně (pokud nechcete mít všechno v dev stabilitě) si můžeme
nastavit dev pouze pro nette komponenty.
To se udělá tak, že vyhodíte verzi ^ 2.x.0
a dáte místo ní
dev-master
. Tady máte zkratku pro copy-paste:
"nette/application": "dev-master",
"nette/component-model": "dev-master",
"nette/bootstrap": "dev-master",
"nette/caching": "dev-master",
"nette/database": "dev-master",
"nette/di": "dev-master",
"nette/finder": "dev-master",
"nette/forms": "dev-master",
"nette/http": "dev-master",
"nette/mail": "dev-master",
"nette/robot-loader": "dev-master",
"nette/php-generator": "dev-master",
"nette/safe-stream": "dev-master",
"nette/security": "dev-master",
"nette/utils": "dev-master",
"latte/latte": "dev-master",
"tracy/tracy": "dev-master",
edit N: typos
Editoval ptacek.pavel (4. 5. 2016 20:14)
- David Grudl
- Nette Core | 8218
Ještě doplním, že pokud máte v composeru nějakou komponentu, která
vyžaduje přímo Nette 2.3 (nikoliv >=2.3
), takže můžete to
pořešit takto:
"nette/application": "dev-master as 2.3-dev",
"nette/http": "dev-master as 2.3-dev",
"nette/forms": "dev-master as 2.3-dev",
"nette/utils": "dev-master as 2.3-dev",
...
Prostě bude používat 2.4 dev, ale bude se to tvářit jako 2.3. Dalo by
se tam použít i "2.4.x-dev as 2.3-dev"
, ale bacha, balíček
nette/caching už je ve verzi 2.5 a jiné (component-model, deprecated,
safe-stream) ve verzi 2.3.
Nezapomeňte takto vyjmenovat všechny balíčky, včetně
component-model
apod, které přímo nemusíte
používat.
- Marek Šneberger
- Člen | 130
Pokusil jsem se updatovat DámeJídlo na 2.4. Narazil jsem na pár problémků:
Sections in config file are deprecated:
Měli jsme v bootstrap.php
$configurator->addConfig(__DIR__ . '/config/config.neon', $configurator::AUTO);
Stačilo odebrat druhý parametr metody addConfig()
a trochu si
pohrát s configem, aby s tím počítal.
Configuration section 'nette.application' is deprecated, use section 'application' (without 'nette')
Ta hláška je myslím všeříkající :-) Stačilo odstranit sekci
nette:
a to co bylo v ní přesunout na stejnou úroveň, jako
bylo nette.
Section inheritance damejidlo.emailRedis < redis.client is deprecated:
Upřímně vůbec nevím, proč jsme tohle v configu měli :-) Každopádně
stačilo smáznout to dědění a nastavit správnou class
.
Found section 'debugger' in configuration, but corresponding extension is missing
Stačilo sekci přepsat na tracy
.
- Webloader zatím nepočítá s Nette 2.4, pošlu pull
- kdyby/replicator zatím nepočítá s Nette 2.4 neaktuální, dg
- Poslal jsem mini pull requesty do pár knihoven, které používáme aby počítali s Nette 2.4. damejidlo/newrelic, damejidlo/datetime-factory, achse/php-math-interval, achse/template-helpers
- ublaboo/datagrid už sice ve verzi 4 podporuje Nette 2.4,
ale na packagist je stále
~2.3
neaktuální, dg
- Jan Tvrdík
- Nette guru | 2595
@DavidGrudl Při práci na úžasné nové verzi Nextras Mail Panelu, jsem narazil na incompatible context varování, přestože si myslím, že šablonu mám dobře.
<iframe data-content="{include MailPanel.body.latte, message => $message|escape}"></iframe>
- Milo
- Nette Core | 1283
S Latte (na tomto
commitu) dostávám Incompatible context
, |noCheck
chybku nepotlačí:
<script>{include '@inline.js' |noCheck}</script>
- David Grudl
- Nette Core | 8218
@Milo tohle bude vyžadovat, aby soubor @inline.js
začínal {contentType javascript}
- David Grudl
- Nette Core | 8218
Tak Latte už obsahuje úplně všechno, včetně kontroly content type pro
modifikátory použité u {block}
nebo {include}
(a
třeba i párový {_}...{/_}
). A s chybou, že používáte
filtr s nekompatibilním content type, se dost možná setkáte, tak si to
zaslouží lépe vysvětlit.
Všechny filtry počítají s tím, že jako vstup dostanou čistý text
(plaintext), třeba nějakou proměnnou z databáze. Na ni se pak aplikuje
například |upper
nebo |truncate
a výsledkem je zase
čistý text, který se před vypsáním escapuje pro příslušný kontext,
například HTML.
Trošku jiná situace nastává, pokud filtr použiju nad
{block}
nebo {include}
, protože v tu chvíli není
vstupem plaintext, ale HTML s tagy a entitami. Filtry jako je
|upper
nebo |truncate
s HTML neumí pracovat, kromě
samotného textu zvětší na velká písmena i obsah HTML značek a entity.
Pokud takto filtr použijete, Latte na to nově upozorní.
Taková věc se nicméně v praxi stává, příkladem může být kopírování obsahu H1 do TITLE:
<title>{include title|striptags|truncate:50}</title>
<h1 n:block=title>Hello</h1>
V tomto případě Latte upozorní na to, že truncate je použito špatně.
Kde je problém? Obsahem bloku title je HTML text. Mohou v něm být HTML
značky a entity. Striptags sice HTML značky vymaže, entity však ponechá,
takže výstupem striptags není plaintext, ale opět HTML kód. A může se
stát, že truncate nějakou entitu rozřízne vejpůl, takže v title se
může objevit třeba <
bez závěrečného středníku.
A právě na to Latte upozorní.
Rešení je jednoduché, stačí místo striptags použít filtr
|striphtml
, který krom odstranění tagů převede i HTML entity
na text, takže výstupem je plaintext, na který je pak možno truncate
v pohodě aplikovat. A následně se automaticky před vypsáním
escapuje.
Pokud by za striptags nenásledovalo truncate, tak Latte žádnou chybu hlásit nebude, prostě ví, že výstupem striptags je HTML a ani je nebude před vypsáním escapovat.
Aby váš vlastní filtr bylo možné používat na bloky, je potřeba, aby jako první parametr přijímal objekt Latte\Runtime\FilterInfo.
- DavidKrmela
- Člen | 5
@DavidGrudl Pak si ještě říkám, že by se někdy mohl hodit filtr
|trim
na ořezání whitespace u html kódu pro kodéry
perfekcionisty. U toho také nevidím problém, tedy za předpokladu, že
kodér neudělá něco jako |trim:'>'
.
- romiix.org
- Člen | 343
Má nejaký hlbší zmysel zmiznutie makra _
(translate)?
Pôvodný kód:
{_pendingOrders.newOrders, $count}
Nový kód:
{var $s = 'pendingOrders.newOrders'}{$s, $count|translate}
Má nejaký hlbší zmysel zmiznutie _
?
Dá sa to vyriešiť nejak elegantnejšie?
- David Matějka
- Moderator | 6445
@romiix.org makro translate nezmizelo. co to hlasi za chybu? jestli
Invoking filters via $template->translate($vars) is deprecated, use ($vars|translate)
tak je to tim, ze kdyby/translation neni kompatibilni (nejaky PR uz tam je
otevreny)
- romiix.org
- Člen | 343
David Matějka napsal(a):
@romiix.org makro translate nezmizelo. co to hlasi za chybu? jestli
Invoking filters via $template->translate($vars) is deprecated, use ($vars|translate)
tak je to tim, ze kdyby/translation neni kompatibilni (nejaky PR uz tam je otevreny)
Vďaka, bude to asi tým. Skúsim s tým @FilipProcházka pomôcť ak budem vedieť :P
- xificurk
- Člen | 121
Context-aware filtry jsou naprosto úžasné vylepšení! Mám ale trochu guláš v tom, kdy se context (ne)uplatňuje a proč tomu tak vlastně je :-)
Konkrétně jsem začal tápat při úpravě svého Texy! filtru. Ať do Texy
pošlu cokoliv, výstupem je vždy escapované (X)HTML – filtr tedy vrací
instanci Latte\Runtime\Html
a v Latte 2.4 nově i mění
contentType v předaném FilterInfo
na (X)HTML. A teď
přichází trochu wtf:
{$foo|texy|truncate:42} {*OK*}
{block|texy|truncate:42}bar{/block} {*warning*}
- David Grudl
- Nette Core | 8218
Při klasickém volání filtru nad proměnnou se s kontextem nepracuje,
vlastně to funguje úplně stejně, jako dosud. Filtr, který je kontextový,
dostane objekt FilterInfo
s hodnotou
$contentType = NULL
.
Důvod je ten, že o content type vstupní proměnné nic nevíme (pokud to
samozřejmě není proměnná zabalená do Latte\Runtime\Html
) a
nic nevíme ani o filtrech (nechtěl jsem, aby bylo nutné úplně každý
filtr předělávat na kontextový), tudíž Latte žádná další pravidla
neuplatňuje.
On byl hlavně problém s filtry nad bloky, kde si málokdo uvědomil, že třeba vytváří bezpečnostní díru, u těch proměnných i díky automatickému escapování je situace docela jiná, takže tady se dává přednosti rychlosti. Ale nevylučuju, že časem přijdu (nebo někdo jiný) na způsob, jak si poradit i s tímto.
- xificurk
- Člen | 121
David Grudl napsal(a):
Důvod je ten, že o content type vstupní proměnné nic nevíme (pokud to samozřejmě není proměnná zabalená doLatte\Runtime\Html
) a nic nevíme ani o filtrech (nechtěl jsem, aby bylo nutné úplně každý filtr předělávat na kontextový), tudíž Latte žádná další pravidla neuplatňuje.
Jasně, na vstupu není context znám… Ale třeba právě v případě
Texy (a i dalších filtrů – jsou to ty, co mění nastavení
$filterInfo->contentType
) je znám typ výstupu.
Přijde mi, že by bylo dobré, kdyby se chování sjednotilo a jediný rozdíl mezi blokem a vypsáním proměnné bylo právě to, že proměnná má nazačátku nespecifikovaný context. Ale přiznávám, že jsem nedomýšlel důsledky, a je dost možné, že se to nedá rozumně implementovat.
- radas
- Člen | 224
Jak napsal @DavidGrudl:
Route i SimpleRouter nyní generují v URL stejné HTTP/HTTPS schéma,
s jakým se přistupuje ke stránce. Tím v podstatě zmizel smysl flagu
SECURED a potažmo Route::$defaultFlags, kteréžto jsou deprecated.
Poradil by někdo, jak teď nově vynutit, aby web běžel jen na
HTTPS?
Dříve jsem toho dosáhl právě nastavením
Route::$defaultFlags = Route::SECURED;
Díky
- Jan Mikeš
- Člen | 771
@radas zkus neco podobneho v htaccess (psano z hlavy ale ± nejak tak to bude)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>
Tuto direktivu lze pouzit i v nastaveni virtual hosts
<VirtualHost *:80>
ServerName mysite.com
ServerAlias www.mysite.com
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>
- David Grudl
- Nette Core | 8218
xificurk napsal(a):
Přijde mi, že by bylo dobré, kdyby se chování sjednotilo a jediný rozdíl mezi blokem a vypsáním proměnné bylo právě to, že proměnná má nazačátku nespecifikovaný context.
Jasně, je to téma do příští verze :-) Prvním krokem bude, aby se filtry, které mění content-type, třeba tím, že vracejí objekt Html, přepsaly na content-type aware. Přidal jsem do Latte takovou noticku.
radas napsal(a):
Poradil by někdo, jak teď nově vynutit, aby web běžel jen na HTTPS? Dříve jsem toho dosáhl právě nastavením
Route::$defaultFlags = Route::SECURED;
To byl právě spíš omyl, Route::SECURED
nezajistil, že web
běžel na HTTPS, ale že odkazy, které router generoval, vedly na HTTPS. Což
v důsledku díky kanonizaci mohlo vést k tomu, že se obsah generovaných
stránek přesměrovával (s velkou režií) na HTTPS. Aby server běžel na
HTTPS, je nutné veškerý trafic přesměrovat už na úrovni serveru, takže
třeba nastavením v .htaccess.
- Milo
- Nette Core | 1283
David Grudl napsal(a):
To byl právě spíš omyl,Route::SECURED
nezajistil, že web běžel na HTTPS, ale že odkazy, které router generoval, vedly na HTTPS. Což v důsledku díky kanonizaci mohlo vést k tomu, že se obsah generovaných stránek přesměrovával (s velkou režií) na HTTPS. Aby server běžel na HTTPS, je nutné veškerý trafic přesměrovat už na úrovni serveru, takže třeba nastavením v .htaccess.
Může to být zásek pro aplikace, které běžely jak HTTP tak HTTPS a
SECURED používali pouze pro login a nebo administraci. Takhle jsem význam
Route::SECURED
kdysi pochopil. Na pár intrawebech to tak mám, ale
osobně nemám problém přepnout kompletně na HTTPS.
- David Grudl
- Nette Core | 8218
@milo přesně takhle to v minulosti bývalo, dnes už se to dělá jinak, přepínají se celé weby a proto to IMHO lze označit jako deprecated.
- David Grudl
- Nette Core | 8218
Tedy flag SECURED ponechat a mít deprecated pouze $defaultFlags? To by šlo, na druhou stranu to dává jen falešný pocit bezpečí. Kanonizace neprobíhá ani při POST požadavcích, dal bych to pryč.
Tak jinak: jak upozornil @JanTvrdík, není možné definovat v routě s celou doménou, zda jde o HTTP nebo HTTPS. Tudíž pro tento účel musí flag zůstat. Ale vlastně by šlo o flag třídy Route, nikoliv IRouter.
- Šaman
- Člen | 2658
No, bylo tak tomu doposud, tak myslím, že není dobré měnit to v Nette 2.4, která by měla být stále kompatibilní s dvojkovou řadou. Mám pocit, že na 2.4 se ještě bude upgradovat, zatímco Nette 3 bude většinou jen pro nové projekty. Takže pro takovéhle zásadní věci tam už prostor je.
- David Grudl
- Nette Core | 8218
@Šaman flag SECURED stále funguje, jen vyhazuje noticku. To je vlastně smyslem celé 2.4, fungovat, ale vyhazovat noticky u věcí, co příště fungovat nebudou.
- Jan Tvrdík
- Nette guru | 2595
přepínají se celé weby
Když to jde, bohužel např. kvůli dodavatelům reklamy to občas zatím ještě nejde.
Tedy flag SECURED ponechat a mít deprecated pouze $defaultFlags?
Když nad tím tak přemýšlím, tak pokud chceme výchozí chování změnit na COPY, tak bude potřeba navíc ještě přidat flag UNSECURED, jinak nebude fungovat generování odkazů např. z HTTPS administrace na HTTP blog.
- kukulich
- Člen | 58
@DavidGrudl Nemělo by tohle fungovat https://github.com/…f4d6533a5200 ?
S {block|strip}
to fungovalo, ale makro {spaceless}
se teď vykonává během kompilace šablony, takže to nefunguje. Nešlo by to
makro předělat, aby se stripnutí vykonávalo v runtimu? Díky.
- David Grudl
- Nette Core | 8218
finwe napsal(a):
Ještě jsem asi objevil jeden BC break, který jsem nikde neviděl popsaný: services teď nejde pojmenovávat jménem obsahujícím zpětné lomítko
\
– používám někde FQN.
To je pravda, nicméně dám tam noticku, protože na službu, jejíž název
obsahuje lomítko, se pak nejde odkazovat jménem, lomítko v
@neco\neco
znamená odkaz přes třídu.
kukulich napsal(a):
S{block|strip}
to fungovalo, ale makro{spaceless}
se teď vykonává během kompilace šablony, takže to nefunguje. Nešlo by to makro předělat, aby se stripnutí vykonávalo v runtimu? Díky.
spaceless se na rozdíl od strip řeší během kompilace, takže je výkonově zadarmo, ale hlavně strip řeší, aby se neodstraňovaly mezery uvnitř elementů PRE, TEXTAREA a SCRIPT, na což používá regulár, který u větších kódů může zařvat na vyčerpání backtrack limit. Buď je řešením to přepsat jinak, což se mi nechce, nebo zrušit tuhle vlastnost a obsah zmíněných elementů stripovat taky, což by mohl někdo reportovat jako bug, tak jsem ho deprecatnul.
- uestla
- Backer | 799
Předně moc díky za velké množství skvělých změn.
Dotaz ohledně nového Latte/Application a formsStack
.
Když mám část formuláře uvnitř snippetu a v něm pak prvek
vykreslený pomocí n:name
, při pokusu o překreslení snippetu
je $this->global->formsStack
prázdné a končí
warningem
end() expects parameter 1 to be array, null given
Existuje pro toto nějaký trik?
- David Matějka
- Moderator | 6445
@uestla tipuju, ze si jako workaround posilal primo do sablony
$_form
z presenteru/controlu? pripadne uvnitr snippetu mel neco
jako {var $_form = $control['foo']}
?
- David Matějka
- Moderator | 6445
@Mysteria @uestla zadny rozumny reseni bez sahani na internal
promenne me nenapada (vlastne $_form byla taky interni promenna)… mozna bude
fungovat zopakovani {form foo}
uvnitr snippetu, ale nevim…
ale asi by to slo udelat, aby se to nemuselo resit vubec (resp ve vetsine pripadu). Ze by ty formularova makra pro inputy zjistila, jestli jsou uvnitr snippetu a kdyz jo, tak si to samo poresilo ziskani formu. cc @DavidGrudl co si o tom myslis? mam kdyztak pripravit PR?
- David Grudl
- Nette Core | 8218
@DavidMatějka myslíš, že když by prvek zjistil, že je uvnitř
snippetu, tak by dohledal, zda je nad ním {form řetězec}
případě {formContainer řetězec}
a pak by místo formsStack
používat přímo uiControl->getComponent(...)
?
Je to možnost, na druhou stranu si říkám, že tohle je věc, na kterou
už existuje obecnější řešení {snippetArea}
, ne?
Každopádně workaround je nahradit $template->_form = $form
za
$template->getLatte()->addProvider('formsStack', [$form])
.
- David Matějka
- Moderator | 6445
@DavidGrudl jj, nejak tak.
hm, pravda, snippetArea to vyresi – ale zbytecne se bude provadet kod, ktery neni potreba :) bylo by hezky, kdyby to fungovalo primo.
- David Grudl
- Nette Core | 8218
Zkomplikovat kód FormMacros kvuli okrajovému usecase a to něčím, co stejně není úplně stoprocentní, nebo nechat server pracovat o milisekundu déle? Nechal bych makat servery.
- finwe
- Člen | 58
Jo a taky se mi při upgrade na 2.4 přestává se stejným nastavením zobrazovat Debugbar.
Podrobněji můžu. Přišel jsem na to, že se to děje na podstránkách. Kód tracy je v HTML vypasný, ale jakmile nejsem v rootu, tak requesty na tracy vrací HTML stránky webu, na které jsem, místo toho, aby vracely dané HTML/CSS/JS.
Jedu na nginxu a v konfigu jsem měl
try_files $uri $uri/ /index.php;
S tím jsem nikdy neměl problém. Teď, aby mi (asi) laděnka brala ten
$_GET
parametr z Bar.php:150, musím do konfigu přidat
$args
.
try_files $uri $uri/ /index.php?$args;
- David Grudl
- Nette Core | 8218
Úplně správně by to mělo být
try_files $uri $uri/ /index.php$is_args$args;