de la aproximativ 2 săptămâni php 5.3 El intră povestea încet, dar sigur. La data de 11 au anunțat la sfârșitul întreținerii sale și care vor fi plasate numai patch-uri de securitate pentru 1 an. In principiu PHP 5.4 merge în etape stabile vechi și PHP 5.5 devine stabilă, care este mai puțin distractiv, deoarece încă o parte din noi adăugiri și plugin-uri php nu funcționează destul de corect, dar versiunea 5.5 Este destul de nou, astfel încât mă voi abține de la migrarea către acesta.

Deci, să spunem pentru mine migrația 5.4 din 5.3. Am avut dezvoltat anterior informații pentru funcțiile depășite, cei care s-au schimbat în mod dramatic, iar cei care nu vor mai fi menținute pentru dramele pe ambele părți, care nu se va aprinde sau 😉 Deci, această sincronizare dimineața de începere a migrației în jurul valorii de 7 devenire, că există o durere minimă în timpul migrației în cazul în care nu merge fără probleme. Spre marea mea surpriză, totul a mers mai lin – compilat PHP-ul 5.4.17 Am început și-oh apache ceruri totul este acolo. O privire rapidă în jurul jurnalele vor răcni de funcții depricated sau deloc necunoscut – în mod evident, băieții au făcut bine treaba. Apoi am fost doar recompilarea și suplimente care sunt compilate cu API-ul vechi ca APC, RAR și altele. În al doilea rând de repornire și totul a adormit. se așteaptă în afară îmbunătățirea productivității ca oamenii de pretutindeni arătând degetul mare în cazul în care unele tablete arată cum PHP 5.4 consumă mai puțin RAM și execută script-uri mai rapid.

Câteva zile afară XAMPP 1.8.0 ieri după upgrade de la versiunea 1.7.7 Am avut destul de o problemă interesantă. PhpMyAdmin și el nu se deschide și a urlat cu 403

Accesul interzis!


Noul concept de securitate XAMPP:

Accesul la obiectul solicitat este disponibil numai din rețeaua locală.

Această setare poate fi configurată în fișierul “httpd-xampp.conf”.

deschis imediat httpd-xampp.conf care pentru mine este în / opt / lampp / etc / extra /, La prima vedere, totul arata fin. Regulile pentru rețeaua locală au fost printre. În afară de localhost de deschidere. WTF ??? M-am uitat la log-și poate vedea că accesul meu este tăiat de konfiguatsiyata. Iată acum ce am suspinat și, sincer, oarecum mai puțin noroc găsit problema. După merge peste httpd. conf şi văzut în permite/Deny clauzele un ultimul rând Solicite toate acordate. Oh eureka. Acesta este un nou mecanism de control care a intrat în Apache 2.4.x. Acesta oferă acces sau refuzul unei astfel de amenzi, practic imita Allow / Deny funcționalitate :). Pentru a remedia problema adăugăm necesită toate acordate în folderul / opt/de lampp/phpmyadmin. După schimbările din mine arata ca

<director “/opt / lampp / phpMyAdmin”>
AllowOverride authconfig Limita
comanda permite,nega
Se lasă la toate
Solicite toate acordate
</director>

 

Viangi poate încerca un alt sălbatic, de exemplu, pentru a redenumi ceva dosar phpMyAdmin altul și nu alias pentru. Dar e urât și nu foarte semnificativ 🙂

P.S m-au întrebat de ce folosesc XAMPP nu instalare curată a tuturor componentelor așa cum le este Debian meu născut – Răspunsul este într-adevăr foarte simplu – LENE. Mi prea leneş pentru a scrie mai multe comenzi, apoi obţine konfovete etc.. Destul de uşor este să ia întregul pachet razarhiviraš şi de lumina 😉

Consolidată prin Zemanta

Debian OpenLogo

Миналия ден един приятел ми писа че имал проблем с Debian server-a си. По точно не му пазел сессиите повече от 30 минути независимо колко се настройва session.gc_maxlifetime. В общи линии проблема е че Debian са решили да пренапишат поведението на сесиите като вместо garbage collector-а се стартира един cron на всяка 9-та и 39-та минута който почиства старите сесии. Тои се намира в /etc/cron.d/php5

като цяло семпличък скрипт който стартира от своя страна /usr/lib/php5/maxlifetime и в него се намира променливата колко време да е живота на кукито който е 1440 секунди или 24 минути 😉 От тук нататък има 2 варианта или да се спре крон-а и по този начин се прекратява автоматичното чистене което може по късно да се пренастрой от php.ini или направо в самия скрипт да се промени продължителноста на живота на сесиите с променливата max. Аз лично предпочитам втория вариант. Доста по чист е като цяло но има и недостатъкако се презапише файлът промените ни ще се изгубят което си е неприятен факт.

ps. Сега като се замисля вероятно ако се дефинира друго място където да се съхранява сеиината информация чрез самото php би трябвало да излезе извън обхвата на скрипта и по този начин да се използва пак по нормален сесията без да прекъсва грубо.

ini_set('session.gc_maxlifetime', 14400);
 ini_set('session.gc_probability', 1);
 ini_set('session.gc_divisor', 100);
 session_save_path(APP_PARENT_DIR . '/sessions');

Consolidată prin Zemanta

Azi am vorbi despre durerile în jurul unui singur server cu Suhosin patch-uri și de modul în care Debian afacere Sqeeze cu ea. Acum începem o mică distanță. Când instalați php în sistemul de ambalare Debian (stabil pentru alții nu pot spune cum încă) trebuie să instalați și Suhosin mod de a-l. Am avut probleme cu un anumit sistem MAH-cadru scris în php și a luat decizia de cardinal în loc să facă depana sistemul și din spate de rapoarte pentru dezvoltatori pentru a pierde patch-uri de securitate și, astfel, salvați-am probleme. În general, pot spune cu îndrăzneală că aceasta a fost una dintre deciziile cele mai stupide am luat vreodată. La început, modul de eliminare php5-Suhosin repornire server web și o oops postare – patch-o este încă încărcat. După un scurt studiu găsit, că pachetul este compilat și direct în trece la trap cod, ceea ce înseamnă că nu excludere sau de îndepărtare, cu excepția cazului recompilați codul din nou fără patch-uri. Care va rezolva drapna și recompilati la pachetul deb. Făcut mai devreme a spus face apt-get php5 sursă mă trage acest cod sursă, razpaketirva și etc. Aici ideea mea ideală pentru a elimina sursa pachetului pentru a elimina plasturele și compila-l înapoi la pachetul Debian, plus una din două mici optimizări în compilare. a declarat terminat – elimina patch-uri inutile de debian / patch-uri / suhosin.patch L-am scos de la joc în debian / patch-uri / serie. Până în prezent, totul în mod clar și fără probleme. Apoi rulați pentru a compila pachet debuild și așa cum am așteptat, am suflat compilare din cauza antete lipsă. În mod natural va exista nici o penurie – Sunt încă cu netinstall debian. fix rapid prostie rula din nou compilare, la un moment dat doar leșin din nou, că, cu o eroare de ciudat în Zend / zend_stream.h sau .c nu amintesc exact (dacă mă pot ocupa mai târziu pentru a verifica exact ce fișier și linia tunat). Dupa ce unele îndoielii ceea ce se întâmplă și de ce dracu 'se poate vuietul miezului Zend – în cazul în care ar fi trebuit să bubuie din orice motiv și un pic de studiu mai constată că această problemă este semne relativ rare și nu multe din ea. Bănuiesc că unul dintre patch-uri din sursa a fost greșit, dar nu am nici nervi pentru a verifica it. Hmmmmm ciudat super-ciudat. Aproape am decis să compila php pură, dar am decis să încerc oglinzi dotdeb acolo pentru a vedea ce se întâmplă. Acolo compilare a murit din cauza unor dependențe ciudate, dar ferite de probleme în corpul principal. Care la rândul său, este de înțeles că le au 30-40 patch-uri care au fost în ambalaj stabil. După mai multe încercări nereușite de lungi și m-am saturat si inchis, pachetul meu de vanilie si compila-l cu opțiuni de aproape debian-ski cu ideea de a rescrie sistemul meu actual și instalarea unor noi pachete din alimentatorul se poate comporta pachet instalat din depozit (probabil, o altă diferențiată nu este o soluție rezonabilă). Așa cum mă așteptam, fără nici o instalare patch-uri a mers fără probleme. Acesta este rezultatul dosarul meu config.nice:

#! /bin/sh
#
# Created by configure

CFLAGS='-g -O2 -fPIC -Wall -fsigned-char -fno-strict-aliasing   -gstabs' \
CXXFLAGS='-g -O2' \
'./configure' \
'--with-apxs2=/usr/bin/apxs2' \
'--prefix=/usr/local/php5' \
'--disable-cgi' \
'--with-config-file-path=/etc/php5/apache2' \
'--with-config-file-scan-dir=/etc/php5/apache2/conf.d' \
'--build=x86_64-linux-gnu' \
'--host=x86_64-linux-gnu' \
'--sysconfdir=/etc' \
'--localstatedir=/var' \
'--mandir=/usr/share/man' \
'--disable-debug' \
'--with-regex=php' \
'--disable-rpath' \
'--disable-static' \
'--with-pic' \
'--with-layout=GNU' \
'--with-pear=/usr/share/php' \
'--enable-calendar' \
'--enable-fileinfo' \
'--enable-hash' \
'--enable-json' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-sysvmsg' \
'--enable-bcmath' \
'--with-bz2' \
'--enable-ctype' \
'--without-gdbm' \
'--with-iconv' \
'--enable-exif' \
'--enable-ftp' \
'--enable-dbase' \
'--with-gettext' \
'--enable-mbstring' \
'--with-onig=/usr' \
'--with-pcre-regex' \
'--with-mysql=shared,mysqlnd' \
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' \
'--with-mysqli=shared,mysqlnd' \
'--enable-pdo=shared' \
'--with-pdo-mysql=shared,mysqlnd' \
'--with-pdo-odbc=shared,unixODBC,/usr' \
'--with-pdo-pgsql=shared,/usr/bin/pg_config' \
'--with-pdo-sqlite=shared,/usr' \
'--with-pdo-dblib=shared,/usr' \
'--enable-phar' \
'--enable-shmop' \
'--enable-sockets' \
'--enable-dom' \
'--enable-wddx' \
'--enable-tokenizer' \
'--with-zlib' \
'--with-kerberos=/usr' \
'--with-openssl=/usr' \
'--enable-soap' \
'--enable-zip' \
'--with-mhash=yes' \
'--with-exec-dir=/usr/lib/php5/libexec' \
'--with-system-tzdata' \
'--without-mm' \
'--with-readline=/usr' \
'--without-sybase-ct' \
'--without-sqlite' \
'--without-sqlite3' \
'--without-mssql' \
'--enable-pcntl' \
'--enable-inline-optimization' \
"[email protected]"

Această configurație este similară cu cea a dotdeb compilare. Като основаното и най важно е prefix опцията където ще се разполагат файловете с библиотеките на php. Него както и другите пъти ги коригирайте според вашата система така че да не се усети компилацията с промяна на пътищата.

Consolidată prin Zemanta

Vector logo of the PHP programming language wi...

Днес ще драсна едно леко четиво за php cache de html. Тука говорим за кеширане на изхода от кода ни а не както съм писал да кешираме скритповете до opcode ниво с eAccelerator. Така за какво иде речнека да си припомним на бързо работата на php-то. Подаваме заявка на web server-a ни той приема параметрите който подаваме след това той ги подава на php скрипта той се компилира и плюе резултат в html вариант. Това е в доста общи линии. Каква ще е идеята ни тука да прескачаме заявки, да прескачаме големи блокове или не чак толкова големи блокове като директно изрисуваме вече веднъж компилирания изход. Преимуществата са очевиднинамаляна на времето за изпълнение, по малко натоварване и потребление на ресурси. Като цяло не е откриване на топлата вода нито е нещо кой знае колко сложно. Има множество класове за тая цел като PHP Pear Cache_Lite който разполага с прекрасна функционалност но аз мисля в бъдеще да си напиша мой с доста по облекчена структура и мой си изисквания към кеширането. Сега ще разгледаме най аборигенския вариант с Output Control Functions. Така нека да кешираме нещо

//start cache all output after that will be saved

ob_start();

//generate output

echo 'Some dynamic output';

echo 'Some other dynamic output ...';

//assign output into variable

$var=ob_get_contents();

//close cache output

ob_end_flush();

Горния код е тривиален но нека да обясним какво стана. Първо декларираме от коя част в кода започва кеширането. След това си генерираме по стандартен начин изхода от кода. След това генерирания изход се присъединява към променлива която ще е достъпна по късно дали през файл някакво или през sessions това си е ваше решение. Накрая изчистваме и прекратяваме кеширането. Съвсем тривиална операция ако да речем геенрирането на кеша минава през огромни блокове от код така можем да спестим доста процесорно време като кешираме за известно време или за една сесия. Вече всичко опира то това какво искате дали да е общодостъпен кеша или да е достъпен за различен потребител.

Consolidată prin Zemanta