Repository navigation
Conversation
chore: update node, npm, and composer deps
- Add defined() checks in tests/_data/config.php to prevent duplicate constant errors when constants are already set in wp-config.php - Remove wp config set commands for WP_AUTO_UPDATE_CORE and AUTOMATIC_UPDATER_DISABLED from setup-wp-env.sh since they're already defined in tests/_data/config.php which loads first - Delete default WordPress content (Hello world! post and default comment) in setup-wp-env.sh to ensure tests don't fail due to unexpected content interfering with assertions (was experiencing failures in some clean environments ie GitHub vs already running environments, ie local) These changes fix functional tests that were passing locally but failing in GitHub Actions due to environment differences.
- Add defined() checks in tests/_data/config.php to prevent duplicate constant errors when constants are already set in wp-config.php - Remove wp config set commands for WP_AUTO_UPDATE_CORE and AUTOMATIC_UPDATER_DISABLED from setup-wp-env.sh since they're already defined in tests/_data/config.php which loads first - Delete default WordPress content (Hello world! post and default comment) in setup-wp-env.sh to ensure tests don't fail due to unexpected content interfering with assertions - Change theme from twentytwentyfive to twentytwentyone in codeception.dist.yml for compatibility with WordPress 6.1+ These changes fix tests that were passing locally but failing in GitHub Actions due to environment differences.
wp-env test environment doesn't have standard WordPress themes installed, so remove the theme configuration to let WPLoader use the default.
ContentTemplateTest requires a theme directory to copy custom templates. Add twentytwentyone theme to wp-env tests config and restore theme setting in codeception.dist.yml.
The twentytwentyone theme hooks the_block_template_skip_link to wp_footer, which was deprecated in WordPress 6.4. Add expected deprecation in setUp to prevent test failures on older WordPress versions.
The function was deprecated in WordPress 6.4, so only set the expected deprecation on that version and later.
…precation Instead of trying to expect the deprecation (which only works when the hook actually fires), remove the deprecated function from wp_footer entirely to avoid the deprecation notice.
…emoval Explain why removing this action is not a hack but a legitimate fix for test framework noise. The deprecation notice goes to error logs, not the response body, and doesn't affect WPGraphQL's output buffering which is what these tests actually verify.
Let each WordPress version use its native default theme to catch real-world compatibility issues. The RouterTest fix for removing the_block_template_skip_link only runs if the function exists, so it's safe regardless of which theme is active.
- Add 'theme' variable to CI matrix: - WP 6.1-6.6: twentytwentyone (classic) for classic template tests - WP 6.7+: twentytwentyfive (block) for real-world block theme testing - Install both themes in .wp-env.json for availability across all WP versions - Add TEST_THEME env var support in codeception.dist.yml - Update ContentTemplateTest to handle both theme types gracefully - Add documentation for template differences between classic/block themes - RouterTest: Remove deprecated the_block_template_skip_link action This ensures comprehensive testing coverage for both classic PHP templates and modern block themes across the WordPress version matrix.
| parent::setUp(); | ||
|
|
||
| // your set up methods here | ||
| /** |
There was a problem hiding this comment.
bad ai. We do not need a 30LOC doc-block before a 2-line remove_action()
There was a problem hiding this comment.
lol. that was me prompting for a comment here, because I wouldn't know why the heck we were doing this if I looked back in 2 years.
There was a problem hiding this comment.
How about
/**
* The twentytwentyone theme hooks the deprecated `the_block_template_skip_link` to `wp_footer`.
* We unhook it here, so we don't need to litter our tests with `setExpectedDeprecated()` any time `wp_footer` is triggered.
*/- Add testBlockThemeCustomTemplate: Tests programmatically created block templates - Add testBlockThemeI18nTemplate: Tests block templates with i18n names (e.g., Japanese) - Add testBlockThemeBuiltInTemplate: Tests assigning built-in block templates to pages - Add skipIfNotBlockTheme() helper and createBlockTemplate() helper method CI matrix coverage: - WP 6.1-6.6 (twentytwentyone): Runs classic PHP template tests, skips block tests - WP 6.7+ (twentytwentyfive): Runs block template tests, skips classic tests - Universal tests (DefaultTemplate, introspection) run on both
| multisite: "%MULTISITE%" | ||
| title: "Test" | ||
| theme: "twentytwentyfive" | ||
| theme: "%TEST_THEME%" |
There was a problem hiding this comment.
Im not by my computer to check, but this coupling between CI and codeception makes me nervous and is what I fought so hard to refactor away from. What happens when this isnt explicitly defined in the env?
There was a problem hiding this comment.
funky issues and missed coverage. Things like ContentTemplate behave differently for block themes and "classic" themes, so if we only test on twentytwentyfive we have failing tests for "old" features that work on "classic" themes. By using a variable and updating the matrix we can now properly test features on both classic and block themes.
I'm open to other ideas, but I do think we need a way to ensure we're testing both block and classic themes, as we weren't properly doing it and the hard-coding of a theme in this PR brought that to light for me
There was a problem hiding this comment.
So then at minimum we should add it to .env.dist with a default of twentytwentyfive so non-ci testing doesn't go funky
PS: we're also not clobbering coverage, so coverage is still gonna be missed, same as it is currently via multisite.
There was a problem hiding this comment.
(once the env is updated with our new var, I'm good with merging. any other feedback i have will either be cosmetic or iterative and can happen as a followup)
There was a problem hiding this comment.
I think I tried leaving theme undefined and letting the latest default theme be active, but I think that wasn't working. I can try again.
There was a problem hiding this comment.
Ok, so ya, I tested without defining theme in codeception.dist.yml, hoping that WP would just load whatever default theme for that WP version, but that wasn't happening.
So we do need theme: "%TEST_THEME%" in codeception.dist.yml for the CI matrix to work, and to ensure we're testing features of block themes and classic themes.
WPLoader only uses the theme if it's explicitly configured. If we remove theme from the config, passing TEST_THEME as an env var does nothing - WPLoader just ignores it and uses WordPress's default (which is often empty/broken in the test environment, at least from what I was testing. Maybe it was an issue with my test runs, though? Possibly I need to stop/start my wp-env also 🤔).
So the coupling is intentional - without it, the CI matrix can't switch themes per WordPress version (although let me try again with stopping/starting my wp-env with the theme not explicitly set in codeception.dist.yml 👀 )
Some Notes
.env.dist already has TEST_THEME=twentytwentyone as a default. The standard setup flow is:
- Clone repo
- Copy
.env.dist→.env - Run tests
So TEST_THEME is always defined for anyone following the setup docs. CI just overrides it via the matrix.
This is the same pattern we use for MULTISITE, TEST_DB_NAME, etc. - defaults in .env.dist, CI can override when needed.
What happens in practice
| Scenario | Result |
|---|---|
Dev runs tests without .env |
❌ Error (but this breaks other stuff too, not just theme) |
Dev copies .env.dist to .env |
✅ Uses twentytwentyone |
| CI with WP 6.7+ | ✅ Uses twentytwentyfive (block theme) |
| CI with WP 6.1-6.6 | ✅ Uses twentytwentyone (classic theme) |
I added a comment in codeception.dist.yml explaining this so future us doesn't wonder why it's there. 👍
There was a problem hiding this comment.
ok, unfortunately, that doesn't work (stopping/starting wp-env for different versions of WP). When theme isn't in the config, WPLoader loads WordPress without any theme, regardless of what's active in wp-env.
WPLoader requires explicit theme config to load a theme for wpunit tests. Default is twentytwentyone (in .env.dist), CI matrix overrides per WP version.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Dovid Levine <justlevine@gmail.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
3 participants
Fix Test Failures and Add Theme Matrix to CI
Summary
This PR builds on the wp-browser 3.7 upgrade by fixing test failures and adding comprehensive theme testing to CI.
Changes
🎨 Theme Matrix in CI
Added theme testing to catch compatibility issues across both classic and block (FSE) themes:
twentytwentyfivetwentytwentyoneThis ensures WPGraphQL is tested against realistic default themes for each WordPress version, catching theme-specific issues before they reach production.
🧪 Test Fixes
RouterTest: Fixed deprecation notice failures from
the_block_template_skip_link(deprecated in WP 6.4). The twentytwentyone theme hooks this function towp_footer, which triggered test failures. The action is now removed in test setup with detailed comments explaining why this is the correct approach—WPGraphQL's output buffering handles this in production, but the test framework's deprecation tracking causes false negatives.ContentTemplateTest: Updated to gracefully handle both classic and block themes:
testAvailableTemplatesAreExposedandtestTemplateQueryReturnsTypeInfofor coverage on both theme types📁 Configuration Updates
.wp-env.json: Addedtwentytwentyoneandtwentytwentyfivethemes to ensure availability across all WP versionscodeception.dist.yml: Addedtheme: "%TEST_THEME%"for dynamic theme configuration.env.dist: AddedTEST_THEMEenvironment variable (defaults totwentytwentyone)testing-integration.yml: Addedthemeto CI matrix with activation step📖 Documentation
Added documentation in
docs/themes.mdexplaining the differences between classic and block theme template behavior in WPGraphQL.Testing
All tests pass locally with both themes:
twentytwentyonetwentytwentyfiveBreaking Changes
None. This is a test infrastructure update only.