Build pipeline for multiple PHP versions and targets #7
Labels
Comments
|
Multiple PHP versions are now supported via |
ghost
mentioned this issue
brandonpayton
pushed a commit
that referenced
this issue
Feb 25, 2025
## Motivation for the change, related issues Files in a zip file should only have relative urls as per spec. Right now, when exporting the backup for the site, we create a zip file with a leading slash in the files inside it. This got surfaced in Studio app when we switched to a diff zip library that strictly adheres to zip spec and PG exported zip files fail to process. Related to: Automattic/dotcom-forge#10369 Note: There are other places where `ZipArchive` is used but this PR only modifies the location that impacts the site export. <img width="531" alt="Screenshot 2025-01-30 at 11 44 32" src="https://github.com/user-attachments/assets/561896ee-0fe9-40c1-b413-d226c68fc0be" /> Probably other places can use the same change, and I can follow that up in a separate PR, if you like. ## Testing Instructions (or ideally a Blueprint) Export zip of a site and examine the file paths inside it using the following script: ```php <?php $zip = new ZipArchive(); $zip->open('/Users/ashfame/Downloads/wordpress-playground-16.zip'); echo "=== ZIP Contents ===".PHP_EOL; for($i = 0; $i < $zip->numFiles; $i++) { echo $zip->getNameIndex($i) . PHP_EOL; } echo "=== End ZIP Contents ===".PHP_EOL; $zip->close(); ``` Prior to this PR, you would see file paths like: ``` /wp-content/themes/twentytwentyfive/patterns/more-posts.php ``` and with this PR you will see file paths without the leading slash: ``` wp-content/themes/twentytwentyfive/patterns/more-posts.php ```
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
What problem is this issue looking to solve?
A pipeline that builds all the listed PHP versions would pave the way to one-click switching of the PHP version:
How does this issue proposes to solve it?
The technical foundation was shipped in 45ba8ce. Since that commit, the docker build process can be build a specific PHP version as follows:
I confirmed it works with
7.0.0,7.0.24and even8.0.29when vrzno is disabled. It may break for versions that are not compatible with the PHP patches shipped in this repo.The text was updated successfully, but these errors were encountered: