I am looking to see what it takes to have multiple installs of php in osx 10.5.
I found this page that goes on to explain it for windows.
I was looking for confirmation from someone that knows better than me, if the steps are very similar for 10.5.
I am a novice user. Having only scripted with php, not actually building or installing it.
My web host runs a php older than I have installed. And I'd like to at least test locally on a version the same as my remote option.
Any help is appreciated. Thanks.
Is one of the servers running PHP 5 and the other PHP 4?
If so you can run PHP 5 in PHP 4 mode by enabling the following in your php.ini file:
zend.ze1_compatibility_mode = 1
If you can't edit the php.ini file then you can't change the local version for the script running by adding the following to your PHP script:
#ini_set('zend.ze1_compatibility_mode', 1);
You should find a tutorial for Linux or BSD, which would be a lot more helpful then a Windows-based one.
Some time ago I managed to do it on WIndows and wrote a quick how-to. While I don't believe it could be much relevant to OS X (except maybe for the part showing how to switch engine in .htaccess) I can give you some hint about the basic points:
Install as CGI, not as an Apache module;
ignore any instruction to put your php.ini in a common location or set up environment variables pointing to a single php.ini: what you definitely need is a separate php.ini for each PHP version, so you have to put them in the respective PHP folder to be found;
when testing check with phpinfo() which php.ini is actually being loaded.
Just for sake of completeness I'd add that at the time of writing (2007) both PHP4 and PHP5 were happy to run with each other's php.ini - until I started loading extensions: those are compiled for their PHP version only and go into a spin if used with the wrong PHP.
Hope I've been helpful.
Related
So I have a Portable Webserver program called USBWebserver,
because the original program still uses php 5.3 (I believe) I went on an adventure to upgrade it so that not only me but the rest of my class can use it.
I upgraded the Apache server build to 2.4.27
I upgraded the PHP binary to 7.1.9
The thing is... Everything functions but one thing:
For some reason MBString (Yes, just MBString) will not start up with a variable path anymore. If I set a manual path it functions it just no longer does this with a variable one.
Before people say:"Then why don't you just make it a manual path and be done with it." because it needs to stay portable and usable "out of the box" so to say.
I am quite stuck on how to fix this issue. If any info is needed, please ask and I will edit this post with the info. (Like if you need php.ini)
After a lot more messing about with it I finally found out what fixed this issue. I'll post it here so that others who might try to do this won't have this hurdle to combat.
extension_dir's path at first was "php\ext" as php.exe wasn't liking that I changed it to ext, which php.exe liked but apache...not so much.
After a long while I changed the path to extension_dir = ".\php\ext" and as if the gate of heaven opened... it functioned. Fully and completely without even one error.
So now I have a modified USBWebserver running:
PHP 7.1.9
Apache 2.4.27
PHPMyAdmin 4.0.4.2
MySQL 5.6.13
Fully portable, fully fuctional. I hope this little tid bit of info helps someone else some day and if some people want the program, ask and I will make a download link and edit it into my original post any this answer.
Have you been updating usbwebserver to newer version?
It seems that the officiel development has stopped.
I have tried to update php to version 8, but then the apache server won't start, and there is noting in the log file - its just empty.
Thanks
Jorgensen
I'm having what to me is a weird problem, and I'm wondering if you can help me figure out the shamefully obvious mistake I'm making.
I have a javascript app that runs a bunch of php scripts via ajax, all running locally on my Mac, using the built-in apache server. It's been working for years, but on my new Lion Mac, the php scripts no longer return the files they're supposed to be reading. They return the php script itself.
The php scripts work fine if I run them from the command line. They work fine if I run them directly from the command line. They work fine run from Ajax on a Snow Leopard computer. They do not work if Ajax runs them on my Lion Mac.
Things I have tried :
I have adjusted httpd.conf so that the php module loads, and I have restarted my Mac.
Apache is definitely running: 127.0.0.1/~myname/ gets the "it works" msg.
I have tried running the ajax using jquery and using the old-fashioned longhand ways. Same problem. (I have made sure that jquery is in fact loading.)
I am not using the short code "<?" in my php scripts
The php file is in the same directory as the html and javascript files. The permissions are the same as the permissions on the Snow Leopard computer where it all works fine
I've tried googling for this up and down, but I'm stumped. Any suggestions? Thanks!
The problem seems to have been that php 5.3.1 was installed on my Lion machine. When I updated to php5.4, it began working again.
To update to php5.4, I followed the instructions here: http://php-osx.liip.ch/ Thanks for your help, Stackoverflow!
Is php enabled and configured properly?
Edit your /etc/apache2/httpd.conf and make sure the line: LoadModule php5_module libexec/apache2/libphp5.so exists, then re-start Apache: sudo apachectl restart
Is the correct/expected php.ini being loaded?
On Lion-upgrade the php.ini file will be renamed to /etc/php.ini-5.2-previous and a new sample PHP configuration file, /etc/php.ini.default is put in place!!!
Hence you probably might want to reconfig your php.ini file.
Extensions previously installed under /usr/lib/php/extensions/.../ had been removed.
So, if you have extensions that you wish to still use with 5.3, they will need to be re-built.
Can you now load a phpinfo.php file containing <?php phpinfo();?>.
Now check the phpinfo for the mySQL directives (and other locals) if you use it.
Apple has included the Suhosin patch and extension.
Suhosin is part of the Hardened-PHP project which aims to protect PHP applications against buffer-overflow and format string vulnerabilities. Compare Suhosin's feature-list to your php-scripts.
Might there be deprecated php statements being used (that worked in a older version of php)?
Does it work now?
My Xdebug works fine when I use eclipses' internal browser but when I use it in an external browser apache crashes.
I am using xampp and on windows 7 64 bit. If someone needs more information let me know.
For some reason if I have the variables tab open in the php debugger in eclipse it crashes apache. So to stop it I just can't have variables tab open while debugging. So this avoids the problem but doesn't fix it. I would like to be able to have this tab. Any suggestions?
It is possible that the XDebug build and type does not match your apache & php build and type...
Apache compiled with VS.NET 2008 (VC9) for 32bit and using PHP as a module would require XDebug: 32bit, VC9, Thread Safe.
http://xdebug.org/download.php
Also, you could test another WAMP package that comes with XDebug (for example WampDeveloper) and if it also does not work for you, it's probably not a build mismatch issue.
Hey I got this working
Eclipse 3.6.1 (because on later versions key shortcut for putting line comment don't work)
Xampp 1.7.4
Xdebug 2.1.2
The trick is to change php from VC6 to VC9 and then it just works correctly.
BTW. It's the variables panel that causes xdebug to crash apache on php VC6.
Remember to get VC9 version of xdebug for new php AND if you put your new php in directory other than
\xampp\php, then on phpinfo(); you'll see that there's no php.ini loaded so just rename old php (co you can swich them from one to other anytime) and put new php in the same directory in which original php was in "\xampp\php" and copy your php.ini (because paths doesn't change). Also remember to obtain any additional php extensions you've been using in VC9 version for new php and put them in "\xampp\php\ext"
I can confirm most of what t0meck said. Except I've moved up to xampp-win32-1.7.7-VC9 which has PHP 5.38. Taking the phpinfo() results from that to Xdebug's custom installation analyzer, it specifies the php_xdebug-2.1.2-5.3-vc9.dll, but the problem isn't entirely eliminated. As I've documented in my 'notes to self' page, the following is working for me.
After following the above procedure, the 'run as' should work on the first try, but the 'debug as' may crash Apache at every attempt. This is an issue that has driven many people to severe distraction. There is an apparent bug exposed using the debug perspective. At the top center of the perspective is a window with two tabs, the variable view and the breakpoint view. Usually, Apache crashes only when the variable view is highlighted, so highlight the breakpoint view instead. Then set a breakpoint on your project. Now, if you are one of the chosen, you will be able to step through the script using the debugger, but when you switch to the variable view it may still crash Apache. What a drag. Repeat the process and the next time you should actually see the variables and the problem will magically go away, until you restart the project. Just repeat the procedure and be satisfied with being one of the lucky ones.
Don't know if this help, I have same kind of issue, but it relate to array depth xdebug >handle in Variables view. And you can change it. Widnow > Preferences > PHP > Debug > >Installed Debug > Xdebug > Configure enlarge the "Max array depth" solved my issue.
http://bugs.xdebug.org/view.php?id=658#c1767
Just set it to 10 or bigger and it should work
I've set up my own Apache server; with MySQL, PHP and PHPMyadmin.
It used to work previously when I did it before on various computers; but that was the older versions I dealt with, not the latest. However, it's been a while since I've updated my PHP version, so that's why I'm asking this.
What configuration changes do I need to make to get 5.36 to work properly with Apache?
Currently any .htm files can display properly in http://localhost, but no .php ones.
All I see is a text file, so what's gone wrong with this?
The server is not public - in fact, it's on a Windows Vista Home Edition install, and it's a development one. I don't need to worry about anything else just yet, as this is a totally new install.
What config changes do I need to make?
I tried:
# mod_php5
Include conf/extra/suite-php5.conf
but that didn't work, so what's the solution with PHP 5.36?
Should I re-enable the above line (it's currently commented out with the # symbol).
So far the server works; but it's not serving up PHP pages, which is strange.
Anyone got any ideas why? I would gladly appreciate your help!
Won't post the httpd.conf since it's being developed right now though.
No more VC6 versions of PHP 5.3.x?
From the release announcement:
Windows users: please mind that we do no longer provide builds
created with Visual Studio C++ 6. It
is impossible to maintain a high
quality and safe build of PHP for
Windows using this unmaintained
compiler.
For Apache SAPIs (php5_apache2_2.dll), be sure that you
use a Visual Studio C++ 9 version of
Apache. We recommend the PHP builds as
provided by ApacheLounge. For any
other SAPI (CLI, FastCGI via mod_fcgi,
FastCGI with IIS or other FastCGI
capable server), everything works as
before. Third party extension
providers must rebuild their
extensions to make them compatible and
loadable with the Visual Studio C++9
builds that we no longer provide.
Check your config files for http and php. I haven't done this in a while, but you need to add the file type .php to list of files types that you want Apache to serve. READ the config file carefully.
Also, inside your http config file there should be some additional lines that tell Apache where to find php, vis-a-vis the php.ini file. You need to set up your path information inside the config file and in the environment/system variables section of your Microsoft OS.
I recently installed Windows 7 on my desktop and the following problem has begun occuring:
I regularly run some PHP scripts from the commandline that are now giving this error in a popup window:
CLI has stopped working.
I cancel this and my script terminates. Not good...
I've googled around and tried most of the few ideas suggested but still i am plagued by this annoyance. Right now it appears to regularly occur when I do a file_get_contents() of a url pointing to an image file. Only happens when the url is http protocol, works fine for ftp files. It also happens spuriously doing other things as well.
This is PHP 5.3.0 as distributed in a xampp 1.7.2 .zip. All exe's and dll's have been unblocked by copying thru FAT32 and back.
hints from anyone who's cracked this would be most helpful.
Try updating your PHP version bundled with xampp. You might have to update some php_XXX.dll extension files.
More info: http://web2.0entrepreneur.com/31/cli-has-stopped-working-on-windows-vista.html
PHP-CLI stops under these circumstances: Windows 7 64bit, PHP 5.6.8 64bit, only when Zend OpCache extension is ENABLED!!!
Just edit php.ini and comment zend_extension=php_opcache.dll (with ; in front of it)
I found that this happened to me when I had the APC extension enabled. I switched to using the Wincache for PHP extension instead.
If you receive this error after installing WAMP, most likely you have another installation of PHP on your machine. This may have been installed using the Microsoft Web Platform Installer or by other means. The first thing you should do is un-install PHP.
If this doesn't work, check to make sure that IIS and Apache are not trying to use the same port. WAMP starts out with Port 80 as standard and IIS usually will be the same. The easiest way to fix this is to turn off IIS while running WAMP, but you can set either of them servers to port 81 or another port.
If this doesn't work, my last suggest is to look for multiple copies of php.ini on your machine. You may find them in places like the Windows directory. Make a backup of the file just in case, and then remove them from all of the folders except the WAMP folder.
it happened to me in laravel 5.I searched every where but no solution that fix my problem then i debug my web application at different points and found that if you comment your php code in laravel comments in blade template like
{{--print_r($date_a);--}}
Now comment like this
//print_r($date_a);
works
The solution for me was to stop using PHP 5.3.0 and go back to 5.2.11. Once I did this the "CLI has stopped working" issue disappeared.
I have the same issue with Windows 7 Professional.
My Apache Server has no problem finding and executing PHP within my web application but the command line execution gives the infamous message "CLI has stopped working."
The User Account Settings seem to allow executions.
Perl has no problem.
I always have to take my code to an XP machine and run it there to debug it.
You didn't specify that you were using xdebug, but just in case you were, I may be able to help. I had this error for a long time. It turned out I was on a slightly older version of Xdebug (php_xdebug-2.2.0-5.4-vc9.dll).
I replaced that file with "php_xdebug-2.2.2-5.4-vc9.dll" and it magically started working immediately.
I'm on wamp, and I updated both php.ini files (one is for cli, one for normal use) with the latest filename.
"zend_extension = c:\wamp\bin\php\php5.4.3\ext\php_xdebug-2.2.2-5.4-vc9.dll"
Then dropped the new file into the php ext folder and instant success.
I had the same issue on Windows 7 (Home premium). I had a hunch that it is caused by one of the extensions I installed so I started commenting them out one-by-one.
Turned out it was caused by a non-compatible mongodb extension I was using
Edit php.ini and comment zend_extension=opcache.enable_cli=1 (with ; in front of it)
Try to use another php version instead.
It works perfectly for me.
Try to run scripts with php-cgi.exe instead of php.exe. For me it works.