Konfigurace serveru

Dobrý den,
chtěl bych se zeptat, zda je možné nějak přenastavit konfiguraci serveru, protože jsem se rozhodl udělat stránky ve Frameworku a hlásí mi to, že by to chtělo povolit funkci ini-set, která je primárně disable na serveru, kde jsou strány uloženy. Je nějaká jiná možnost jak nastavit tuto funkci jen pro moje stránky, nebo je to bez problémů nastavit pro všechny.

Na foru Frameworku je rada, přejít k jinému poskytovateli, ale stránky co budu dělat jsou novou verzí pro staré stránky, které již uživateleé nají a tak bych nerad měnil adresu zaběhlé stránky.

Díky Petr
<HTML>Funkce ini_set jen tak někde povolena nebude, leda na nějakém vlastním serveru. Zkuste část kódu s funkcí ini_set zakomentovat (obejít, zrušit) a případně převést do souboru .htaccess coby php_flag.

Konkrétní postupy se dají najít, případně, nevíte-li si rady, hoďte sem ten kousek kódu, který dělá potíže.

PS. Až Vám autoři toho Frameworku budou tvrdit, že jsou odborníci a že vědí, co dělají, sdělte jim, že si myslím naprostý opak. Např. já jsem v životě funkci ini_set nepotřeboval, protože všechny věci, které se s ní nastavují, lze hodit jako php_flag do souboru .htaccess, který je podporován na mnohem více serverech než ini_set.</HTML>
Použit nebo nepoužít ini_set() je diskutabilní. Nejpoužívanější frameworky Zend i Nette funkci ini_set() normálně používají. Nejčastější využití je v detekci chyb, kdy ve vývojovém režimu máš striktní režim se zobrazením chyb a v produkčním naopak tichý režim bez zobrazení chyb. Navíc tyhle aplikace jsou stavěny tak, aby do toho uživatel nemusel zasahovat.
A to vůbec nemluvím o serveru IIS, kde tvé řešení selže, protože nepodporuje .htaccess.
>> .htaccess, který je podporován na mnohem více serverech než ini_set
No nevím. V defaultním nastavení Apache je .htaccess vypnuto. A pokud je na serveru PHP, tak je ini_set() vždy přítomno. Že to někdo zablokuje, je jiná věc. A opět Apache není jediný webserver. Samozřejmě, že .htaccess je ve většině případu přítomno, ale není rádno se na to spoléhat.

Velkou nevýhodou freehostingu je právě omezené nastavení. Takže ti, kdo chtějí hostovat na free serverech, si toto musí uvědomit. Důvodem, proč je to tak omezené, je bezpečnost. Poskytovatel neví, kdo je jeho klientem a co má v úmyslu. Proto musí počítat, že klient může na jeho písečku dělat různé lumpárny. Aby to nedělal, tak kritické funkce prostě zakáže.
V placeném hostingu je to jiné. Tam ví, kdo je klientem a může si tak na něj podat. Navíc od něj dostává zaplaceno. To částečně přinutí klienta změnit postoj a na placeným nebude dělat nic, co by ohrozilo server. Proto je tam také volnost nastavení.
<HTML>Frameworky mají být bez chyb, případně chyby mají být řádně ošetřované, stačí vlastní error handler, do konfigurace není potřeba zasahovat. Funkcí error_reporting se pak dá i řídit, které chyby bude interpret hlásit.</HTML>
Však zmíněné to mají ošetřené. Ale počítají s ním. Třeba "Nette Framework Requirements Checker" při absenci ini_get hlásí "Function ini_set() is disabled. Some parts of Nette Framework may not work properly." Davida Grudla považuji za odborníka. Takže musel mít nějaký důvod, proč použít ini_set();
<HTML>Asi ano - aby s tím štval provozovatele i klienty freehostingů.</HTML>
:)

Ale na druhou stranu. Freehostingy mají vlastní pravidla, která bývají odlišné od ostatních. Zvláště, když jsou odlišná pravidla i mezi sebou. Proto se pak není čemu divit, že na freeserverech něco nefunguje, protože si to server sám takto nastavil.
Většina tvůrců při tvorbě spoléhá, že své aplikace se budou provozovat na serverech s všeobecným nastavením. A tam je ini_set povoleno. Výjimka v podobě freehostingu je nemusí zajímat. Proč dělat výjimku pro nějakou menšinu. Samozřejmě mohl naspat kód tak, že ini_set není potřeba, ale znáš to. Každý má své znalosti, každý má své slabiny a každý má omezený čas. Takže buď to nevěděl nebo prostě neměl čas se tím patlat.