Fatal error: XAMPP

4lan4raujo

Error after installing on the local server XAMPP

Fatal error: Maximum execution time of 30 seconds exceeded in C:\host\htdocs\flarum\flarum\vendor\s9e\text-formatter\src\Configurator\JavaScript\Minifiers\ClosureCompilerService.php on line 52

d1a8lo24

Make sure that " allow_url_fopen" is enable in PHP(meaning in your php.ini file,) since "file_get_contents" is trying to access a URL. That is the first thing I would check since its trying to get data from a URL and only with "allow_url_fopen" will work.

JoshyPHP

If it was allow_url_fopen it would be a different error message.

Try bumping max_execution_time to 40-60 in your php.ini and see if it changes anything.

d1a8lo24

On line 52 there is an if statement, meaning that it shouldn't take no more than a second to validate a true or false variable.

But because a file_get_contents is being call right before it and its trying to get data from a URL thats where the problem may be, since file_get_contents doesn't know when to stop retrieving data it will wait there until there is a 200 response from the site and is fully loaded until then is when its execution should end and move on. And because of these there is no error from file_get_contents since it never got to finish.

and max_execution_time should be left alone unless you know that whatever script you're calling needs that much time, thats a half on a minute already waiting longer just means that there is something not being process correctly and with PHP applications most of the time is because a connection to the database is taking too long for many reasons, or there is a call to another link and its waiting for a response. That is why CURL is always the best at this because you can give it a timer for it to wait else close the connection and send an error.

And the only reason why I mention allow_url_fopen is because if its not enable using a URL in file_get_contents will not work. And I am pretty sure there are many others out there that may be having problems if this setting is not enable. I have had many problems with other apps that use file_get_contents to retrieve data from URL the problem is that many share hosts don't have this enable and many times errors are not display for the same reason.

--- Sorry line 52 is still part of the file_get_contents code block so the site that is trying to call may just be busy, I am pretty sure you have seen sites that just load forever sometimes. That is why to me using CURL is better in such cases.

JoshyPHP

As per the PHP's manual, "The maximum execution time is not affected by system calls, stream operations etc."

There is a default timeout for steams, default_socket_timeout. There is also a timeout context option for HTTP(S) streams, although in this case it is not used. In my experience, most people who use the cURL extension in PHP do so because they are unfamiliar with PHP streams.

d1a8lo24

JoshyPHP As per the PHP's manual, "The maximum execution time is not affected by system calls, stream operations etc."

There is a default timeout for steams, default_socket_timeout. There is also a timeout context option for HTTP(S) streams, although in this case it is not used. In my experience, most people who use the cURL extension in PHP do so because they are unfamiliar with PHP streams.

You can have an execution time of 1 hour if you want but that doesn't mean you should do it and have a script run for such a long time specially in PHP and this will just make your server environment very unstable an easy to overload. This Is also a security issue, since anyone can overload a server if they know that your execution time is that high. Now I am not going to say you can't use it for debugging but always make sure to set it back to the way it was.
Yes there is a default_sucket_timeout setting in PHP but is a setting that not everyone has access too, even when this can be set dynamically. Some hosts specially share hosts will disable such settings and wrappers to access URLs for security reasons. That is why CURL is always the prefer way of making such calls and most share hosts in my experience will have it enable. But if you're building an application and want to make it as user friendly as possible you should always have another way of doing things if possible such as if CURL is available use it if not use fsockopen and if not and last use file_get_contents while always making sure that the last 2 functions in order to call URL will need to have allow_url_fopen setting enable in PHP.

A good developer should always be aware that in many situations the user may not be able to configure such settings either because their host is not allowing it or they don't have any idea of what a php setting is or where to look, where it is and what to do and how to edit etc... and be able to provide other ways of doing things through the main script/application/function or provide an error if something fails. We are not building an application for professional developers but just regular people that just want to run a cool app.

Also some functions don't return anything, and there are many reasons why, bad configuration, something that the functions couldn't handle etc...

So having something like $var = some_function(); and that function fails "silently" will not set $var so doing if ( ! $var ) will also throw a silent error depending on your PHP error reporting and if its allowed to display errors. the error will be $var not set. The best way to test this is to use empty() this will test and empty string, false, empty array(), NULL, 0, and an unset variable.

The only reason why I mentioning this is because when you use file_get_contents you may run into a variable not being set because the function fail and it didn't return anything. It threw a silent error not return an error.

But that is just my opinion I may be wrong in all of it.

JoshyPHP

I didn't say that max_execution_time should be set arbitrarily high in production. 4lan4raujo said it was a local server and in this case, increasing max_execution_time will help him (and us) diagnose the issue.

Not everyone can change their server settings and not everyone has access to the cURL extension. You said that cURL "is always the best at this because you can give it a timer for it to wait". I corrected you on that; HTTP streams have a timeout context option in addition to the default socket timeout. You can read about it in the manual page that I linked.

You say "A good developer should always be aware". That's not the same thing as trying to cater to every badly configured instance of PHP out there. Development cost, maintenance cost and code complexity have to be considered.

I'd also like to remind you that there's no indication that this error originates from a lack of support for HTTP streams. As I said earlier, if it was the case the error message would be different. Specifically, it would be something like that:

Warning: file_get_contents(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0

In that case the JavaScript wouldn't be minified but the installation would just keep going normally.

d1a8lo24

JoshyPHP I didn't say that max_execution_time should be set arbitrarily high in production. 4lan4raujo said it was a local server and in this case, increasing max_execution_time will help him (and us) diagnose the issue.

It is different when you mention to "help him or us diagnose the issue" but when is not said an inexperience user may leave it that way or make it higher making them think that, that is the way to fix things.

At the end you had the right answer but is still not the solution since its the script that is taking longer than what the parcer is allowing, that is why I said that having a timer to make sure the call to the URL doesn't last longer than it should as some online services may no loner be available, could have a never ending load with out a response and many other issues that are out of the applications control, but it can control the time it should wait before closing the connection .

Also like I said before and what @4lan4raujo just did making this setting larger than what it should be can end up causing more problems than fixing things.

Here I am quoting PHP.NET max_execution_time

This sets the maximum time in seconds a script is allowed to run before it is terminated by the parser. This helps prevent poorly written scripts from tying up the server. The default setting is 30. When running PHP from the command line the default setting is 0.

30 seconds should be more than enough for very process intensive scripts but making a call to a URL to get a response should not be one of them.

JoshyPHP Not everyone can change their server settings and not everyone has access to the cURL extension. You said that cURL "is always the best at this because you can give it a timer for it to wait". I corrected you on that; HTTP streams have a timeout context option in addition to the default socket timeout. You can read about it in the manual page that I linked.

Yes you did corrected me by pointing out the function on php.net yet is not about you or me being right is about the function in question that is calling a service to minify the JS file but it does not have 2 things that should be important like you just pointed out which could help diagnose the problem.
1. Its not testing if allow_url_fopen is enable to make sure that file_get_contents can get data from a URL
2. there is no time limit set except to rely on the one set by default_sucket_timeout which could be longer than the one set by max_execution_time.

That is why I said always test if one function or library is available if not try the next best thing if available to make sure that the function can be executed, specially when you're relying on an online service. What if the site won't work because the application cannot reach the service or the service is temporary unavailable or no longer available.

At this point the more and more I look at this function I am just hoping that is not something required or that can easily be skip if not available also be set as an option to enable or disable it.

JoshyPHP You say "A good developer should always be aware". That's not the same thing as trying to cater to every badly configured instance of PHP out there. Development cost, maintenance cost and code complexity have to be considered.

That is true, but being aware of such things as a developer is very important in making an application that works well and doesn't require a programmer to identify the problem.

JoshyPHP I'd also like to remind you that there's no indication that this error originates from a lack of support for HTTP streams. As I said earlier, if it was the case the error message would be different. Specifically, it would be something like that:

Yes I understand that and I also said that sometimes a function may end up failing without errors for many different problems and errors will be different and this type of errors may end up not setting a variable and may not even display any errors.

Anyway I do hope people understand whats going on here and to never set max_execution_time to more than 30 seconds unless you're testing or debugging to see which script/function is tying up the server and why, once you're finish debugging make sure to set it back down to its default setting. And NEVER go crazy setting this to more than 60 seconds unless you know what you're doing.

4lan4raujo

Thanks guys solved the problem by modifying the PHP.ini

 ; Note: This directive is hardcoded to 0 for the CLI SAPI
  max_execution_time=900

clayanon

; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time=900

It doesn't work pal

4lan4raujo

clayanon Anymore undoubtedly is not the solution because to change to 60 secundos occurs the same mistake .
Also I have an error when you try to publish

validation.required

txtd

XAMPP shouldn't be your go-to solution when hosting locally.
You might wanna check a vagrant.

d1a8lo24

Yes use another solution that may work best for you.

There is WAMP, XAMPP, MAMP, Vargrant, Amazon AWS their Free tiers etc...

I haven't run into any big problems just a few and very, very small bugs. I have install it in a XAMPP stack on my windows machine running windows 10 64bit. I have also install it in a virtual server on godaddy running centos 6.

And I can say I am using it at my own risk on a small community and I haven't had any problems, when posting, replying, notifications etc...

I am guessing I am just lucky but I am loving this new forum application.

Anyway try other solutions, I have use most of them and they work, I just could never get vagrant to work correctly so I just gave up on it, I don't know if is my machine or what but it always freezes when I try to run it plus I am not that great using the console so that may be reason, me. 🙂