I've been learning up on PHP, and a lot of the time in the books and tutorials I read, features come up as having been introduced in PHP 5. I don't know anything about PHP history, so I don't know if I can safely use these features on most servers. I know in Python, adoption of new versions is very slow (few apps use 3.x, most desktops have 2.6, many server distros like Red Hat have versions as early as 2.4).
Is there a similar situation in the PHP ecosystem? My server has version 5.2, but are some servers still running PHP 4? What version of PHP can I safely assume a server would run?
PHP 5 was released in 2004, and PHP 4 reached End of Life at the end of 2007. You can safely assume that the server has at least 5.0.
PHP 5.3 was released in 2009, but there are still major pieces of software that have not fully taken into account everything that was changed in it; additionally, there are still distributions within their mainstream support cycles (like fairly recent versions of Ubuntu and Debian) that do not have it by default.
However, assuming PHP 5.2 is definitely safe.
At this point you should expect if not demand PHP 5.2.x. If your host doesnt have that, switch hosts - they dont deserve your money. PHP 5.3 on the other hand is a different story... not all shared hosts offer that yet so youll want to check it before deploying or setting up an account if thats the version youre targeting.
I wouldn't assume minimum versions of any software installed anywhere. I'm sure there are people still running PHP4 in 2010. Having said that, I also wouldn't be developing any new software targeted at PHP4 in 2010. PHP 5.2 is probably a good, practical choice at this point in time.
Distrowatch can be a useful resource for this type of question. Here's an example: It appears that RedHat went to PHP 5 in RHEL 5.5, which came out in March. That's not actually so long ago; it wouldn't surprise me if some enterprise users haven't upgraded (I work at a large university and we have many production servers running RHEL 4).
Nonetheless, if we were going to run a PHP app on one of those servers, it's a safe bet that we would update PHP. I'd use 5.2 and just document the requirement.
So, we've got some current data after all:
http://phpadvent.org/2010/usage-statistics-by-ilia-alshanetsky
PHP version | usage at the end of 2010
---------------+----------------------------
4.4 | 6%
4.4 | 16%
5.1 | 8%
5.2 | 66%
5.3 | 4%
And a more recent analyzation (says June 2011)
http://w3techs.com/technologies/details/pl-php/5.3/all
5.3 | 8.6% (from 6.6%/0.764)
Most web hosting providers are using PHP5. Some of them still provide both use of PHP 4 & 5 on a hosting account. In any case keep on with development in PHP5.
Related
I am developing a Laravel 9.x app in Windows 10. My current version of PHP is PHP 8.1.5 (cli) (built: Apr 12 2022 17:38:57) (ZTS Visual C++ 2019 x64). Is this a thread-safe or not-thread-safe version? How can I tell? When should I prefer a thread-safe over a not-thread-safe version?
I've tried researching this issue here on StackOverflow but the questions/answers I see all seem to be a decade or more old - like this - and I strongly suspect that I might get a different answer if I asked the question today simply because the technology has changed in the intervening years. Is that a reasonable assumption? (At the very least, my current version of PHP evidently uses a newer compiler, VC++ 2019, rather than VC6 or VC9.)
I have no idea yet what my production environment is going to be or even IF the app I'm developing will ever go to a production environment since it's just an app I'm writing to (re-)learn Laravel. I may put it in production as a demonstration of a working Laravel app when the time comes but whether it will be on a hosting service or Netlify or something else, I just don't know at this point.
Just to give you some context, this issue only came up because I am trying to learn how to step through my Laravel source code to debug problems and this apparently requires me to add XDebug to XAMPP. The instructions I found for installing XDebug point me to here and recommend that I download the Windows binaries for my version of PHP. There are no binaries of 8.1.5 so I don't know if one of the binaries for 8.1 would work or if I'd be better to use 8.1 thread-safe or 8.1 not-thread-safe. If it would be better to upgrade my PHP first to 8.2, I still don't know if thread-safe or not-thread-safe is a better choice.
Can someone enlighten me on these matters?
Is this a thread-safe or not-thread-safe version? How can I tell?
You can use the good old phpinfo() function and lookup for the Thread Safety column.
If you have your PHP setup in PATH environment, you can even get it via CLI using a quick command php -i | grep Thread
When should I prefer a thread-safe over a not-thread-safe version?
As per PHP official documentation
If you choose to run PHP as a CGI binary, then you won't need thread safety, because the binary is invoked at each request. For multithreaded webservers, such as IIS5 and IIS6, you should use the threaded version of PHP.
I have no idea yet what my production environment is going to be ...
Generally, there is no difference on TS or NTS code execution. It's more towards the webserver.
If I am not mistaken, by default, XAMPP uses Apache Handler, so it will likely be a thread safe build. And yes, the Xdebug binary for PHP8.1 will just work fine.
Technically, NTS should be slightly faster because it doesn't need to cater for thread safety.
Personally, I think it doesn't matter, unless you want to spend slightly more time to tinker around the webserver switching to FastCGI or PHP-FPM, since you are still in development phase, I think stick to the default setup and focusing on getting it up is more efficient.
According to the PHP documentation on unsupported branches
using [unsupported branches of PHP] may expose you to security vulnerabilities and bugs that have been fixed in more recent versions of PHP.
Debian 11, the current stable release, comes with PHP 7.4. which according to the PHP documentation on supported versions ceased being actively supported 6 months ago and will only be supported for security for another 5 months. I assume this means that in 5 months time, which seems like a short time in the life of a production web server, PHP 7.4 will be considered as unsupported by the official PHP organization.
What should I do in order to set up a Debian server for a secure production PHP website?
My current best idea is to set up Apache on Debian 11 and import an 'unofficial' repository from Ondřej Surý who seems to have a good reputation for producing reliable PHP packages. Then I should be able to install PHP 8 from his repository.
Another idea would be to use PHP 7.4 with Debian 11 now and upgrade to Debian 12 assuming it ships with PHP 8. That would presumably be the safest approach theoretically but in practice sounds like a lot of admin with scope for a lot of problems.
I have seen quite a lot of advice which strongly urges users not to install software from repositories that do not ship with the distro. This wiki from Debian is an example.
Are there more sensible alternatives? If so what are they? If not which of my ideas should I pursue?
I have a commercial membership site php program on the server, but after the server upgrade it no longer works. The provider has ceased to operate so there is no support. I am using php 7.0.15, but the server wants me to upgrade to a more recent version, 7.4. This breaks the program /all I get is a blank screen)
My level of PHP does not allow me to debug such a complicated program. My question is:
is there any way of instructing php to only use the older version? I imagine that this would have to be done in the php.ini file on the server?
I would like to upgrade to php 7.4 on the server, but have this software run in php 7.0.
Is this possible?
The simple answer is No - PHP does not offer any options to emulate the behaviour of previous versions.
Partly because features are sometimes removed because they prevented changes in the engine, or would need a lot of work to operate with them; partly just because there is only a limited amount of resources available to work on the core of PHP, and maintaining multiple versions of each feature to enable such compatibility would take effort away from improving the current version.
Your short-term option is to find a way to run an actual copy of PHP 7.0 on the server, or a different server that will allow you to run it. You may need to pay someone who provides unofficial long-term support for old versions, since the last official security patch for that version was over 3 years ago. Even PHP 7.4 will only receive official security patches until the end of this year.
In the long term, your only options are to hire someone to update the application to run on a modern version of PHP, or to migrate to a different application which still has a vendor supporting it.
I have a Joomla 1.5.10 based Intranet system. In this application, we have more than 80% custom extensions. Below is the configuration:
Apache version : Apache/2.2.22 (Win32) mod_ssl/2.2.22 OpenSSL/0.9.8
PHP version : 5.3.13
MySQL version : mysqlnd 5.1.11
It has 3 dedicated Appliocation Server which configuration is :
Windows Server 2008 Standard Edition Service Pack 2
Compiler: MSVC9 (Visual C++ 2008)
Architecture: x86
Again, it has dedicated DB server which configuration is :
8x Intel(R) Xeon(R) CPU X5460 #3.16GHz, 8.0GB RAM, Windows Server 2008 Standard Edition Service Pack 2.
Below is the MySQL settings in my system:
Sl.# Parameter Value
1 Key Buffer 547M
2 Sort Buffer Size 256K
3 Query cache limit 4M
4 Cache size 350M
5 Long query time 5
6 Interactive timeout 300
7 Max Connection 800
8 Thread cache size 36
We have configured WAMPSERVER (32 BITS & PHP 5.3) 2.2E on our servers and then install MySQL5.1 on other dedicated server. Hence, we are not using MySQL provided with WAMP.
My system become too slow or crash when number of DB connection threads crossed 100. Number of logged-in users we can see are 3000-5000 only. Multiple queries start logging in the slow query logs and huge number of queries are in sleep state. Those queries which are running normal also start logging in slow query log and taking much time in execution.
I am unable to find the bottlenecks in my system. Is there Joomla or MySQL creating bottlenecks. Would upgrade helpful to avoid the bottlenecks and increased the performance of our system? If yes, what should we upgrade - Joomla or MySQL and what will be the strategy to upgrade the system. Is there a known performance/scalability issue in 1.5.10 that is resolved by an upgrade?
My overall goal is to increase the system performance.
Thanks in advance.
First of all as mentioned in my comments, upgrading your CMS to atleast Joomla 1.5.26 will help. You're running PHP 5.3 and only Joomla 1.5.15+ is fully compatible with this PHP version. Seeing as you're using 1.5.10, there will be some issues there.
Apache is not an issue here. There are sites out there running Joomla that have thousands of users and run Aache without any problems, so not to worry about this.
From Joomla 1.6 onwards, the optimization started. Reduced and sorted database tables, endless bug fixes and also security issues. The framework has also improved majorly not to mention it supports PDO, mysqli (more secure than mysql) and postgre. Ugrading to Joomla 3.2 (latest version) will be of course a massive step. You will have to make all your custom extensions compatible with the new Joomla version and keep up to date with the latest coding standards. Even though this is a big step and will of course take some time, it's fully worth it. Joomla 1.5 hasn't been supported for a long time now and things are moving forward majorly.
Your server specs are good, you're running a decent PHP and Apache version, you're MySQL version could be upgraded however it's still not bad. So overall, it's not a server related issue.
I do think that it could very well be the way your custom extensions have been coded. So my final suggest would simply be taking a backup of your site and start migrating it and all of your extensions to Joomla 3.2.
You can change the webserver. Apache is totally bloat. Lighttpd can help to fix the problem. It' also simpler to run. A cms upgrade most likely break something.
I'm trying to figure something out:
I am using Ubuntu server 11.10 virtualized on Win7 (I don't think that matters but more info is better than less) to work on a Drupal 6 website I inherited and need to make significant changes to.
I want to set up a development copy of this Drupal website on my Ubuntu server so I can work without worrying about torching the production website.
I successfully got the production files downloaded and onto my machine, I got the production MySQL database exported and imported into the dev MySQL server, and I set up a symbolic link from the directory /home/myname/thewebsite.com to /var/www/thewebsite.com so I can easily access it.
When I got the website they didn't know the admin password so I dug around online and reset it in the dev db using phpmyadmin and finally log in.
When logging in and poking around the site there are lots of errors, which when googled lead me to believe that PHP 5.3 is causing them and that there are some modules in use that only work with PHP 5.2
After looking around a lot online and on stackoverflow there seems to be no easy way to install PHP 5.2 on Ubuntu Server 11.10. With no packages for 5.2 available through apt-get or aptitude what should/can I do?
1) Install 5.2 from source - how do I get it to interface with MySQL and Apache2? Also, I've never installed anything significant from source. Is there a walkthrough?
2) Replace the repositories with old ones? Will this work on 11.10? The newest instructions I found were for 10.04
3) Use already built PHP 5.2 packages for Ubuntu? Couldn't find these
4) Pay someone who knows more to do it for me? (Just kidding, this isn't really an option...)
Cheers and thanks for your help!
PHP dropped support for 5.2 in August 2011; operating system providers such as Ubuntu will not supply a version that is out of support, so you absolutely won't get an official copy of PHP 5.2 on the current version of Ubuntu (or any other OS).
If you're running an older version of Ubuntu (eg 10.04), you might be able to do it; it would still be a downgrade, because PHP 5.3 has been the default version for quite a long time now.
If you're on a newer version of Ubuntu, ie 11.10 as you state, it is going to be a problem for you.
The Drupal developers dropped the ball badly on this one. I guess it was because Drupal 7 tool so long to finish; they were expecting D7 to be out much sooner, and so they never bothered fixing up D6 to work with PHP5.3. As it turned out, this was a big mistake, because in fact D7 still wasn't officially released when PHP dropped support for 5.2.
But even so, they should have fixed it, because they're still officially supporting Drupal 6, so they need it to work with the current version of PHP. This is definitely Drupal's problem, not PHP's, Ubuntu's or yours.
But you still need to deal with it.
I found this question over on AskUbuntu.com, which gives an answer applicable to 11.04. It isn't quite 11.10 you were asking for, but it it a lot more recent than the best you'd found, so it might be helpful.
Alternatively, you could research exactly what it is about Drupal6 and your specific modules that doesn't work in PHP5.3. The language differences between 5.2 and 5.3 that can break things are not big, so I would expect any code changes required to be fairly small. You might find you can fix the code yourself. And maybe even submit the changes to the community -- Drupal is open source, after all.
Another tack you could take is to consider whether this saga represents an opportunity for you to move the site to Drupal 7?
This may or may not be feasible, depending on the modules you're using, etc, but if it is possible, it will solve the problem, because D7 is of course fully compatible with PHP5.3.
And just to cheer you up, I'll close by mentioning that PHP are on the verge of releasing PHP 5.4. Hopefully the Drupal devs will be more on the ball this time.