Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wp-now: Expose PHP error log #151

Open
adamziel opened this issue Jan 31, 2024 · 1 comment
Open

wp-now: Expose PHP error log #151

adamziel opened this issue Jan 31, 2024 · 1 comment
Labels
Enhancement New feature or request wp-now

Comments

@adamziel
Copy link
Collaborator

When developing with wp-now, it would be ideal to have the PHP errors available either in the terminal or in an error_log file/

The suggested wp-config.php settings would be:

define( 'WP_DEBUG', true ); // enable debugging
define( 'WP_DEBUG_DISPLAY', false ); // prevent errors/warnings from displaying on screen
define( 'WP_DEBUG_LOG', '/path/to/active/folder/debug.log' ); // log to errors/warnings to the debug.log file in the open folder

Bonus points if it could be possible to enable/disable the WP_DEBUG_DISPLAY constant, in case a developer wanted to do so.

This is just like #27, but for wp-now

@adamziel adamziel added Enhancement New feature or request wp-now labels Jan 31, 2024
@ktmn
Copy link

ktmn commented Feb 3, 2024

I'm just trying out wp-now for the first time, I'm following this:

### Defining Debugging Constants
In the similar way we can define `WP_DEBUG` constants and read the debug logs.
Run `wp-now start --blueprint=path/to/blueprint-example.json` where `blueprint-example.json` is:
```json
{
"steps": [
{
"step": "defineWpConfigConsts",
"consts": {
"WP_DEBUG": true,
"WP_DEBUG_LOG": true
},
"method": "define-before-run"
}
]
}
```

but I get:

Warning: Constant WP_DEBUG already defined in /var/www/html/wp-config.php on line 82

when actually using that blueprint.

So how is the defineWpConfigConsts step supposed to work when wp-config.php has WP_DEBUG hard-coded?

Edit: just noticed #135

johnhooks pushed a commit to johnhooks/playground-tools that referenced this issue Oct 11, 2024
## Description

Sets up the correct build pipeline for all parts of Playground and PHP.wasm. This enables a public release of the [Playground API](WordPress/wordpress-playground#149) npm package!

I've been [struggling](WordPress/wordpress-playground#146) with [this](WordPress/wordpress-playground#70) for [a while](WordPress/wordpress-playground#150) and couldn't understand what's so hard. NX made it apparent – look at this dependency graph!

<img width="1291" alt="CleanShot 2023-03-16 at 23 16 26@2x" src="https://user-images.githubusercontent.com/205419/225764795-7fa8e972-09f8-41ef-aac2-1c96bd100ea0.png">

No wonder it's been almost impossible to set everything up by hand!

## Usage

Start with `yarn install`

### Shortcuts

To start a copy of `wasm.wordpress.net` locally, run `yarn run dev`.
To build it, run `yarn run build`.

### Fully qualified commands

In reality, these `yarn run` commands are just triggering the underlying project's nx `dev` and `build` commands:

```bash
nx dev playground-website
nx build playground-website
```

Here's a few more interesting commands:

```bash
# Build and run PHP.wasm CLI
nx start php-wasm-cli

# Build latest WordPress releases
nx recompile-wordpress:all playground-remote

# Recompile PHP 5.6 - 8.2 releases to .wasm for web
nx recompile-php:all php-wasm-web

# Recompile PHP 5.6 - 8.2 releases to .wasm for node
nx recompile-php:all php-wasm-node

# Builds markdown files for readthedocs site
nx build docs-site

# Builds the Playground Client npm package
nx build playground-client
```

## NX is the tool Playground needed from the outset

It's ridiculous how many problems this solves:

* The build pipeline is explicitly defined and easy to modify
* Tasks only run once their dependencies are ready
* The dev mode works and is fast
* The build works and is fast
* We get CI checks to confirm the entire build process still works (which solves WordPress#150)
* Cross-package TypeScript just works
* There are linters and formatters (which solves WordPress#14)
* Documentation is correctly generated from the latest built artifacts
* There are nice generators for bootstraping new packages and moving the existing ones around
* There are checks to ensure the private `php-wasm-common` package is not imported by anything else than `php-wasm-web` and `php-wasm-node`

## Next steps

* Add Lerna to harness package publishing
* Additional developer documentation for the nx-based flow

Related to WordPress/wordpress-playground#148 and WordPress/wordpress-playground#147
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request wp-now
Projects
None yet
Development

No branches or pull requests

2 participants