[2009-04-01] Parametry Debug::enable() a vylepšení profileru

Děkujeme!

Omlouvám se ale nechtěně jsem měl nahozenu revizi 251 kde to ještě není… http://code.google.com/…/source/diff?…
Něják nestíhám tempo vydávání revizí v posledních dvou dnech… :-(

Editoval vrtak-cz (1. 4. 2009 16:14)

Ale jsou tam … V Environment jsou to jen názvy módů a DETECT tam vůbec není.

Editoval romansklenar (1. 4. 2009 16:00)

Jen se zeptám, k čemu je používáná funkce ini_set v případě, kdy mám v bootstrap.php:

Debug::enable(Debug::DETECT,‚%appDir%/log/php_error.log‘,$emailHeaders);

a v config.ini:
mode.production = true;

vyhodí mi to chybu, jelikož máme zakázaný ini_set(). Když je ale v config.ini:
mode.production = false;
jede to v pohodě.

Můžete mi prosím napsat, k čemu se tam to ini_set používá?
Díky

Jo, jen nerumím jak funguje tohle:

bootstrap.php
Environment::loadConfig();
Debug::enable(Debug::DETECT);

config.ini
[production < common]
mode.production = true
mode.debug = no

Myslel jsem si, že pokud v config.ini definuji, že v production mode je debugování vypnuté. Ale asi to takto není, že? Musím mít v bootstrapu nějakou vyjímku, kde budu spouštět Debug::enable() jen pokud budu mít nastaveno mode.debug=yes?

Koukal jsem do dokumentace i do fóra, ale úplně moudrý z toho nejsem:

3 věci:

Envirovment…nastavuje prostředí a to buď manuálně, nebo pomocí autodetekce
Config.ini.....nastavíme pro dané prostředí režim pomocí mode.debug…?
Debug.enable().je na co? Čekal bych, že když mám nastavený Debug.enable(Debug::DETECT), tak když dám, že v případě kdy se Envirovment nastaví autodetekcí na Production vezme se config.ini:
V tom mohu definovat mode.production: true/false (to je k čemu?). Pokud nastavím mode.debug=no, stejně mi v produkčním režimu spadne aplikace na ini_set() – proč ale, když jsem mu řekl, že v produkčním módu nemá debugovat?

Melu asi páté přes deváté, ale fakt mám s tou terminologií a návaznostma velký problém…

díky

EDIT: Ještě praktický dotaz, jde teda nějak rozumně (čti: bez psaní vlastní log class) bez ini_set() logovat chyby do souboru na produkčním serveru?

Editoval Jakub Šulák (7. 4. 2009 19:21)

Jakub Šulák napsal(a):

EDIT: Ještě praktický dotaz, jde teda nějak rozumně (čti: bez psaní vlastní log class) bez ini_set() logovat chyby do souboru na produkčním serveru?

Bez ini_set (nebo ekvivalentního nastavení v .htaccess) nejde logovat chyby do souboru. Nepomůže ani vlastní log class, ta zachytí jen nedostatečný okruh chyb.

Zkus se zeptat na hostingu, jestli by ti ty direktivy, co se nastavují v Debug pomocí ini_set nenastavili. Možná by stačily jen error_log a log_errors.

Editoval romansklenar (9. 4. 2009 11:50)

Mám stejně postižený hosting, musí se zakomentovat ten řádek, o kterém jsem psal výše a nebude to vyhazovat žádné výjimky a když nastaví ty direktivy, dosáhne toho čeho chce bez toho aniž by psal nějakou svou logovací class, čemuž se snaží vyhnout.

Tam se tomu nevyhneš, já si to tam přímo upravuju tím že tam přidám podmínku, na localu si Nette aktualizuju přes svnko, takže se ty změny co tam udělám nepřepíšou, pak to přes svn vyexportuju (abych se zbavil všech těch meta .svn adresářů) a nahraju na server. Horší je to už s compact verzí…

Bohužel jsem to zatím nestihl ještě vyzkoušet, ale vypadá to, že to takto snad poběží. díky

Přesto bych však udělal změnu. Toto řeší použití ini_set() zde, ale já bych byl pro nějaké kompletnější řešení formou nějaké funkce:

<?php
function ini_set_extended($declaration, $value)
{
  if (ini_get($declaration)!==$value){
    if (function_exists('ini_set')){
      ini_set($declaration, $value);
      return TRUE;
    }else{
      throw new Exception('ini_set() is not allowed');
    }
  }else{
    return TRUE;
  }
}
?>

A nahradil takto všechny výskyty ini_set() v Nette. Tak by bylo možné používat všechny vlastnosti (i do budoucna), které v Nette budou používat ini_set() za předpokladu, že je ini_set() zakázáno, ale je možné konfiguraci navolit jinak (přes podporu hostingu).

Nejsem si jistý, ale pokud zavolá ini_set() (což dělá jako první), tak to stejně hodí vyjímku, že daná funkce neexistuje, ne? Nebo se to odchytí na vyšší úrovni než je ta metoda?

Byl bych vážně pro jednoduchý způsob, tak jak jsem psal výše. Dá se jen otestovat, co je rychlejší – zda volat ini_get() dříve nebo function_exists().

Ale já si myslím, že to zas tak velký zásah do Nette není. Navíc pokud je/byla funkce Tool::iniset() v Nette již implementována.

Domnívám se, že hodně lidí má právě problém s tím, že hosting nepodporuje ini_set() z bezpečnostních důvodů. Řešení typu „změň hosting“ neslyším rád, protože je jako od člověka z jiné planety – firmy mají už mezi sebou různé smlouvy, speciální řešení hostingu, apod. a změna není možná. Pokud se touto jednoduchou úpravou zajistí, že bude nette zase použitelnější, tak je to jenom dobře. Proto taky říkám, aby se to použilo všude, kde je/bude potřeba ini_set().

K tomu vysvětlování – před asi dvěma týdny jsem se znovu pokoušel vymáčknout vyjádření z jednoho nejmenovaného hostéra (bíle Č v červeném poli :)), které znělo takto:

povoleni teto funkce neni mozne z bezpecnostnich duvodu. Kdybychom ji povolili, uzivatele by si mohli menit nastaveni PHP na hodnoty, ktere by umoznily ohrozeni bezpecnosti serveru a dat jinych uzivatelu.

skocourek napsal(a):

povoleni teto funkce neni mozne z bezpecnostnich duvodu. Kdybychom ji povolili, uzivatele by si mohli menit nastaveni PHP na hodnoty, ktere by umoznily ohrozeni bezpecnosti serveru a dat jinych uzivatelu.

A ještě vymáčkni: kterou direktivu konkrétně a jak by to přesně ohrozilo bezpečnost serveru, pane hostére? ;)

Pokud Český hosting neumí dosud logovat chyby, tak je použitelný pouze na statické prezentace. Hostovat v něm aplikace Nette vám způsobí spoustu starostí, vezme spoustu času a stejně dřív nebo později odejdete jinam a budete si říkat „že já vůl to neudělal hned."

Já lidi vedu k tomu, aby se naučili dát sbohem hostingu, který jim nevyhovuje. Souvisí to s naší národní „zaprcaností“, my pokud dostaneme v restauraci nedobré jídlo, tak si sice řekneme „sem už nepůjdem“, ale personálu nedáme vědět nic, aby jsme je neurazili. Tak se to nedělá.

Tohle nesouvisí s frameworkem (nebo alespoň ne s Nette, u Zendu bude stejná nemožnost logovat chyby).

Argumenty o nákladech a smlouvách neberu. Roční hosting stojí totéž, co 3 hodiny práce programátora. Pokud nejdou logovat chyby, firma utratí za zbytečné debugování víc už při výskytu první chyby. Také pokud má někdo někde 100 prezentací, hostér mu milerád vyjde vstříc, není blázen, aby o takového klienta přišel kvůli ptákovině.

Takže ačkoliv jsem Debug::enable() před týdnem upravil, budu dál a stále víc brojit proti nekvalitním restauracím a hostérům ;) Proto vznikl Requirements Checker.

Hádat se nebudu, tvé argumenty chápu – jen si dovolím vyvrátit tvůj argument – roční hosting stojí 3 hodiny práce programátora.

1. převod hostingu – hrubá kalkulace nákladů

Změna systému importu faktur za hosting pro přefakturování svým klientům od firmy dodávající ekonomický systém – 15–20 000,–

Převod jednoho hostingu (pouze fyzické překopírování dat a kontrola nastavení a funkčnosti) á 200,– = 100*200=20 000,–

Nastavení e-mailových adres a v 30% případů půl hodinový telefon zákazníkovi – á 100,– = 10 000,–

Změna smluv – poplatky za právní služby = 10 000,–

Jednorázové platby za převod SSL a zřízení IP = 10 000,–

CELKEM: 55–60 000,–
na zákazníka: 5 500 – 6 000 Kč

Náklady jsou orientační, ale vycházejí z mé nedávné zkušenosti, kdy partnerská firma přecházela na jiný hosting. Tyto náklady není možné fakturovat zákazníkovi, jelikož mu nelze říci: "Váš předchozí hosting byl v pořádku, ale jelikož XYZ (nerozumí proč, ani nemůže) zaplaťte šesti násobek ročního poplatku.

Takže ačkoliv si jindy velice vážím tvého tlaku na lidi, v tomto případě dáváš firmám jasný signál, že mohou mít příště strach „co přijde příště“ :).

PS: V restauracích se rád ozvu – naposledy jsem dělal ostudu v Brně u Pandura, kde neumí (skutečně neumí) načepovat půl litr.;-)

Tady se ta debata na konci převedla spíše do úrovně, zda „vést“ firmy k tomu, aby měnili hosting, nebyla tu už ani tak řeč o samotné podstatě problému, který je jak jsi uvedl již vyřešen.

Šlo mi o to vývratit tvoji větu Já lidi vedu k tomu, aby se naučili dát sbohem hostingu, který jim nevyhovuje. a nahradit ji právě větou Říkat, že je to Nette, kdo nutí firmy měnit hosting nebo používat jiný framework, mi připadá jako chucpe.

Howgh.

skocourek napsal(a):

Žádané vymáčknutí. ;)

Jé, tichá pošta. Tak se jich zeptej na php_admin_value a php_admin_flag. Cituji:

php_admin_value: Sets the value of the specified directive. This can not be used in .htaccess files. Any directive type set with php_admin_value can not be overridden by .htaccess or ini_set(). To clear a previously set value use none as the value.