This question already has answers here:
How To Run PHP From Windows Command Line in WAMPServer
(12 answers)
Closed 4 years ago.
When I start wamp it shows me this error about the PHP path but I don't even have this PHP version on my computer.
Sorry,
There is an error.
There is Wampserver path (c:/wamp64)
into Windows PATH environnement variable: (C:\wamp64\bin\php\php7.2.4)
It seems that a PHP installation is declared in the environment variable PATH
C:\wamp64\bin\php\php7.2.4
Wampserver does not use, modify or require the PATH environment variable.
Using a PATH on Wampserver or PHP version
is detrimental to the proper functioning of Wampserver.
Press ENTER to continue...
This are the versions that I have installed: 5.6.38, 7.0.32, 7.1.22, 7.2.10
I've already tried uninstalling and installing wamp again (even upgraded to the newest version), but still get the same error.
I've also already tried changing the Environment Variables PHP path like how it is suggested in this question I am getting error in wamp for PHP in path and it didn't work.
I can access the localhost page, the phpmyadmin page, everything seems to work fine but I keep getting this error.
EDIT: I don't understand why this was marked as duplicate. This question was about runing php from command line, mine was about an error, that just so happen to be about php and wamp as well. It has nothing to do with my question at all, and didn't answer any questions I might still have had.
I fixed it on my own.
I unistalled wamp, deleted the php path (like it says to do on the question I linked above), installed wamp again and then added back the php path (I don't think you have to do this last step, but I did it anyway. It was there, there might be a reason why? edit: it's there because composer needs it).
At first it still wasn't working. I had visual code opened when I did this because I was trying to roll back some migrations I had made before this error, but it was giving me another error (php command not found, or something like that), so I closed visual code, opened it again and it was working. edit: again, composer. I guess because I hadn't closed it, it didn't recognised I had added it back, but this error was because of composer
I still don't know what caused this error, since it was working the last time I checked, with no errors and I didn't change anything, but at least it's fixed.
I don't know if this was the best solution, but I hope it can help someone who is in the same situation as me!
Edit: I know wamp doesn't need the path, but from what I've read and from this experience, composer does.
WAMPServer does not set the PATH to contain a reference to it's potentially multiple versions of PHP and warns you with the error above that there is a potentially confusing situation on your system if it finds that someone has.
The confusion being that when you run the PHP CLI (Command Line Interface) you will be running the version of PHP referenced in the PATH environment variable. Remember this is only affecting the PHP CLI and not the version of PHP that runs with Apache!
Ok so why is it on the PATH anyway?
If people have attempted to install Apache and PHP manually the install of a Windows Standalone PHP will add the folder containing that version of PHP to the PATH.
You may have followed some bad advice and added a version of WAMPServers own PHP versions to the PATH.
What you should do to remove this error
All you need to do is remove ANY reference to ANY folder that contain a PHP executable from your Windows PATH environment variable.
Look at System Properties Heres how to get to those
So how do you run the PHP CLI for any version of PHP installed in WAMPServer
Here is How I do it, the batch file also includes using Composer and even PEAR is you want to. Amend that to suite you situation.
Wampserver decries it as error. But it's clearly more of a bug.
It's just a warning, that you can (and probably should) disable.
Wampserver insisting on managing the available PHP versions might be the proper thing to do from their perspective. It shouldn't prevent you from utilizing proper OS lookup features and having a shortcut to PHP CLI however.
The message itself, btw
[…]
Wampserver does not use, modify or require the PATH environment variable.
[…]
Using a PATH on Wampserver or PHP version is detrimental to the proper functioning of Wampserver.
is pretty vague as to how exactly it is "detrimental". Wether Wampserver uses mod_php or FPM shouldn't be affected by a PATH setting. It would be an issue with old-school CGI setups (but nobody is doing that anymore).
It's kinda bonkers that the message first claims that the environment variable is not used and required, but then goes off to make it sound harmful (without mentioning the concrete conflict).
Alternatively you can of course set up the recommended batch wrapper, and remove the versioned folder from your system environment PATH.
See also: http://forum.wampserver.com/read.php?2,151286,151424#msg-151425
Related
So I have been looking on the net for hours now and I can't solve my problem.
I have wamp installed (WampServer Version 3.1.7 64bit).
I want to open phpMyAdmin through wamp. (I have the phpMyAdmin5.0.2 installed and phpMyAdmin.conf is configured).
I have several php versions installed.(this was done through the process of trying to fix the solution alone).
When I try to open phpMyAdmin I get this error message: [1]: https://i.stack.imgur.com/ZEMaX.png .
I have tried configuring php.ini file (by de-commenting mysqli) it didn't change a thing.
Here's my php.ini file joined in the google drive link: https://drive.google.com/file/d/1fQuVoh5vhRX-MHhYL3zMQ4xNkstO-4Ch/view?usp=sharing .
I have configured extension_dir tp the php/ext folder.
I have similary configured my windows path to the php/ext.
Nothing I try works. Any help is welcome.
Thank you.
Since you're using WAMP, which should include all the pieces you need already working, but also have several PHP versions installed, it sounds like you're installing more than you need which is causing conflicts.
Assume you have no data in your database or web pages that you need to preserve, I suggest removing everything; get rid of WAMP and any extra Apache, PHP, or MySQL/MariaDB installations you have. Clean up (delete or move out of the way) any leftover configuration files, then reinstall WAMP. If you have trouble after installing only WAMP and no other PHP installation, then report back here details of the error. WAMP should come to you working and all ready to go, so if there is a problem, it will be helpful to start from a known base installation without extra configuration files or executable that will cause conflicts.
I'll also point out that the very top of the file you posted states that it's used only for the PHP Command Line Interface, so this is not the configuration file used by anything running through your webserver (like phpMyAdmin or your site). It's a little confusing that there are really two PHP instances (one for the command line and one that runs through the webserver), but in this case you would be looking for the file in wamp/bin/apache/apache2.x.y/bin/php.ini
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
This question already has answers here:
program cant start because php5.dll is missing
(9 answers)
Closed 6 years ago.
I have a Win 2008 r2 server that has been running PHP 5.3 and convinced client to upgrade to 5.6.19 which is the latest available at the time of this post. This instance runs Apache 2.2.
Because I want to keep this instance lean but able to move back to 5.3 if I failed I downloaded the non-thread-safe version. I've updated the soon-to-be commissioned php.ini (formerly the example production file) to be aligned with the params in the 5.3 php.ini. Then I pointed the server's PATH from the 5.3 folder to the new one containing the 5.6.19 files. I have not attempted to run Apache yet opting instead to test that the new PHP works at least with CMD. That's when I got the above message.
It would seem the consensus of these posts:
http://www.touchoftechnology.com/the-program-cant-start-because-php5ts-dll-is-missing-from-your-computer-error/#ixzz42KMHyQFz
program cant start because php5.dll is missing
that I should rename the php5.dll file to 'ts' or 'nts' in its file name and/or add this designation in the php.ini. But I don't see where to put it in the .ini file. Renaming php5.dll (from the installation files) to php5nts.dll returns the message that php5.dll is missing. I've tried many different combinations of these filenames, and even adding a php5ts.dll from a thread-safe distribution. I can't get one without the other.
One of the posts suggests adding the 'nts' to some of the Zend extensions but I'm not running zend on this production box. Where in the php.ini do I need to set the file I got (php5.dll) to solve this? I hope once I get the CLI working that the Apache should not have this problem.
Other comments say to run Microsoft's Platform installer but that seems to introduce more things that are not needed on this production box and I do not want any extra baggage. I just want to point Windows and Apache to this newer PHP install.
I had read that for early Windows OS I should use the non-thread safe version of PHP. That version is missing the php5apache2_x.dll which caused doubt about this package. An acquaintance said to use the thread safe version which had the php5apache2_4.dll. It seemed to work in the Windows CMD browser after I set my environment variable to that folder. But digging further, it appears that I should also upgrade my Apache to 2.4 as later PHP and later Apache are using different Visual Studio compilers.
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 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.