From about 2 weeks php 5.3 enters history slowly but surely. On the 11th, it announced the end of its support and that only security patches would be released for 1 year. In general, PHP 5.4 goes into old stable stages and PHP 5.5 becomes stable, which is a bit fun because some of the add-ons and plugins of php still 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 you about my migration to 5.4 from 5.3. I had released it in advance information for obsolete features, those that have changed dramatically and those that will no longer be maintained so that we do not have drama on both sides whether it will ignite or not 😉 So this morning I chose the time to start the migration around 7 as he got up, that there is minimal pain during migration if it does not go smoothly. To my great surprise, everything went more than smoothly – I compiled my PHP 5.4.17 I started apache and oh heavens everything is there. A quick look through the logs has no roar of depricated or unfamiliar features at all – apparently the boys did a good job. Then all I had to do was recompile the add-ons that were compiled with the old API like APC, RAR and others. Second restart and everything fell asleep. Separately, I expect improvements in performance because everywhere people point with their thumb to some tablets that show how PHP 5.4 consumes less RAM and executes scripts faster.
Changing a domain in WordPress is a pain. I've had to do a few lately and things are happening sportily fast 😀 . If I can summarize the steps are 2 – of course without moving the files, настройките ако се сменя изцяло хостинга.
1. Промяна на старото URL със новото – тука нещата са тривиални. Отваряте си wp-config.php файлът и във него поставяте следните 2 order
Като замествате http://example.com със вашият нов.
2. So far, the site opens well, the urls work, but the uploaded content as pictures, documents and so on are not visible. Rough intervention is already required here. The old urls must be replaced with the new ones in the database. This was a terribly unpleasant process, especially for novice users, which do not handle SQL syntax well, but there is already a pretty nice script searchreplacedb2, who does everything unpleasant for you. Its use is trivial – you upload it to the main directory where your wordpress page is located and open it through your browser. След това следвате стъпките като първо ще ви пита за потребителско име и парола който е взел от вашия wp-config.php и след това ще ви пита за новото и старото url. After the last step you will have to wait for me it took an average of 40 seconds -50 seconds.
This is basically nothing difficult or super complicated.
Last day a friend wrote me that he had a problem with Debian your server. Exactly did not keep his sessions more than 30 minutes no matter how much is set session.gc_maxlifetime. In general, the problem is that Debian has decided to rewrite the behavior of the sessions as instead garbage collector-and a cron is started every 9th and 39th minute that clears the old sessions. Тои се намира в /etc/cron.d/php5
generally a simple script that starts / usr / lib / php5 / maxlifetime and contains the variable how long the life of the cookie is 1440 seconds or 24 minutes 😉 From now on there are 2 option or to stop the cron and thus stop the automatic cleaning which can later be reconfigured by php.ini or directly in the script to change the lifespan of the sessions with the variable max. I personally prefer the second option. It is much cleaner in general but there is a drawback – if the file is overwritten, our changes will be lost, which is an unpleasant fact.
ps. Now that you think about it, if you define another place to store your information via php itself, it should go beyond the scope of the script and thus be used again in a normal session without interrupting it roughly..
Today I will talk about my troubles around a server with Suhosin patch and how Debian Sqeeze handles it. Now let's start a little further. When you install php through the Debian package system (stable for others I can't say how it is yet) be sure to install and suhosin mod to it. I had problems with a plu-frame php system and I made the cardinal decision instead of debugging the system and returning a report to the developer to lose the security patch and thus save my headaches.. In general, I can safely say that this was one of the stupidest decisions I have ever made. First I remove the module of php5-suhosin restart the web server and opa beam – the patch is still loaded. After a very short study I find out, that the package was compiled with a patch directly in the code, which means that there is no shutdown or removal unless the code is recompiled again without a patch. I decide to download it and recompile to a deb package. That said, I'm doing my apt-get source php5, I'm pulling the current source code, unpacked and so on. Here's my perfect idea to download the source of the package to remove the patch and recompile it to a debian package plus one or two small compilation optimizations. Said done – I removed the unnecessary patch from debian/patches/suhosin.patch removed it not to play and in debian/patches/series. So far, everything is clear and without problems. Then run to compile the package with debuild and as I expected, my compilation crashed due to missing headers. Of course, there will be such shortcomings – I'm still with debian netinstall. I quickly correct my stupidity and re-compile, at one point it just dies again, that with a strange error in Zend / zend_stream.h or .c I don't remember exactly (if it bothers me, I can later check exactly which file and on which line it exploded). After some bewilderment, what is happening and why the ajeba is thundering in the Zend core – where it should not explode for any reason and a slightly longer study I find that this problem is relatively rare and there are not many signals for it. I suspect that one of the patches in the source is wrong but now I don't have the nerve to check it. Hmmmmm weird super weird. I almost decided to compile pure php but I decided to try the mirrors of dotdeb let's see what happens there. There, the compilation died due to some strange dependencies, but it overlooked the problems in the main part. Which is understandable, they didn't have them 30-40 patches that were in the stable package. After several long and unsuccessful attempts, I got tired and downloaded the vanilla package and compiled it with almost debian options with the idea to rewrite my current installation and by installing new packages from the feeder to be able to behave on a package installed from the repository. (probably another not very reasonable decision). As I expected without all the patches the installation went smoothly. This is the output of my config.nice file:
This is a configuration close to that of the dotdeb compilation. As a basic and most important is the prefix option where the files with the php libraries will be located. Adjust it as well as other times according to your system so that the compilation with change of ways is not felt.
Today I will write a light reading for php cache on html. Here we are talking about caching the output of our code and not as I wrote to cache scripts to opcode level with eAccelerator. So what are we talking about – let's quickly recall the work of php. We apply to web server-a he accepts the parameters that 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 queries, to skip large blocks or not so big blocks by directly drawing the already compiled output. The benefits are obvious – reduced execution time, less workload and resource consumption. In general, it is not the discovery of hot water, nor is it anything that complicated. There are many classes for this purpose such as PHP Pear Cache_Lite which has great functionality but I think in the future to write mine with a much lighter structure and my requirements for caching. We will now consider the most aboriginal variant 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 from which part of the code the caching starts. Then we generate the output of the code in a standard way. Then the generated output is joined to a variable that will be available later, whether through a file or through sessions, this is your decision.. Finally, we clear and stop caching. Quite a trivial operation if, say, cache generation goes through huge blocks of code so we can save a lot of CPU time by caching for a while or for a session. It's all about what you want, whether it's a public cache or a different user.