Expose PHP fatal errors from the WASM interpreter #3
Comments
adamziel
changed the title
|
Solved in a59ef18 by adding a php.ini with |
adamziel
added a commit
that referenced
this issue
Oct 5, 2022
bgrgicak
pushed a commit
that referenced
this issue
Jun 2, 2024
## What is this PR doing? Similar to #1357, but taking a deeper cut at it, as import expects to be run within an admin interface. ## What problem is it solving? The following fatal will be triggered: ``` PHP Fatal error: Uncaught Error: Call to undefined function wp_read_audio_metadata() in /wordpress/wp-admin/includes/image.php:2 Stack trace: #0 /wordpress/wp-content/plugins/WordPress-Importer-master/class-wxr-importer.php(1067): wp_generate_attachment_metadata(821, '/wordpress/wp-c...') #1 /wordpress/wp-content/plugins/WordPress-Importer-master/class-wxr-importer.php(861): WXR_Importer->process_attachment(Array, Array, 'https://raw.git...') #2 /wordpress/wp-content/plugins/WordPress-Importer-master/class-wxr-importer.php(383): WXR_Importer->process_post(Array, Array, Array, Array) #3 /internal/eval.php(20): WXR_Importer->import('/tmp/import.wxr') #4 {main} thrown in /wordpress/wp-admin/includes/image.php on line 2 ``` Fixes #1444 (Since found this issue) ## How is the problem addressed? Including includes/admin.php which pulls in all admin-related functionality, rather than just the cropping functionality. Alternatively, this could've been done by selectively importing `includes/media.php` as well as `includes/image.php`, but I anticipate that core is likely to include other related admin functions. ## Testing Instructions Note: This is an untested change. Try running https://playground.wordpress.net/builder/builder.html#{%22preferredVersions%22:{%22php%22:%228.0%22,%22wp%22:%22latest%22},%22phpExtensionBundles%22:[%22kitchen-sink%22],%22features%22:{%22networking%22:true},%22steps%22:[{%22step%22:%22login%22,%22username%22:%22admin%22,%22password%22:%22password%22},{%22step%22:%22importWxr%22,%22file%22:{%22resource%22:%22url%22,%22url%22:%22https://raw.githubusercontent.com/WordPress/theme-test-data/try/cors-accessible-images/themeunittestdata.wordpress.xml%22}}]}
ghost
mentioned this issue
adamziel
added a commit
that referenced
this issue
Nov 22, 2024
…lations Uses a major WordPress version to fetch the translations, e.g. https://downloads.wordpress.org/translation/core/6.6-RC/en_US.zip instead of https://downloads.wordpress.org/translation/core/6.6.1-RC/en_US.zip This fixes an issue introduced in #1987 that caused the E2E tests to fail on trunk: ``` ✘ 77 [chromium] › blueprints.spec.ts:438:6 › should translate WP-admin to Spanish for the beta WordPress build (retry #3) (30.2s) ``` The setSiteLanguage step would try to download the translations from https://downloads.wordpress.org/translation/core/6.7.1-RC/es_ES.zip which responded with a 404, instead of https://downloads.wordpress.org/translation/core/6.7-RC/es_ES.zip where the translations are actually available. ## Testing instructions * Confirm the E2E tests pass * Go here and confirm you can see a Spanish version of wp admin: http://localhost:5400/website-server/?language=es_ES&url=%2Fwp-admin%2F&wp=beta&modal=error-report
adamziel
added a commit
that referenced
this issue
Nov 22, 2024
…lations (#2017) Uses a major WordPress version to fetch the translations, e.g. `https://downloads.wordpress.org/translation/core/6.6-RC/en_US.zip` instead of `https://downloads.wordpress.org/translation/core/6.6.1-RC/en_US.zip` This fixes an issue introduced in #1987 that caused the E2E tests to fail on trunk: ``` ✘ 77 [chromium] › blueprints.spec.ts:438:6 › should translate WP-admin to Spanish for the beta WordPress build (retry #3) (30.2s) ``` The setSiteLanguage step would try to download the translations from https://downloads.wordpress.org/translation/core/6.7.1-RC/es_ES.zip which responded with a 404, instead of https://downloads.wordpress.org/translation/core/6.7-RC/es_ES.zip where the translations are actually available. ## Testing instructions * Confirm the E2E tests pass * Go here and confirm you can see a Spanish version of wp admin: http://localhost:5400/website-server/?language=es_ES&url=%2Fwp-admin%2F&wp=beta&modal=error-report
adamziel
pushed a commit
that referenced
this issue
May 30, 2025
## Motivation for the change, related issues **This is a WIP draft at the moment. Looking for feedback on the direction I'm taking here.** The new SQLite driver requires the `DB_NAME` constant to be set. This is to be able to store the correct database name in the information schema. However, some WordPress site backups and exports don't include the constant in `wp-config.php`. This happens with hosts that inject the database configuration in a different way. Even though we could probably emulate it dynamically in the SQLite driver, this may be non-trivial, e.g., in cases someone joins on the `information_schema.tables` table, etc. Making sure that the constant is defined seems to be easier, and should also improve the compatibility with any plugins that rely on the `DB_NAME` constant to be set. --- This was discovered when importing a site backup without the `DB_NAME` constant in Studio: ``` Fatal error: Uncaught Error: Undefined constant "DB_NAME" in /var/www/html/wp-content/mu-plugins/sqlite-database-integration/wp-includes/sqlite/db.php:64 Stack trace: #0 /var/www/html/wp-content/db.php(37): require_once() #1 /var/www/html/wp-includes/load.php(683): require_once('/var/www/html/w...') #2 /var/www/html/wp-settings.php(133): require_wp_db() #3 /var/www/html/wp-config.php(85): require_once('/var/www/html/w...') #4 /var/www/html/wp-load.php(50): require_once('/var/www/html/w...') #5 /var/www/html/wp-blog-header.php(13): require_once('/var/www/html/w...') #6 /var/www/html/index.php(17): require('/var/www/html/w...') #7 {main} thrown in /var/www/html/wp-content/mu-plugins/sqlite-database-integration/wp-includes/sqlite/db.php on line 64 ``` Related: - Automattic/sqlite-database-integration#40 - Automattic/sqlite-database-integration#44 ## Implementation details ## Testing Instructions (or ideally a Blueprint) 1. Boot Playground (`npm run dev`). 2. Export the site into a ZIP. 3. Remove the `DB_NAME` constant definition from the ZIP. 4. Import the site without the `DB_NAME` constant set. 5. Verify that a `DB_NAME` constant was injected (TODO: describe how). 6. Export the site ZIP and have the `DB_NAME` constant defined in `wp-config.php` (TODO: is this required?).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now, PHP syntax errors cause the WASM PHP to return an exit code 2, but it doesn't return any error message. Let's make it provide a regular error message such as
Fatal error: Class 'MyClass' not found in ...The text was updated successfully, but these errors were encountered: