From about 2 Weeks PHP 5.3 Enters the story slowly but surely. On the 11th announced the end of its support and that only security patches will be released for 1 Year. Basically PHP 5.4 goes into old stable stages and PHP 5.5 becomes stable, Which is a little fun because still part of the additions and plugins of PHP do not work quite correctly but also a version 5.5 is quite new so I will refrain from migrating to it.
So let me tell myself about my migration to 5.4 от 5.3. I had pre-posted Information For outdated features, Those that have changed cardinal and those who will no longer be supported to have no dramas on both sides whether it will ignite or not 😉 so today morning I chose a time to start the migration around 7 When I became, That there is minimal pain in migration if it does not go smoothly. To my huge surprise everything went more than smooth – I compiled my PHP 5.4.17 I started the Apache and oh heavens everything is there. A quick glance through the logs there is no roar of depricated or unknown functions at all – Apparently the boys have done their job well. Then I just have to recompile and the additions that are compiled with the old API like APC, RAR, etc.. Second reboot and everything fell asleep. Separately, I expect performance improvements, since people point to the big finger everywhere, some trays showing how PHP 5.4 Consumes a bit of RAM and runs scripts quickly.
Преди няколко дни излезеXAMPP 1.8.0 вчера след надграждане от версия 1.7.7 имах доста интересен проблем. Phpmyadmin-а не ми се отваряше и изгърмяваше със 403
New XAMPP security concept:
Access to the requested object is only available from the local network.
This setting can be configured in the file “httpd-xampp.conf”.
Веднага отворих httpd-xampp.conf който при мен се намира в /opt/lampp/etc/extra/, на пръв поглед всичко изглеждаше наред. Правилата за локалната мрежа бяха наред. Отделно че отварях от localhost. WTF ??? Погледнах log-а гледам че достъпа ми е отрязан от конфигуацията. Тука вече нещата ме ахнаха и честно казано донякъде малко на късмет открих проблема. След като преглеждах httpd.conf-а видях в Allow/Deny клаузите един последен редRequire all granted. О да еврика. Това е новия контролен механизъм който влезе вapache 2.4.x.С него се дава достъп или се отказва такъв на всички изискани, в общи линии се имитира Allow/Deny функционалността :). За да поправим проблема добавяме Require all granted в директивите за папката /opt/lampp/phpmyadmin. След промените при мен изглежда така
<Directory “/opt/lampp/phpmyadmin”> AllowOverride AuthConfig Limit Order allow,deny Allow from all Require all granted
Вианги може да се пробва и друга дивоти, например да се преименува папката phpmyadmin на нещо други и да се направи alias към не. Но е по грозно и не особено смислено 🙂
p.s Питаха ме защо ползвам XAMPP а не чиста инсталация на всички компоненти както си ги е моя Debian родил – отговорът е много много прост – МЪРЗЕЛ. Мързи ме да напиша няколко команди после да си пипна конфовете и прочие. Доста по лесно е сваляш целия пакет разархивираш и палиш 😉
Last day a friend wrote me that he had a problem with Debian Server-A. He's not exactly keeping him up more than 30 Minutes no matter how much you adjust Session gc_maxlifetime. В общи линии проблема е че Debian са решили да пренапишат поведението на сесиите като вместоgarbage collector-а се стартира един cron на всяка 9-та и 39-та минута който почиства старите сесии. Тои се намира в /etc/cron.d/php5
като цяло семпличък скрипт който стартира от своя страна /usr/lib/php5/maxlifetime и в него се намира променливата колко време да е живота на кукито който е 1440 секунди или 24 Minutes 😉 from now on there are 2 option or stop the Crohn and thus terminate the automatic cleaning which can later be readjust from PHP. ini or directly in the script itself to change the duration of the session life with the variable max. I personally prefer the second option. It's a lot cleaner, but there's a flaw – If you overwrite the file our changes will be lost which is an unpleasant fact.
Ps. Now that I think about it, perhaps if a different place is defined where the information is to be stored through PHP itself, it should go beyond the scope of the script and thus be used again in the normal session without interrupting rude.
Today I will tell about my woes around a server with Suhosin Patch and how Debian Sqeeze copes with it. Now let's start a little farther away. When you install PHP through the Debian package system (Stable for others I can not say how is even) Necessarily you install and Suhosin mod to it. I had problems with some Prettywell written PHP system and I took the cardinal decision instead of making a system glitch and returning the developer to get rid of the security patch and save myself headaches. In general, I can boldly say that it was one of my most foolish decisions taken ever. At the outset, I remove the PhP5-Suhosin I reset the Web server-A and oops girder – Patch-A is still loaded. After a very short study, I detected, That the package was compiled and with the stack directly into the code meaning there is no shutdown or removal unless you recompile the code again without the patches. I decide that I will pull it and recompile it to the Deb package. Said done do your apt-get source php5 pulls my current source code, unpacked, etc.. Here's my perfect idea to download the package Sori to remove the patches and compile it again to a Desian package plus a two small build optimizations. Spoken done – Removed the unnecessary patch from the Debian/Patches/suhosin. patch I removed it not to play and in Debian/Patches/series. So far, everything clearly and without problems. Then I release to recompile the package with Debuild And as expected I blew up the compilation because of missing headers. Of course there will be such shortages – Though I am using Debian netinstall. I quickly redo the compilation, At some point again only, That with a strange error in Zend/zend_stream. h or. c Do not remember exactly (If I am concerned I may later check exactly which file and in which order it was). After some misunderstanding what is happening and why the Adjeba Rumble in the Zend kernel – Where I would not have to rumble for any reason and a little longer study discovered that this problem is relatively rare and there are not many signals about it. I suspect that one of the patches in the sori is wrong but now I have no nerve to check it. Xmmmmm Strangely Super Strange. I almost decided to compile a purely PHP but I decided to try the mirrors of dotdeb See there what happens. There, the compilation died because of some strange dependencies but the problems in the main part. Which in turn was understandable they were not 30-40 Patches that were in the stable package. After a few long and unsuccessful attempts I got tired and I took off the vanilla package and compiled it with almost Debian-ski options with the idea to rewrite my current installation and installing new packages from Feeder can have the behavior of the package installed from the repository (Probably another non-differentiated solution). As I expected without all the patches the installation went smoothly. This is the output of my config. nice file:
This is a configuration similar to that of the Dotdeb build. The prefix option, where the PHP library files will be deployed, is as based and most important.. As well as the other times correct them according to your system so as not to feel the build with the change of roads.
Today I will scratch a light reading about PHP Cache Of Html. We're talking about caching the output of our code, not as I've written to cache the spikes to OpCode Level with eAccelerator. So what's the speech – Let us remember the rapid work of PHP. We submit a request to Web server-A US he accepts the parameters we submit then he submits them to the PHP script he compiles and spits the result in HTML version. This is in pretty general terms. What would be our idea here to skip orders?, To jump over large blocks or not such large blocks as we directly paint the already compiled output. The advantages are obvious – Reduction in the execution time, By less load and resource consumption. Generally it is not discovering the hot water nor is it something who knows how complicated. There are many classes for this purpose as PHP Pear Cache_Lite which has great functionality but I think in the future I will write my own with a rather more streamlined structure and my own caching requirements. Now we will look at the Aboriginal version with Output Control Functions. So let's cache something –
//start cache all output after that will be saved
echo 'Some dynamic output';
echo 'Some other dynamic output ...';
//assign output into variable
//close cache output
The above code is trivial but let's explain what happened. First we declare which part in the code starts caching. Then we generate the output from the code in a standard way. The generated output is then joined to a variable that will be available later whether through a file any or sessions this is your decision. Finally, we clear and disable caching. A very trivial operation, if we say cache geoscanning goes through huge blocks of code so we can save a lot of CPU time by caching for a while or for a single session. It's now all about what you want whether to public the cache or be available to a different user.