With the logger refactoring and the latest changes in climulti:request, the archiving should log to file whether:

• core:archive calls the HTTP API
• core:archive calls climulti:request to simulate an HTTP call

climulti:request now starts in the web environment (instead of cli) which means it will log to file (if logging to file is enabled!).

So that means we can close this one?

Nice progress!

Here is a proposal:

• If climulti:request is supported, then archive runs over CLI.
  • if log to file is enabled, in the message, maybe we could give the path to the log file where the application+php errors are logged.
  • if log to file is not enabled, maybe we could recommend user to activate it (a must for troubleshooting?).
    • wondering if user will have to wait for next PHP error/warning occurence to happen to get more info
• If climulti:request is not supported, core:archive will run through web server. In this case we tell users to look in the web server error log file for info (eg. similar to current msg)

Wether climulti:request is supported or not it will be the same situation (i.e. if log to file is not enabled, then nothing is logged).

Could we just replace this:

Please check your Web server Error Log file for more details.

To this:

Please check the Piwik log file for more details. If you have not enabled logging in a file, see this FAQ: http://…

(by the way I couldn't find any FAQ regarding this?)

I'm not sure getting the name of the log file will be easy :/

Wether climulti:request is supported or not it will be the same situation (i.e. if log to file is not enabled, then nothing is logged).

not exactly, because, when climulti:request is not supported, then the requests will go through the web server and so we must tell user to also look in their we server error log which may have logged some error such as Timeout or Internal server error, that may somehow nt show up in piwik application logs (eg. if server is misconfigured or overloaded).

 (by the way I couldn't find any FAQ regarding this?)

we only have this FAQ so far: https://piwik.org/faq/troubleshooting/faq_115/ - maybe it needs updating?

I'm not sure getting the name of the log file will be easy :/

could we get it from DI container?

OK, but we can't know the location of the server error file. It's not configured in Piwik, it's something like /var/log/apache/error.log but it can be anywhere. Scratch that, I got what you meant now.

I'm thinking about it over and over...

• if running through web
  • exception/error: the HTTP request will return an invalid response containing the error
    • the error message shown will contain the error description: Good
  • memory limit or other fatal error with empty response
    • the error message shown will say "check your Web server Error Log file": Good
• if running through climulti:request

  • exception/error: the CLI command will return an invalid response containing the error

    • the error message shown will contain the error description: Good

  • memory limit or other fatal error with empty response

    • PHP running climulti:request should display on the CLI output the PHP error message (maybe on stderr), which means CLIMulti should pick it up and never go in the if (empty($response)) (because $response would contain the PHP error): Good

    For example running this shows the PHP error directly (so response is not empty):

    $ php -n -dmemory_limit=1M -r 'while (true) { $str .= 'h'; }'
    
    Fatal error: Allowed memory size of 1048576 bytes exhausted (tried to allocate 786385 bytes) in Command line code on line 1
    

TL/DR: empty response should only happen when running through web (i.e. climulti:request not supported).

$message = "Got invalid response from API request: $url. ";
if (empty($response)) {
    $message .= "The response was empty. This usually means a server error. This solution to this error is generally to increase the value of 'memory_limit' in your php.ini file. Please check your Web server Error Log file for more details.";
} else {
    $message .= "Response was '$response'";
}

That should show:

Got invalid response from API request: . Response was 'Fatal error: Allowed memory size of 1048576 bytes exhausted (tried to allocate 786385 bytes) in Command line code on line 1'

This should be fine then.

Sounds good! +1

OK all should be good then