De alrededor de 2 semanas php 5.3 Entrar en la historia poco a poco. 11 anunció el final de su mantenimiento y jugó el solo parches de seguridad para 1 año. En General, PHP 5.4 pasa por etapas y edad PHP estable 5.5 se convierte en estable, que tipo de diversión porque usted todavía parte de las adiciones y de php no funcionan los plugins totalmente correctamente pero version 5.5 es bastante nuevo, así que me abstendré de migración le.

Así que vamos a decir para mi migración a 5.4 por 5.3. Había fijado previamente el información características obsoletas, los que han cambiado mi personalidad entera y los que ya no tiene que mantener para que no hay dramas en ambos lados si va a iniciar o no 😉 por lo que opté por hora de esta mañana para el comienzo de la migración en 7 como se convirtió en, existe un dolor mínimo durante la migración si no va sin problemas. Para mi inmensa sorpresa todo fue más bien – ha compilado el PHP 5.4.17 Comencé a apache y Oh cielos, es todo lo que. Un rápido vistazo a través de registros no rugido de depricated o funciones desconocidas – Al parecer, los chicos han hecho su trabajo bien. Entonces solo tengo que prekompiliram y adiciones que se compilan con la API antigua como APC, RAR de etcetera.. Un segundo reinicio y todo dormido. Por separado, esperar mejoras en el rendimiento porque en todas partes gente apuntando grande dedo del pie las bandejas que muestra cómo PHP 5.4 consume menos memoria RAM y se ejecuta secuencias de comandos más rápido.

Hace unos días salió XAMPP 1.8.0 Después de actualizar desde la versión 1.7.7 Tuve un problema bastante interesante. PhpMyAdmin, no mi abertura y izg″rmâvaše con 403

Acceso prohibido!


Nuevo concepto de seguridad XAMPP:

Acceso al objeto solicitado sólo está disponible desde la red local.

Este ajuste puede configurarse en el archivo “httpd-xampp.conf”.

Ahora abrí el xampp httpd conf que me... se encuentra en el/opt/lampp/etcetera/extra /, a primera vista, todo parecía bien. Las reglas para la red local estaban bien. Aparte abro localhost. WTF ??? Miré en el registro y ver que mi acceso es cortado por konfiguaciâta. Aquí cosas ya ahnaha me y francamente un poco de suerte encontré problema. Después de pasar sobre el httpd. conf y Sierra en la Permitir/denegar las cláusulas una última fila Requieren a todos los otorgados. Oh a Eureka. Este es el nuevo mecanismo de control que entró en Apache 2.4. x. Da acceso o rechazar tal todo fino, básicamente imitaron la funcionalidad de permitir/denegar :). Para solucionar el problema le añadimos requieren todos concedidos en carpeta del / opt/lampp/phpmyadmin. Después de los cambios en mi aspecto

<Directorio “/opt/lampp/phpmyadmin”>
AllowOverride AuthConfig límite
Orden permite,negar
Permite a todos
Requieren a todos los otorgados
</Directorio>

 

Siempre puedes probar otro divoti, por ejemplo, para cambiar el nombre de la carpeta phpmyadmin algo la otra y no alias para. Pero es feo y no muy significativa 🙂

p. s frecuentes por qué usar XAMPP y no limpiar la instalación de todos los componentes ya que es mi Debian nací – la respuesta es muy simple – PEREZA. Demasiado perezoso para escribir varios comandos entonces me haz konfovete etcetera.. Muy fácil es el paquete entero razarhiviraš y luz 😉

Mejorado por 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');

Mejorado por Zemanta

Hoy nos hablará sobre sus problemas sobre un servidor con Suhosin parche y cómo Debian Manipular de acuerdo con lo. Ahora vamos a empezar un poco de distancia. Al instalar php en el sistema de paquetes de Debian (estable para los demás, no puedo decir cómo es más) Debe instalar suhosin y mod a él. Tuve problemas con el sistema escrito de capas de php y tomé la decisión de kardinalnoto para hacer la depuración de aplicaciones en el sistema e informar al desarrollador para obtener el parche de seguridad y así ahorrarme dolores de cabeza. Generalmente puedo decir atrevidamente que esto fue una de las más insensatas decisiones siempre me. El siguiente deshacer snap-on PHP5-Suhosin restablecer un servidor web y oops de la viga – un parche está todavía cargado. Después de haber detectado una encuesta muy corta, ese paquete está compilado y con Pacha directamente en el código que significa que no apague o quite a menos que prekompilira el código nuevo sin cacahuetes. Decidir que se le dr″pna y prekompiliram para el Paquete deb. Han hecho hace apt-get source php5 me tira este código fuente, razpaketirva y así sucesivamente. Aquí la idea perfecta para descargar Sorsa del paquete para retirar los cacahuetes y compilarlo nuevamente al paquete de debianski plus una dos pequeñas optimizaciones para compilar. Dicho y hecho – He quitado la imagen del parche Debian/patches/Suhosin.patch He quitado no para tocar serie de parches de Debian. Aquí todo claramente y sin problemas. Entonces corro para recompilar el paquete con debuild y como esperaba mi compilación de estallidos debido a la falta de cabeceras. Por supuesto habrá tal escasez – Estoy con debian netinstall. Fijar su estupidez real rápido suelte nuevamente compilación, en un punto de primer ministro otra vez solamente, Es un extraño bug en Zend / zend_stream. h o c no recuerdo exactamente (Si el acuerdo puede más tarde para comprobar exactamente qué archivo y línea de que estaba hablando con). Después de un nedoumâvane lo que está sucediendo y por qué el infierno puede retumbar en Zend Core – donde no se supone que rumble en para sin razón y un estudio algo más detectaron que este problema es relativamente raro y no un montón de señales para él. Sospecho que ninguno de los parches en la fuente está mal, pero ahora no tengo nervios para verificar. Raro raro Super Hmmmmm. Casi me decidí a compilar php puro pero me decidí a probar los espejos dotdeb Vamos a ver qué va a pasar allí. Allí murió a causa de algunas dependencias extrañas pero brillante sobre los problemas en la parte principal de compilación. Que a su vez es comprensible que se habían ido 30-40 parches que estaban en el paquete estable. Después de varios intentos largo y no que me encogí de hombros he descargado paquete vainilla y compilado con opciones casi debian-ski con la idea de reescribir mi instalación actual e instalar nuevos paquetes desde el comedero que puede tener comportamiento del paquete instalado desde el repositorio de (probablemente un obosobno no sabia decisión). Como era de esperar sin parches de cualquier instalación fue sin problemas. Ésta es la salida de mi archivo config agradable.:

#! /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]"

Esta configuración es similar a la de la compilación de la dotdeb. Като основаното и най важно е prefix опцията където ще се разполагат файловете с библиотеките на php. Него както и другите пъти ги коригирайте според вашата система така че да не се усети компилацията с промяна на пътищата.

Mejorado por Zemanta

Vector logo of the PHP programming language wi...

Днес ще драсна едно леко четиво за php cache el 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 това си е ваше решение. Накрая изчистваме и прекратяваме кеширането. Съвсем тривиална операция ако да речем геенрирането на кеша минава през огромни блокове от код така можем да спестим доста процесорно време като кешираме за известно време или за една сесия. Вече всичко опира то това какво искате дали да е общодостъпен кеша или да е достъпен за различен потребител.

Mejorado por Zemanta