I am trying to update the PHP version of my development environment from PHP 5.3 to either PHP 5.6 or 7.0.
I have used Meld to compare the php.ini files and the php_mysqli.dll file is uncommented on all three versions as is php_mysql.dll on both of the versions that support it.
Running <?php print_r(get_loaded_extensions()); lists both extensions as loaded in PHP 5.3 but doesn’t list either as loaded in the other versions. PDO does show as loaded on all versions but undortunately I am not using that interface.
I have been renaming the php folders to determine which should be used and then restarting Apache. It does show the correct version of PHP is running when I check the version after restarting.
Does anyone have any ideas on what step I have missed in setting up the newer versions?
Ah, I remember the days of having .dll or other issues similar to this and also wondering why things weren’t working right with my Windows dev environment. Now that I use Virtualbox with Vagrant, those days are gone. And, I can also easily test or use all kinds of different environments fairly quickly too and destroy them with two clicks of a mouse button (or typing in “vagrant box remove”) and not have a mess on my Windows host machine. (Yes, that is an indirect suggestion. LOL!)
In two completely different versions of PHP downloaded at completely different times - seems extremely unlikely.
I looked into Vagrant already and decided not to switch to that at the moment. What’s the point in running Windows if I am going to run almost everything inside of virtualbox?
Not quite sure why but I tried renaming the PHP 5.6 version of the file and copying one of the other two versions in its place and got a different error message and then when I swapped it back it worked.
So now I have successfully upgraded from PHP 5.3 to PHP 5.6.
So next step is to go through everything and fix anything that now shows as an error before switching again to PHP 7.
How I got mine to work was just do a clean installation of PHP 7. If you’re doing this locally, you’ll need to do a lot of stuff. I’m not sure if I can tell you the precise ways I did it, but I’ll do my best.
Download process
Go to apachelounge and download the Apache package for Apache 2.4.18.
Look for what ever module you want to enable and enable it.
Modify the DocumentRoot and Directory location if you want it to be in a different location.
Add index.php before index.html in between <IfModule dir_module>.
At the end of httpd.conf, add in
PHPIniDir /::PHP_DIR::/
You are now done with httpd.conf file.
Navigate to your PHP folder, rename either php.ini-development or php.ini-production to php.ini.
Go back to your favorite IDE editor and open up php.ini.
In PHP 7, all extensions are commented out so you’ll need to uncomment the important ones like php_mbstring.dll, php_mysql.dll, php_pdo_mysql.dll, .etc.
You are now done with php.ini file.
Open up command prompt as an administrator.
Change the directory to your Apache 2.4 bin folder.
When you’re in the bin folder, type in this command.
httpd -k install
If Apache 2.4 doesn’t want to install or it’s complaining about something. Type in
httpd
to see what the problem is. Most likely, it’ll complain about missing files or files that cannot be executed.
You’ll need to download PHP 5.3 - 5.6 again. You only need to do this because the files libeay32.dll, libssh2.dll, and ssleay32.dll in the Apache 2.4 bin folder for PHP 7 has something wrong with it. You’ll need to replace those 3 files using the files in PHP 5.3 - 5.6 folder. You’ll most likely see these files where the php.ini file is located in.
Try uninstalling and reinstall Apache 2.4. if it gets any errors. You’ll need to correct them.
Change /::PHP_DIR::/ to your actual PHP folder.
I’m not sure how accurate this will be since I have already install PHP 7. I can install a new Windows OS on my separate hard-drive to test it for you if you want and I’ll most likely record everything I do.
I am planning on just updating the XAMPP installation that I already have (which I last updated in 2013).
So far today I finally got mysql updated from 5.5 to 5.7, PHP updated from 5.3 to 5.6 and phpMyAdmin updated to the latest version.
Now that I solved the not seeing certain extension problems in PHP 5.6 I am sure I will be able to do the same for PHP 7 (once I make sure there are no more warning messages being generated due to the 5.6 upgrade).
I see. I remember seeing that they have PHP 7 for XAMPP, but I didn’t know you have to do a full upgrade and not just skip a version to the latest. Maybe this could cause errors?
I never understood XAMPP, I don’t like the one size fits all, with that said.
Recently installed win 8.1
I have always downloaded the windows version of Apache, mySQL and in this case php7 (both 64 and to test 32).
the 64 bit php7 was called > php-7.0.0-nts-Win32-VC14-x64.zip
Just extracted the contents to C: drive as php7, no install needed.
Edited httpd.conf to point to ScriptAlias /php/ “C:/php7/” and added
<Directory "C:/php7">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
I really don’t think the second part is necessary, not sure but had it in the old httpd.conf for php5.5.6 .
Install went smoothly and has that new php smell.
MariaDB is an easy install by itself.
Try skip the XAMPP and install each one seperately.
My ony gotcha was that I didnt download for Visual C++ Redistributable for Visual Studio 2015
This tutorial was what I needed.
From the article:
Remember my gripe about not being told I needed the C++ distributable. Well [cough] [ahem]… If I actually took the time to read the sidebar on the download site, I’d’ve noticed this:
DOH!
all I have to do to change php versions is change ScriptAlias /php/ “C:/php7/” to php7-x86 or php5.5.6
I haven’t seen PHP 7 for XAMPP yet - that’s why I am planning in just replacing the version of PHP rather than doing a whole new install.
Already today I have updated XAMPP 1.7.1 that I downloaded back in 2013 so that it is now running PHP 5.6.16, mySQL 5.7.9 and phpMyAdmin 4.5.3.1 - so it certainly isn’t one size fits all since XAMPP don’t have a version with that combination (particularly now that they include mariaDB and I wanted to stick with mySQL).
Once I get the php.ini for PHP7 right then all I will need to do to switch versions is to rename a couple of folders and change a couple of lines in the httpd.xampp.conf file (unless it plays up again with refusing to recognise the mysqli extension as it did with 5.6.16)
That option wasn’t there the last time I looked - which was admittedly a couple of weeks ago. Anyway, if I were to install that now I’d be swapping back to an earlier version of phpMyAdmin and changing to a different database (that is also probably an older version seeing as I just upgraded to the very latest version on mySQL).
I have actually found it easier to simply replace the component parts of XAMPP with newer versions than upgrading to an entirely new version of XAMPP. It is certainly easier to revert the individual components back if there are any issues than having to revert back the whole of XAMPP at once…
Having cleaned up the couple of warning messages that appeared when I upgraded to PHP 5.6 I have now successfully updated to PHP 7 - still not sure why the mysqli.dll refused to work initially (in 5.6 and 7) but it is working fine now.
That’s good to hear. Yeah, I guess I agree with replacing a few files instead of replacing an entire software.
I still have the old version of XAMPP which I’ll most likely switch sooner or later. As of right now, I’m thinking about replacing the version I have with a manual installation of PHP 7.
One major advantage of a vm is you’re not hosing the existing environment. For example, in upgrading individual applications to be compatible with newer version of php it would be nice to compare and contrast locally. Using a vm you could have done that leaving all you’re existing projects functional instead of potentially hosing them. This is especially true for extensions that might be dependencies of existing projects but are not installed by default. Also any php.ini tuning which you might have overlooked. There are several advantages to maintaining the existing environment. I can’t speak for you but I work simultaneously only projects which require different be Simons of php and dependencies. I always find it bad form to hose environments because you never k ow when a critical issue might occur with any one project and the last thing you want to do is spend time downgrading or setting up an environment that previously worked fine.
I know we’ve talked about using VMs instead of installing the PHP environment on your actual OS, but with my experience using VM, the VM lags way way too much. So when I attempt to install a VM, I normally have to shut it off constantly and reboot it. I read somewhere that you can reduce the lag, but the lag is unbearable for me.
I can’t just shut off a VM every 2 minutes to fix the lag. I’ll be wasting more than 3 hours fixing a lag rather than trying to develop for those 3 hours.
So that’s my beef with VMs. I don’t mind using them, but they just lag way too hard.
That’s what I have.
I used XAMPP for a long time, Easy because I didn’t need to know any sysadmin stuff.
But I didn’t like being limited to what versions came in a package.
So I bit the bullet and did manual installs of the components.
I needed to edit some system PATH variables and conf and ini files etc. but it wasn’t too much trouble and the solutions to the problems I encountered were easily found by searching online.
I also have Vagrant installed. I’ve run into quite a few problems with it. Mostly due to Windows Security limitations and problems with SSH to GitHub.
It’s not so easy to find solutions online because of all the possible environments - OS, OS version, dependencies etc.
BUT once working correctly it’s great (I still feel that any success I’ve had with it is due more to luck than having any deep understanding of what I did). A lot more flexible because you can “spin up” different “boxes” that are configured as desired.
IMHO trying Vagrant is well worth the effort if you aren’t easily discouraged
You need to be using the most optimal file sync for your host machine. I hate xamp. It only solves one problem - installing php. It does not solve all the other problems that are typically involved in setting up a complete local environment such as installing extensions and front end workflow tools. For example try to install the oauth extension on xamp vs. a Linux vm. There is no comparison in ease on a true Linux environment vs xamp. Try installing ruby or a search engine. It’s all hell on earth on Windows. I won’t stop people from using xamp but I’m also not going to help them in dealing with all other issues that come along the way that could have been avoided using a a vagrant and puphpet set-up. I think it’s really stubborn not to be using that set-up or a container service. Though I’m not really a fan of the whole contact thing for local environments either unless someone with a lot of dev ops knowledge is responsible for maintaining the container.
Not always - sometimes you need your development environment to be ahead of the live environment so as to test that the code will work with a new version before you upgrade the live environment. In my case I now have my development environment well ahead of my live environment so I can test that the code will still work when the live environment gets upgraded.
As I said before regarding vagrant - why would I bother having windows at all if everything I am doing was going to be running in a vm? All of my projects all run on the same live hosting so when I upgrade the dev environment they all need to work there before I can do the equivalent live upgrade.
Using vms would be appropriate if the projects were running on different live hosting platforms but in my case they are not and so loading the various components separately onto my computer makes a lot more sense to me - it just happens that the last upgrade I did updated everything at once via an XAMPP install and so the simplest solution was to replace the individual components in that rather than start over.
Effectively I have just installed PHP, mySQL and phpMyAdmin separately (latest production version in each case) while keeping the other components from when I last installed everything (which at that time was via XAMPP as at that time I couldn’t be bothered with downloading everything separately (as I had done on at least one previous occasion).
The biggest issue I had in doing the separate installs was that the mysqli.dll files refused to work properly when I first tried running PHP 5.6 and PHP 7 (which is why I decided to try 5.6 in the first place rather than trying to upgrade directly from 5.3 to 7).
Yeah, manual installation is a good thing I guess. For me, it helps me understand what I am installing and where I’m installing it to. It also helps me understand how you are supposed to install the environment.
The only reason why I use XAMPP as I have said in other topics is because when I’m not at home and somewhere else, I would like to bring my work with me. And since I’m using other people’s properties, I don’t want to install something on other people’s PCs if I don’t have the permissions to do so. So I usually use the portable XAMPP on my USB stick. That way, I don’t need to install the PHP environment on people’s PC and make them angry. Plus, at school if I install something, it gets deleted the next day because they don’t want other stuff that they didn’t install.
Although PHP is supposed to be platform independent, as you can see, there are differences when using PHP between Windows and Linux.
Are the live systems you are developing for on Windows servers too? Is your Windows environment exactly the same as the server’s? If the answer to either question is “no”, then you now know why it is better to use a VM.
