Explore logging to a file

[bgrgicak]

What is this PR doing?

What problem is it solving?

How is the problem addressed?

Testing Instructions

[bgrgicak]

@adamziel I would appreciate some advice on a few issues with this exploration.

Saving to file

The current implementation isn't fully working because of a mix of sync and async code.
I could make everything async, but this could result in many changes, especially because we are replacing sync console.log with async logger.log I would prefer to keep things sync where possible.

Because writing to files must be async we could split the process into log collecting to an array and log saving to a file.
To do this we could use the request.end event which would take logs from the array, update the file, and remove logs from the array when done.
This is a common pattern in loggers for example if the collector sends data over HTTP.

Getting the PHP instance

The logger doesn't need a PHP instance, we currently use it only in the collector, but with saving to files, the file handle needs access to PHP.

I see a few options, but they all have pros and cons.

Get PHP from collectPhpLogs (not an option)

When calling collectPhpLogs we can add the UniversalPHP instance to the logger.
The handler can reuse it.
This is the current implementation and it feels hacky because it relies on an unrelated collectPhpLogs call.

Logger initializer

We could add the php instance to the logger when PHP-wasm starts. This would require yet another initializer function, or updating how we initialize the logger.

Moving the logger instance into the PHP instance

We could consider storing the logger instance in BasePHP. When the logger instance is created, it would have access to the PHP instance.

We initially moved away from this because we didn't want to tightly couple the logger with PHP-wasm, but we went in that direction later to support collecting different log types.

This would also allow us to expose the logger instance to the Playground client, which is a missing feature for projects that use the Playground JS API and want to get log events.

[bgrgicak]

I will move forward with storing logs in an array and moving them to a file on request.end.

This should keep the code simple and avoid frequent file writes.

[bgrgicak]

Moving the logger instance into the PHP instance

I still need to figure out what to do with this before I can continue.

[adamziel]

The logger doesn't need a PHP instance, we currently use it only in the collector, but with saving to files, the file handle needs access to PHP.

How would you save a "PHP instance crashed irreperably" log to a file in the PHP filesystem? What are some upsides of doing that?

[bgrgicak]

How would you save a "PHP instance crashed irreperably" log to a file in the PHP filesystem? What are some upsides of doing that?

I don't think that we can do that. Once PHP crashes we don't have file access, or am I wrong?
This would work for all other errors. The goal would be for an environment like wp-now to have access to all logs and not just PHP logs.

[adamziel]

Aha, that makes sense @bgrgicak! I'd love to help, I'm just not sure what's the specific question you're looking an answer for. It seems like a new log handler would solve this?

[bgrgicak]

Aha, that makes sense @bgrgicak! I'd love to help, I'm just not sure what's the specific question you're looking an answer for. It seems like a new log handler would solve this?

Yes, the handler would pull data from the main logger instance and send it to a file on every 'request.end'. This is the easy part.

What I'm unsure about is how to pass the PHP instance to the handler because the logger doesn't have access to it today.

I was thinking of not initializing the logger automatically and initialize it somewhere in PHP-wasm, for example BasePHP.
This would allow me to store the PHP instance in the logger and use it by handlers and collectors.

But I'm not sure if there is a better way to do it.

[adamziel]

What I'm unsure about is how to pass the PHP instance to the handler because the logger doesn't have access to it today.

Gotcha! I'd avoid intertwining it with BasePHP and offload this to the developers – they could create that handler in their app like this:

const php = await myCustomPHPFactoryForMyUniqueApp();
logger.addHandler( createPHPFileLogHandler( php, '/tmp/log.txt' ) );

Or something to that effect