Pojďte otestovat Nette 2.4 RC

před 11 měsíci

David Grudl
founder | 6645
+
+46
-

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).

před 11 měsíci

Joe Kolář
Člen | 13
+
0
-

Čas ve svatém týdnu jsem věnoval nette2.4, zatím jsem narazil na tyto záležitosti:

  1. emulované properties mi fungují pouze s type hintem – je to záměr?
  2. neaktuální, dg
  3. U Utils/Html dostávám Expanded attribute "data" is deprecated., je nutno tedy přepsat na explicitní data- nebo existuje alternativa?
  4. 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čí chybou Missing parameter $entity required by Presenter::renderDefault(), po odstranění metody renderDefault opět funguje korektně. Je to záměr?

před 11 měsíci

enumag
Člen | 2126
+
+1
-
  1. neaktuální, dg
  2. Ž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).

před 11 měsíci

castamir
Člen | 631
+
0
-

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

před 11 měsíci

ptacek.pavel
Člen | 27
+
+3
-

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:

  1. do composer.json doplňte "minimum-stability": "RC",
  2. 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)

před 11 měsíci

David Grudl
founder | 6645
+
+1
-

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.

před 11 měsíci

Marek Šneberger
Člen | 131
+
+6
-

Pokusil jsem se updatovat DámeJídlo na 2.4. Narazil jsem na pár problémků:

  1. 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.

  1. 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.

  1. 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.

  1. Found section 'debugger' in configuration, but corresponding extension is missing

Stačilo sekci přepsat na tracy.

  1. Webloader zatím nepočítá s Nette 2.4, pošlu pull
  2. kdyby/replicator zatím nepočítá s Nette 2.4 neaktuální, dg
  3. 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
  4. ublaboo/datagrid už sice ve verzi 4 podporuje Nette 2.4, ale na packagist je stále ~2.3 neaktuální, dg

před 11 měsíci

Jan Tvrdík
Nette guru | 2489
+
0
-

@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>

před 11 měsíci

Milo
Moderator | 1027
+
0
-

S Latte (na tomto commitu) dostávám Incompatible context, |noCheck chybku nepotlačí:

<script>{include '@inline.js' |noCheck}</script>

před 11 měsíci

David Grudl
founder | 6645
+
+3
-

@Milo tohle bude vyžadovat, aby soubor @inline.js začínal {contentType javascript}

před 10 měsíci

David Grudl
founder | 6645
+
+17
-

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 &lt 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.

před 10 měsíci

DavidKrmela
Člen | 5
+
0
-

@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:'>'.

před 10 měsíci

kukulich
Člen | 40
+
0
-

@DavidGrudl Je nějaký důvod, proč Latte\Filters::filterContent() nepodporuje dynamické filtry, jako je podporuje Latte\Filters::__get()?

před 10 měsíci

David Grudl
founder | 6645
+
+3
-

Se mi to nechtělo programovat.

před 10 měsíci

medhi
Člen | 189
+
+20
-

Hrozně se mi líbí, že když po mě nové Nette chce něco opravit, napíše proč a případně jak to opravit. Detail, který potěší.

před 10 měsíci

romiix.org
Člen | 342
+
0
-

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?

před 10 měsíci

David Matějka
Moderator | 4738
+
+2
-

@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)

před 10 měsíci

romiix.org
Člen | 342
+
0
-

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

před 10 měsíci

GEpic
Člen | 357
+
0
-

Vím, že v novém Template je setParameters deprecated, každopádně potřebuji za běhu v Latte nastavit do template proměnnou, jak toho docílím?

před 10 měsíci

David Grudl
founder | 6645
+
0
-

Nestačí {var $promenna = 123}?

před 10 měsíci

Lukes
Člen | 38
+
+15
-

Chtěl bych poděkovat autorům za Ajax Tracy. Naprosto geniální nástroj!

před 10 měsíci

xificurk
Člen | 118
+
0
-

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*}

před 10 měsíci

David Grudl
founder | 6645
+
0
-

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.

před 10 měsíci

xificurk
Člen | 118
+
0
-

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á 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.

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.

před 10 měsíci

radas
Člen | 199
+
0
-

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

před 10 měsíci

Jan Mikeš
Člen | 732
+
0
-

@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>

před 10 měsíci

David Grudl
founder | 6645
+
0
-

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.

před 10 měsíci

Milo
Moderator | 1027
+
0
-

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.

před 10 měsíci

David Grudl
founder | 6645
+
0
-

@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.

před 10 měsíci

Milo
Moderator | 1027
+
0
-

@DavidGrudl Jo, souhlasím. Jen jsem zapomněl vyjádřit hlavní myšlenku :) a to, že pokud někdo bude chtít kombinaci HTTP/HTTPS zachovat, nebude to mít snadné (mimo přetížení canonicalize() a nějakého vlastního flagu pro každou routu mě nic nenapadá).

před 10 měsíci

David Grudl
founder | 6645
+
+1
-

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.

před 10 měsíci

Šaman
Člen | 2121
+
+2
-

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.

před 10 měsíci

David Grudl
founder | 6645
+
+4
-

@Š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.

před 10 měsíci

Jan Tvrdík
Nette guru | 2489
+
0
-

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.

před 10 měsíci

David Grudl
founder | 6645
+
+2
-

Pojďme prosím přesunout diskusi o HTTPS a SECURED jinam.

před 10 měsíci

finwe
Člen | 53
+
0
-

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.

před 10 měsíci

kukulich
Člen | 40
+
0
-

@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.

před 10 měsíci

David Grudl
founder | 6645
+
0
-

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.

před 10 měsíci

uestla
Člen | 694
+
+2
-

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?

před 10 měsíci

David Matějka
Moderator | 4738
+
0
-

@uestla tipuju, ze si jako workaround posilal primo do sablony $_form z presenteru/controlu? pripadne uvnitr snippetu mel neco jako {var $_form = $control['foo']}?

před 10 měsíci

Mysteria
Člen | 590
+
0
-

@David Matějka: Já ano. Jak to vyřešit teď? :)

před 10 měsíci

uestla
Člen | 694
+
0
-

@DavidMatějka Měl jsem to tak. Jestli bylo přiřazení do $_form (a asi bylo) bráno jako hack, tak asi nebude existovat alternativa v novém… Chápu, že vykreslovat samostatně input je takové vytržené z kontextu, na druhou stranu každý input si může na svůj form „sáhnout“.

před 10 měsíci

David Matějka
Moderator | 4738
+
+3
-

@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?

před 10 měsíci

uestla
Člen | 694
+
0
-

@DavidMatějka {form foo} IMHO znovu vykreslí začáteční tag <form>. Chápu formsStack jako efektivní udržování vykreslované struktury formulářů, a že sahat při vykreslení každého prvku na formulář je časově náročnější, ale ve snippet režimu to asi jinak nepůjde :/

před 10 měsíci

David Grudl
founder | 6645
+
0
-

@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]).

před 10 měsíci

David Matějka
Moderator | 4738
+
0
-

@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.

před 10 měsíci

David Grudl
founder | 6645
+
+2
-

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.

před 10 měsíci

David Matějka
Moderator | 4738
+
+4
-

Nemyslim, ze je to okrajovy usecase.

před 10 měsíci

finwe
Člen | 53
+
+1
-

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;

před 10 měsíci

David Grudl
founder | 6645
+
+2
-

Úplně správně by to mělo být try_files $uri $uri/ /index.php$is_args$args;

Stránky: 1 2 3 4 Next RSS tématu

Zápatí

Terms and conditions