Asked  7 Months ago    Answers:  5   Viewed   29 times

Yes, there's a built-in web server in the upcoming release of PHP 5.4 which you can try out in their release candidates (I found about this just recently too!)

What I need help figuring out is, is there any way to make it run on domain names other than localhost (it's running fine on localhost, port 80)? Even doesn't work. I've put in dummy hostnames in my hosts file to point to and they don't work too. I understand that it's just a release candidate, but I would like to know whether anyone else has already come up with a solution for this issue so that I can test my app with the actual domain name pointing to in my hosts file. OS is Windows 7 Professional SP1.

Things I've already tried: 1. Googling (duh) 2. Looking through php.ini for options 3. Trying out, my LAN IP, my WAN IP with port 80 forwarded and NAT loopback issue fixed (router running DD-WRT)



I did these tests on a Windows XP system, but should work the same on Linux as well by modifying the commands.

Run your PHP test server like this:

C:/php/php.exe -S
/usr/bin/php -S will bind to all available IP addresses on the system.

On another machine on the network, I configured the hosts file to point to the internal IP of the system running PHP using a custom domain. This is not as that refers to the local host, in my case I pointed my main PC to which was the XP machine running PHP. Note the firewall should be disabled or set to allow traffic on port 80 on the machine running php.

I configured my router to port forward traffic from external port 80 to Then using a hosts file on a PC from an external network, I configured the fake domain to point to my WAN IP. I was able to access the PHP web server externally.

That said, it is just a server for testing, so there may be unknown security risks opening it up to the outside world.

Hope that helps you.

Wednesday, March 31, 2021
answered 7 Months ago

You should point to your vendor/autoload.php at Settings | PHP | PHPUnit when using PHPUnit via Composer.

This blog post has all the details (with pictures) to successfully configure IDE for such scenario:

Related usability ticket:

P.S. The WI-18388 ticket is already fixed in v8.0

Wednesday, March 31, 2021
answered 7 Months ago

On Mac OS X environment variables available in Terminal and for the normal applications can be different, check the related question for the solution how to make them similar.

Note that this solution will not work on Mountain Lion (10.8).

Saturday, May 29, 2021
answered 5 Months ago

You shouldn't create a run configuration at all, just to click on the listen button:

  1. Configure xdebug to attempt to debug every single script (xdebug.remote_autostart = 1 and xdebug.remote_enable = 1).

  2. Use "Phone handle" icon in IDE to start listening for debug connections (e.g. as described in here)

  3. Launch your php code from anywhere -- XDebug will attempt to debug every incoming request.

Here is an hour long webinar about the subject.


if you're interested in doing the same thing on vi + xdebug, see this answer.

Saturday, May 29, 2021
answered 5 Months ago

There isn't one right answer to this question, but here are some things to keep in mind:

With the right amount of horizontal scaling, it is quite possible you could keep scaling out use of the debug server forever. When exactly you would need to start scaling (or switch to using a "real" web server) would also depend on the environment you are hosting in, the expectations of the users, etc.

The main issue you would probably run into is that the server is single-threaded. This means that it will handle each request one at a time, serially. This means that if you are trying to serve more than one request (including favicons, static items like images, CSS and Javascript files, etc.) the requests will take longer. If any given requests happens to take a long time (say, 20 seconds) then your entire application is unresponsive for that time (20 seconds). This is only the default, of course: you could bump the thread counts (or have requests be handled in other processes), which might alleviate some issues. But once again, it can still be slow under a "high" load. What is considered a "high" load will be dependent on your application and the expectations of a maximum acceptable response time.

Another issue is security: if you are concerned at ALL about security (and not just the security of the data in the application itself, but the security of the box that will be running it as well) then you should not use the development server. It is not ready to withstand any sort of attack.

Finally, the development server could just fail outright. It is not designed to be used as a long-running process (days, weeks, months), and so it has not been well tested to work in this capacity.

So, yes, it has limitations. Yes, you could still conceivably use it in production. And yes, I would still recommend using a "real" web server. If you don't like the idea of needing to install something like Apache or Nginx, you can still go with a solution that is still as easy as "run a python script" by using some of the WSGI Standalone servers, which can run a server that is designed to be in production with something just as simple as running python in the command line. You typically just need to create a 4-5 line python script to import and create the server object, point it to your Flask app, and run it.

gunicorn could be run with only the following on the command line, no extra script needed:

gunicorn myproject:app

...where "myproject" is the Python package that contains the app Flask object. Keep in mind that one of developers of gunicorn would probably recommend against this approach. See

Monday, June 21, 2021
answered 4 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :