In general, messing with the ports that your operating system is using just seems like a bad idea. You’ll end up with weird network issues like when trying to print.
In addition, for me having two web servers (IIS running locally for .NET projects) listening on different ports was important.
The best situation was to simply change the IP Port that Apache listens on (the default is port 80, which is the standard for all web traffic).
I changed mine to port 8666 (but it could be anything above 1024). I did the following:
Locate the httpd.conf file in the following directory
[install directory]\xampp\apache\conf
(mine was in, C:\xampp\apache\conf)
Find the line that says, "Listen 80"
- Change it to "Listen 8666"
- Save and Close the file
- Start or restart the Apache service in the XAMPP control panel.
Life should be good.
The only catch to this method is that you can’t just go to http://localhost/xampp any more. You have to tell your browser which port specifically to use (it will by default use 80), so you will have to use http://localhost:8666/xampp/ (the port is designated by the colon and then the number).
The cool thing is I can run http://localhost:8666 to run Apache and http://localhost:8616 to run my local IIS for .NET projects.
Note: XAMPP install path must NOT have special characters in it. Spaces are allowed, parentheses are NOT allowed. Other special characters have to be tested. Apache will not start if the XAMPP install path contains special characters such as parentheses.
A 500 Internal Server Error indicates that Chrome does try to load the page and even gets a server response (being the 500 error). So, the server fails. It probably has some logs?
As cookies are stored per (sub-)domain, and localhost and 127.0.0.1 are different domains, my bet is that Chrome has an old cookie for localhost, which has not yet expired, but is somehow no longer valid.
Even if PHP and phpMyAdmin are backwards compatible (so would handle differences after upgrades), the troublesome cookie might have been created while you were testing the new PHP and new phpMyAdmin. And now that you reverted the upgrade either PHP or myPhpAdmin does not understand the newer format of the cookie or a session it refers to.
For sessions, a browser's session cookie holds an id which on the server refers to "serialized" PHP objects. So, maybe the serialization format has changed in newer versions of PHP, and the old PHP does not know how to handle the newer format.
For other cookies, maybe phpMyAdmin has stored serialized objects in the cookie directly, or in its database, or simply expects different data than it finds in the cookie.
To test the above:
To see if a session cookie is the culprit: restart Chrome and try again.
To see if a regular cookie is causing this without wiping it yet: try an incognito session, which does not send existing cookies to the server. If that works: clear the localhost cookies.
If this does not work, then you need to find the 500 error in the server's log.
Best Answer
First ensure your
session.save_pathin your php.ini is set correctlythen check directory permission
Finally, clear everything (cache, cookies ..) at browser end, refresh and check
If you make any change in php.ini, restart apache