From around 2 weeks php 5.3 Enter the story slowly but surely. 11 announced the end of its maintenance and it will be played just security patches for 1 year. In General, PHP 5.4 passes in stages and old stable PHP 5.5 becomes stable, which is kind of fun because you still part of the additions and plugins of php do not work completely correctly but version 5.5 is quite new so I will refrain from migration to her.
So let's say for my migration to 5.4 by 5.3. Previously I had posted the information for obsolete features, those that have changed my entire personality and those who no longer has to maintain to have no dramas on both sides whether it is going to start or not 😉 So I chose this morning hour for start of migration around 7 as it became, that there is minimal pain during migration if you don't go smoothly. To my immense surprise everything went more smoothly – you have compiled PHP 5.4.17 I started apache and Oh heavens, it's all there. A quick glance through logs doesn't roar of depricated or unknown functions – Apparently, the boys have done their job well. Then I only have to prekompiliram and additions that are compiled with the old API as APC, RAR etc.. A second restart and all asleep. Separately, expect performance improvements because everywhere people pointing big toe the trays that shows how PHP 5.4 consumes less RAM and executes scripts faster.
A few days ago came out XAMPP 1.8.0 After upgrading from version 1.7.7 I had a pretty interesting problem. Phpmyadmin-not my opening and izg″rmâvaše with 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”.
Now I opened the httpd-conf xampp which to me ... is located in the/opt/lampp/etc/extra/, at first glance, everything seemed fine. The rules for the local network were fine. Apart from that I'd open the localhost. WTF ??? I looked at the log and see that my access is cut off by konfiguaciâta. Here things already ahnaha me and frankly kind of a little bit of luck I found problem. After going through httpd.conf-and saw in Allow / Deny clauses one last order Require all granted. Oh to Eureka. This is the new control mechanism which entered into apache 2.4.x. It gives access or refusing such all fine, basically imitated Allow/Deny functionality :). To fix the problem add Require all granted directives for the folder / opt / lampp / phpmyadmin. After the changes in me looks like this
<Directory “/opt / lampp / phpmyadmin”>
AllowOverride AuthConfig Limit
Allow from all
Require all granted
You can always try another divoti, for example, to rename the folder phpmyadmin something other and do not alias to. But it's ugly and not very meaningful 🙂
p. s Asked me why I use XAMPP and not clean installation of all components as it is my Debian was born – The answer is very simple – laziness. Lazy me to write a few commands then touched his konfovete etc.. Much easier is hitting the whole package and unzip you light 😉
The other day a friend of mine wrote to me that I had a problem with Debian -my server a. Its not exactly kept more than sessiite 30 No matter how many minutes to set up session.gc_maxlifetime. Basically the problem is that Debian have decided to re-write the conduct of sessions instead garbage collector-and start one cron every 9th and 39 minutes that cleans up old sessions. He is in/etc/cron.d/php5
overall, the sempličk script which in turn launches/usr/lib/php5/maxlifetime and variable how long is the life of the cookie that is 1440 seconds or 24 minutes from here on there is 😉 2 options or to stop the Crown and thus terminate the automatic cleaning which may later to realign the php. ini or directly in the script to change the life longevity of sessions with the variable max. I personally prefer the second option. Pretty neat is overall but there is a drawback – If you overwrite the file changes will be lost which is a troublesome fact.
ps. Now that I think about it probably if is defined somewhere else where to store the php info via seiinata should go beyond the scope of the script and thus to be used again in a normal session without interrupting rude.
Today I talk about the woes around a single server with Suhosin patch and how Debian Sqeeze deal with it. Now we start a little distance. When you install php in the Debian packaging system (stable for others I can not say how yet) you must install and suhosin mod to it. I had problems with some MAH-frame system written in php and took the cardinal decision instead to do debug the system and back Report Developer to lose security patches and thus save myself the trouble. Overall I can boldly say that this was one of the most stupid decisions I ever taken. At first remove module php5-suhosin restart web server-a and oops post – patch-a is still loaded. After a short study find, that the package is compiled and trots directly in the code which means that no exclusion or removal unless recompile the code again without patch. Solve that will drapna and recompile to deb package. Done sooner said do your apt-get source php5 pulling me this source code, razpaketirva and etc.. Here my ideal idea to remove the source of the package to remove the patch and compile it back to the Debian package plus one two small optimizations in compilation. said done – eliminate unnecessary patch of debian/patches/suhosin.patch I removed him from playing in debian/patches/series. So far everything clearly and without problems. Then run to compile package debuild and as I expected I blew compilation because of missing headers. Naturally there will be any shortages – I am still with debian netinstall. Quick fix stupidity run again compilation, at one point only faint again, that with a strange error in Zend / zend_stream.h or .c not remember exactly (if I can deal later to check exactly which file and the line thundered). After some doubting what is happening and why the hell can rumble of the Zend core – where it ought to rumble for any reason and a little longer study find that this problem is relatively rare and not many signs of it. I suspect that one of the patches in the source was wrong but I have no nerves to check it. Hmmmmm weird super weird. Almost I decided to compile pure php but I decided to try mirrors dotdeb there to see what happens. There compilation died because of some strange addictions but spared the problems in the main body. Which in turn is understandable they did them 30-40 patches which were in stable package. After several long and unsuccessful attempts I got tired and turned off my vanilla package and compile it with almost debian-ski options with the idea to rewrite my current system and install new packages from the feeder can behave package installed from the repository (probably another differentiated not a reasonable solution). As I expected without any patches installation went smoothly. This is the outcome of my config.nice file:
This configuration is similar to that of compilation dotdeb. As the most important-is the prefix option where you will have files with php libraries. It and other times correct according to your system so that you don't feel the compilation changing of roads.
Today we lit a light reading for php cache the html. Here we talk about caching the output of our code and not as I have written to cash out to the skritpovete opcode level with eAccelerator. So stuff – Let us remind ourselves of the quick work of the php-it. Submit the request web server-He accepts us a parameters which we submit it then submits them to the php script he compiles and spit out results in html version. It's in a fairly general lines. What is our idea here over requests, over large blocks or not so big blocks like a direct draw straws once compiled output. The advantages are obvious – namalâna times, less load and consumption of resources. As a whole is not opening the hot water or something who knows how complicated. There are multiple classes for this purpose, such as PHPPearCache_Lite which has a great functionality but I think in the future to write mine with more streamlined structure and my requirements for write caching. Now we will take a look at aborigenskiâ option with Output Control Functions. So let's cash out 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 me explain what happened. First we declare what part in the code starts caching. Then you generate a more standard way of exit code. Then the generated output joins variable that will be available later, whether in a file or during sessions, it's your decision. Finally, remove and disable caching. Quite a trivial operation if Let's say geenriraneto the cache goes through huge blocks of code so we can save a lot of CPU time as cash out for a while, or for a session. Now it's all about what you want whether to cache has been made available to the public or is accessible to different users.