タグ付きの投稿 PHP

PHPのアップグレード 5.3 PHPへ 5.4

0

約から 2 PHPの週 5.3 彼はゆっくりと、しかし確実に物語に入ります. 11日に彼らはそのメンテナンスの終了を発表し、それがための唯一のセキュリティパッチを配置されます 1 年. 基本的にPHP 5.4 ステージ旧安定版とPHPで行きます 5.5 安定, これは追加して、新しいPHPのプラグインのさらに一部はかなり正常に動作しませんので、あまり楽しいものですが、バージョン 5.5 私はそれへの移行を控えるように、それはかなり新しいです.

それでは、移行に私のために言わせて 5.4 から 5.3. 私は以前に入れていました 情報 廃止された機能のために, 劇的に変化したものと、もはや発火や周りの移行の開始の😉だから今朝のタイミングではないでしょう両側にノードラマのために維持されません人々 7 なってきて, スムーズに行かない場合は、最小限の痛みは、移行中に存在すること. 私の大きな驚きに、すべてがよりスムーズに行ってきました – あなたのPHPをコンパイル 5.4.17 私はそれを開始し、Apache-OH天のすべてがそこにあります. ログの周りの一目は、廃止予定か、全く未知の機能の轟音ます – 明らかに人はよく自分の仕事をしています. その後、私はちょうど再コンパイルしたAPCなどの古いAPIを使用してコンパイルされているサプリメント, RARおよび他の. 2回目の再起動、すべてが眠りに落ちました. 人々はどこにでも足の親指をどのようにPHPを示し、いくつかの錠剤を指しているように離れて生産性の向上を期待します 5.4 少ないRAMを消費し、より高速なスクリプトを実行します.

WordPress easy domain and url change

0

ワードプレスであなたのドメインを変更するには、いくつかの痛みであります. 最近、私はすでに速いスポーツが起こっていくつかのことをしなければなりませんでした😀 . 私はステップをsumariziramことができる場合です 2 – 自然にファイルを移動することなく、, 設定の変更が完全にホスティングする場合.

1. 新しいに古いURLを変更 – 些細な事で、ここで私. あなたのwp-config.phpファイルを開き、これらに置きます 2 行


define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');

置き換えとしてhttp://あなたの新しいとexample.com.

2. これまでのところは良い、今サイトでは、このような画像などのURL番目の作業が、アップロードされたコンテンツを開きます, ドキュメントとそうは見えません. ここでは、すでに厄介な課題を持っています. 彼らは、新しいデータベースに古いURL番目を交換する必要があります. これは、初心者のために特にひどく面倒なプロセスでした, SQL構文とうまく対応できません, но вече има доста приятен скрипт searchreplacedb2, これはあなたのためにそれが不快になります. 使用が簡単です – ワードプレスは、あなたのページのルートディレクトリにアップロードし、ブラウザ-あなたにそれを開きます. След това следвате стъпките като първо ще ви пита за потребителско име и парола който е взел от вашия wp-config.php и след това ще ви пита за новото и старото url. След последната стъпка ще се наложи да поизчакате при мен отнемаше средно 40сек -50сек.

Това е във общи линии нищо трудно или супер сложно.

Debian fix php session lifetime

3
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');

Zemantaの強化されたことにより、

debian sqeeze remove suhosin patch

0

Днес ще разказвам за неволите си около един сървър със Suhosin patch и как Debianの Sqeeze се справя с него. Сега да започнем малко по отдалече. Когато си инсталирате php през пакетната система на Debian (stable за другите не мога да кажа как е още) задължително ви се инсталира и suhosin mod към него. Имах проблеми с едни плу-кадърно написана php система и взех кардиналното решение вместо да правя дебъг на системата и да връщам репорт на разработчика да разкарам кръпката за сигурност и така да си спестя главоболията. Общо взето смело мога да кажа че това е било едно от най глупавите ми решения взимани някога. Най напред премахвам модула на php5-suhosin рестартирам web server-a и опа гредаpatch-a все още е зареден. След много кратко проучване откривам, че пакета е компилирах и с пача директно в кода което ще рече че няма изключване или премахване освен ако не се прекомпилира кода наново без пача. Решавам че ще го дръпna и прекомпилирам до deb пакет. Речено сторено правя си apt-get source php5 дърпа ми се настоящия сорс код, разпакетирва се и прочие. Тука идеалната ми идея да сваля сорса на пакета да премахна пача и да го компилирам отново до дебиански пакет плюс една две малки оптимизации по компилацията. Речено сторенопремахнах ненужния пач от debian/patches/suhosin.patch премахнах го да не играе и в debian/patches/series. До тук всичко ясно и без проблеми. След това пускам да се компилира пакета с debuild и както очаквах ми изгърмя компилацията заради липсващи хедъри. Естествено че ще има такива липсивсе пак съм с debian netinstall. Поправям набързо глупостта си пускам наново компилацията, в един момент отново премира само, че със странна грешка в Zend/zend_stream.h или .c не помня точно (ако ми се занимава може по късно да проверя точно кой файл и на кой ред гърмеше). След известно недоумяване какво се случва и защо аджеба гърми в Zend ядротокъдето не би трябвало да гърми по никаква причина и едно малко по дълго проучване откривам че тоя проблем е относително рядък и няма много сигнали за него. Подозирам че някоя от кръпките в сорса не е наред но сега нямам нерви за да го проверявам. Хммммм странно супер странно. Почти реших да си компилирам чисто php но реших да пробвам огледалата на dotdeb да видим там какво ще се случи. Там компилацията умря заради някакви странни зависимости но подмина проблемите в основната част. Което от своя страна е разбираемо нямаше ги те 30-40 кръпки който бяха в стабилния пакет. След няколко дълги и неуспешни опита ми писна и сви свалих ванила пакета и го компилирах с почти debian-ски опции с идеята да пренапише настоящата ми инсталация и като се инсталират нови пакети от хранилката да може да има поведение на пакет инсталиран от хранилището (вероятно поредното не обособно разумно решение). Както очаквах без всички кръпки инсталацията мина гладко. Това е изхода на 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' \
"$@"

Това е конфигурация близка до тази на компилацията на dotdeb. Като основаното и най важно е prefix опцията където ще се разполагат файловете с библиотеките на php. Него както и другите пъти ги коригирайте според вашата система така че да не се усети компилацията с промяна на пътищата.

Zemantaの強化されたことにより、

php html cache

0
Vector logo of the PHP programming language wi...

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

Zemantaの強化されたことにより、
ページのトップへ