* Настройки на php.ini
Публикувано на 18 март 2010 в раздел ОСУП.
Файлът php.ini съдържа основните настройки за програмната среда PHP. Той съдържа изключително много променливи, но ние ще се спрем само над най-важните. Структурата е <име на променлива> = <стойност>.
- short_open_tag – Един PHP файл може да съдържа „микс“ между HTML и PHP код. Стандартно кода се огражда с <?php … ?>. Кратките тагове позволяват това да става с <? … ?>. По принцип се счита за лоша практика и е добре да го избягвате – стандартно дръжте стойността на off;
- output_buffering – стандартно трябва да инициализираме сесиите в PHP преди да са изпратени каквито и да е headers в HTTP протокола. Затова и стандартно output_buffering е off. Възможно е да дадем стойност, например 2048 байта, с която да направим буфер, в който да може да се записва информацията от HTTP headers и да бъде изпращана след инициализиране на сесията. Така сесията може да се инициализира навсякъде. Това е изключително лоща практика, която освен всичко има лош ефект върху производителността. Затова винаги дръжте стойността на off и винаги стартирайте сесиите преди всичко останало;
- expose_php – стойността по подразбиране е „on“, което изначава, че в http headers се изпраща версията на PHP. Принципно това е безсмислена информация – добре е да я скриете. Затова „добрата стойност“ е „off“;
- include_path – посочват се директориите с библиотеки, т.е. файловете в тях могат да се викат с „include“ без да се указва път. Стандартно в include_path се съдържа текущата директория „.“. Ако искате да добавите втора, то се използва разделител от двуеточие, например: „.:/usr/local/lib/php/pear:“;
- error_reporting – първоначално начинаещите администратори си мислят, че не е добре да дават информация на потребителите за това какви грешки се случват в системата. Променливата error_reporting е нещо като „глобална“ за „рапорт на грешки“. Наистина не бихме искали заради грешка в приложението ни да се показват грешки в браузъра на клиентите. Но не е и добре никога да не разбираме за тези грешки. Затова дръжте тази променлива със стойността по подразбиране E_ALL и използвайте следващите изброени променливи за настройка;
- display_errors – указва дали да се показват грешките в стандартната конзола. По подразбиране е „on“, което е добро само за машини за разработчици. На „production server“ го дръжте винаги на „off“ – вашите клиенти не трябва да виждат warnings и errors;
- display_startup_errors – също както display_errors, ние не бихме искали да показваме, че имаме проблеми по време на стартирането на PHP. Затова и тази стойност е добре да бъде „off“;
- log_errors – по време на разработката на приложение обикновено има много грешки и държим стойността на „off“. Когато става дума за приложение в реална среда обаче нещата се променят – там сме скрили грешките от потребителите, но ние лично се интересуваме сериозно когато те се появяват. Затова е добре да сложим стойността на „on“ и редовно да преглеждаме този log файл;
- error_log – като стойност указва името на log файла;
- log_errors_max_len – максимална дължина на лог файла в байтове;
- ignore_repeated_errors – по подразбиране е изключено (стойност 0). Ако се включи, то в лог файла ще бъдат записвани само уникални грешки;
- report_memleaks – по позразбиране стойността е true (т.е. 1). Указва дали да се записват в лог файла грешки свързани с утечки на памет;
- extension_dir – указва пътя (директорията) в която се намират разширенията на PHP. До PHP5 включително не е възможно да имаме разширения от различни директории, т.е. стойността на тази променлива е само една директория. Обикновено не я променяме, а пазим стандартните пътища;
- safe_mode – по подразбиране е изключено. От PHP6 тази опция ще бъде премахната (т.е. перманентно изключена). Ако се включи, то се презаписват include_path с директория зададена в 15. Също така се задава специална директория, в която да могат да се изпълняват външни програми с exec();
- safe_mode_include_dir – директорията за include_path при включен safe mode;
- safe_mode_exec_dir – директорията от която могат да се стартират външни програми с exec();
- open_basedir – указва „главната“ директория за PHP. Добра идея е да организирате сайтовете на потребителите си в специфична директория, например в /home, и да забраните на PHP скриптове да излизат извън нея. Затова се грижи open_basedir;
- max_execution_time – не е добре вашите скриптове да изпадат в безкрайни цикли и да натоварват сървъра ни. Всъщност това е и потенциална атака към стабилността. Затова е добре да изберем разумно максимално време за изпълнение на скрипт в секунди. Естествено понякога това има и своята вреда – скриптове, които отварят мрежови връзки, или такива изпълняващи множество тежки операции, може да не успеят да завършат своята работа;
- register_globals – това е „голямата болка“ на сигурността на PHP. В по-старите версии това „удобство“ водеше до огромни дупки в сигурността. След PHP4 по подразбиране е „off“. Очаква се в PHP6 да бъде премахнато като възможност въобще. Ако бъде включена, то имате възможност да приемате променливи от форми, например <input type=“text“ name=“email“ /> директно чрез име на променлива (от примера $email), вместо стандартния начин $_POST[’email’] или $_REQUEST[’email’]. Същото важи и за GET заявки. Силно препоръчваме да НЕ пускате register_globals никога. Ако даден стар софтуер не работи – поправете го, но не правете компромис със сигурността!;
- post_max_size – стандартно 8M, това указва максималното количество данни, което получаваме с POST заявки. Ако нямаме форми получаващи файлове, то можем спокойно да намалим стойността драстично. Това ще намали ефекта от потенциални атаки с невалидни заявки;
- max_input_time – нова променлива от PHP5, която указва какво е максималното време в секунди, за което PHP ще обработва POST заявки. Ако не очакваме голями POST заявки, то е добре да го намалим. Стойността винаги е разумно да е по-малка или равна на max_execution_time – в противен случай е безсмислена стойност;
- memory_limit – стандартно 8M – указва максималната RAM памет, която може да използва един PHP скрипт. Хубаво е да изчислявате теоретичния максимум памет за вашият „най-тежък“ скрипт и да слагате лимит на паметта спрямо него. Имайте предвид, че със сигурност стойността трябва да е по-голяма от post_max_size, защото информацията от POST заявките също се включват в общата използвана памет;
- register_argc_argv – важи само при извикване на скрипт през командния ред. Това са допълнителните параметри, които се подават към приложението. Рядко извикваме скриптове от командния ред, а още по-рядко им предаваме параметри. Затова го дръжте „false“;
- register_long_arrays – всяко модерно приложение ще го държи на стойност false. Тази стойност ще забрани остарелите $HTTP_GET_VARS и $HTTP_POST_VARS, които вече са заменени от по-модерните $_POST и $_GET масиви. Освен всичко друго подобрява и бързодействието. Важи само за PHP5 и по-нови версии;
- disable_functions – ако искате да забраните „опасни“ функции, то можете да ги изброите при тази променлива. Използва се често при „несигурна среда“ каквато например е споделен хостинг. Примерна стойност е „exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source“.
Както споменахме стойностите са много повече, но в общи линии изброените по-горе са най-съществените. Допълнително с повтарящите се променливи „extension“ можете да добавяте или премахвате разширения. Препоръчваме да добавяте само и единствено разширенията, които използвате.
И защо използването на „short_open_tag“ да е лоша практика и да се избягва?
Две причини:
1. Намалена преносимост на кода – немалко (и все повече и повече) хостинг провайдъри не поддържат short tags (тоест опцията е изключена);
2. Дублиране с други езици – например <?xml. Когато short open tag е включено затруднява работата с XML – PHP започва да интерпретира <?xml като PHP код…
Досега не съм засякъл хостинг провайдър, който да го изключва, незнам откъде си вадиш тези изводи. Да не говорим, че това прецаква и „<?=", което си е голям минус. Колкото до xml-a винаги можем да си го отпечатим с "<? echo'’; ?>“. В край на сметка не виждам нито едно причина да бъде спряно, а точно обратното.
Въпрос на вкус каза кучето и… Все пак навсякъде се препоръчва никога да не се пише със short tags. Пример – документацията на cakephp. Аз лично никога не бих писал код с <?…?>
Единственото нещо пак остава проблема с XML-a. Другото са пълни глупости. Кода далеч не става нечетим, друг е въпроса от задкомпютърното устройство и най-вече неговите навици и желанието му да възприеме нещо ново.
Това е малко като да ми кажеш, че и краткият if-else разваля кода и не се препоръчва да се ползва.
Предлагам ти да прочетеш книгата „Code Complete“ (тук има линкове http://codecourse.sourceforge.net/), да се запознаеш с практиките за програмиране на големи проекти в големи екипи и чак тогава да обсъждаме кое какво е.
Не го казвам като заяждане – просто ще установиш, че всичко е строго субективно. От тук нататък следва демократичния принцип: мнозинството определя нормите и до известна степен правилата. Е, в случая мнозинството е казало, че писането със short tags не е приемливо. Никой не спира никого да нарушава нормите (стига да не говорим за закони) тъй, че „въпрос на вкус каза кучето и…“.
Лоша практика според кой? След като постоянно ми говориш за тези големи проекти, би ли ми показал твой големи проекти или просто си го прочел в някоя дебела книжка?
Като гледам какво работиш и темата ти за MySQL OFFSET-a, ми става ясно защо толкова си защитаваш тезата. Това, че вече си свикнал с нещо не го прави най-доброто решение, точно заради такива практики цялото ни висше образование пълна скръб…
С горното не целя да те обидя, просто така ги виждам аз нещата.
Ясно, ти не си от хората, които четат книжки. За тях хората пишещи „дебелите книжки“ не разбират нищо и са пълни глупаци, които са си загубили времето. Някъде ги наричат „дървени философи“, „феодални старци“ и т.н. Явно за теб хората посветили живота си в дадена сфера и опитвайки се да предадат опита си на другите са просто „гадни нравоучители“. Изразът, който се използва е „я па тоя – ти ще ми кажеш!“.
Иначе разкри ме – не съм „програмист в действие“ и никак не желая да бъда. Това, което говоря е плод на прочит на ненужните „дебели книжки“.
П.С. Впрочем в PHP6 short tags ще бъдат изключени по подразбиране. Дали го правят само и само, за да дразнят „добрите програмисти“?
В такъв случай няма какво да говорим повече, нещата са ясни. Само ми е интересно как хора като теб без реален опит и практика смятат, че могат да пишат книги и да учат другите? От този въпрос можеш да разбереш и защо не чета книги ;)
Да господине – току що доказа, че не разбираш въобще, че има съществена разлика между понятията „Наука“ и „Практика“.
Иначе последната ми дума на тема „short tags“ ще бъде с още един пример от ZEND Framework:
„PHP code must always be delimited by the full-form, standard PHP tags… Short tags are never allowed„.
Защо ли тези глупави хора така затормозяват добрите програмисти? Или и ZEND не разбират нищо от „готино и бързо“ програмиране?
П.С. Впрочем виж какво пише в твоето собствено php.ini файлче:
; Allow the <? tag. Otherwise, only <?php and <script> tags are recognized.
; NOTE: Using short tags should be avoided when developing applications or
; libraries that are meant for redistribution, or deployment on PHP
; servers which are not under your control, because short tags may not
; be supported on the target server. For portable, redistributable code,
; be sure not to use short tags.
short_open_tag = ???
Choose your destiny…
Това го пише защото сървъра може да е „настройван“ от някой книжен разбирач като теб… По подразбиране тази стойност е включена или разработчиците на PHP незнаят какво правят? Така и не ми отговори на въпроса „как хора като теб без реален опит и практика смятат, че могат да пишат книги и да учат другите?“ и ми е чудно защо.
Е както казах за твое щастие опцията ще бъде изключена по подразбиране почти навсякъде след годинка-две, когато PHP6 стане моден.
Аз на въпроса ти „как хора като теб без реален опит и практика смятат, че могат да пишат книги и да учат другите?“ вече отговорих, но ти не ме разбра и няма как да ме разбереш. Накратко – има разлика между „академична дейност“ и „програмиране“. Ако мислиш, че в университета трябва да те учим за това как да станеш добър програмист във фирмата Х, то не си губи въобще времето да учиш въобще. По-добре ще бъде за теб веднага да отидеш във фирмата Х и там да се научиш на практика. В университетите се развива нещо, което се нарича „наука“. Самата дума „академично“ означава „хипотетично или теоретично; без очакване за практически резултати“.
Но пак казвам – няма и не би следвало да го разбереш. Осъзнаването на това какво и защо се учи по този начин в университета очаква да си достигнал определено ниво и да си натрупал достатъчно научни познания. За хората, които ги нямат, „в университета се учат безполезни глупости“. Пример от ТУ: „За какво ни е тая електротехника?“. Всъщност такива реакции са напълно нормални – някои хора още от 4ти клас тръдят, че „в училище се учат глупости“. А в училище се изучават предимно знания насочени към практиката, докато в университета напротив…
Хаха тука вече ме уби :D
1. Провери пак за PHP 6 и ще разбереш че изобщо няма да бъде премахван.
2. Влез в ted.com и виж какво казват за академичните глупости в момента и то го казват за най-добрите университети като цяло, а тук нещата са къде къде по-зле. Живей се в малкото ограничено святче и си мисли че си човек на науката :D
За мен темата е изчерпана.
1. Кога съм написал „премахнат“? Написах „опцията ще бъде изключена по подразбиране“. Защо ли?
2. Да, стоя и гледам как образователни традиции развивани с хиладолетия са натикани в „ограничено святче“ и ще бъдат променени за „нула време“. Само този, който може да го твърди, е ограничен. Иначе съм ги чел тези „бизнес идеи“. Нарочно ги наричам така – именно това целят: да изкарват пари от типично социална структура, каквато трябва да е образованието. Той и нашия образователен министър Сергей Игнатов ги е гледал. Да живеят „иновациите“ :)
хахаха в ted говорят едни от най-големите умове на нашето време, хора които са се доказали като най-добрите в своите области, ти с какво блестиш, че така говориш? станал си асистент? браво браво…
повече няма да пиша, няма смисъл да споря с толкова „широко“ скроен човек като теб, който е постигнал всичко в живота си… станал е асистент.
хайде лека вечер
Ами не, в никакъв случай не съм „голям ум“. Т.е. дори да съм – още нито аз нито други хора го знаят. Големите умове се доказват след много години труд. Е, трудя се – дали постигам нещо качествено или не: не съм аз човека, който трябва да го оценява.
Колкото до „големите умове“ – историята доказва много по-различни неща от това, което се опитват да ти втълпят в ted. Историята доказва, че всяко научно откритие е плод на дълъг колективен труд и много количествено натрупване на знания. Никой не се ражда гении – раждат се с потенциал за гении (доколкото се раждат нормални, без умствени проблеми всички са такива – от там нататък е стечение на обстоятелствата: семейство, финанси, шанс…). И тук идва бизнес модела на платеното образование, който ни лъже, че прави обучението по-качествено.
И сега какво предлагаш? Тези скапани университети да ги затворим? Интересни са ми разсъжденията ти. Обичам хора, които могат да критикуват (само и единствено) деградивно. Освен от българин от друг не съм го виждал :)
Напълно подкрепям господин Филип Петров в спорът му с дървената глава на многознайкото bubsss. Винаги ще има хора, които са научили едно нещо и не искат да се разделят с него. Въпросният господинчо трябва да се научи кое е успех в действителност и той никога няма да постигне и частица от това, което асистентите в държавните унивеситети са постигнали. Бог да пази България!
Малко followup за дискусията от по-горе:
1. От 2012 г. с PHP 5.4 <?= вече не е част от shorttags, т.е. не се премахва с изключването им;
2. На Short tags се слага Deprecation notice и по подразбиране е OFF в PHP 7.4, а в PHP 8.0 финално ще бъде премахнат напълно.