-
Notifications
You must be signed in to change notification settings - Fork 93
Implement network-specific metadata handling in commands. #518
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
Conversation
Added overrides for add, update, get, and delete metadata methods to utilize network-specific options when available. This ensures compatibility and functionality for multisite network scenarios. Fallbacks to standard metadata functions are maintained for non-network environments.
spacedmonkey
commented
Jan 22, 2025
Pinging maintainers to get eyes on this @swissspidy @danielbachhuber @schlessera
swissspidy
commented
Jan 22, 2025
Note that we get pinged automatically with the review request :)
swissspidy
commented
Jan 22, 2025
Two thoughts:
- Network meta command accessing the incorrect caches #504 mentions steps to reproduce the issue — this could be added as a Behat test.
- Looking at https://core.trac.wordpress.org/ticket/61467, it sounds like this could just as well be fixed only in core — so why this change here? Could we just wait for the core fix?
jonnynews
commented
Jan 22, 2025
Note that we get pinged automatically with the review request :)
No one was assigned for a code reviewers. Maybe this repo needs a codeowner file 🤔
#504 mentions steps to reproduce the issue — this could be added as a Behat test.
Before spending any time on getting tests to work, I wanted to make sure everyone was happy with the approach.
Looking at https://core.trac.wordpress.org/ticket/61467, it sounds like this could just as well be fixed only in core — so why this change here? Could we just wait for the core fix?
The core patch is not confirmed yet and not work. Also that will only fix the issue with 6.8+. WP CLI support down to 3.7. Fixing this here is to ensure BC.
swissspidy
commented
Jan 22, 2025
No one was assigned for a code reviewers.
Screenshot 2025年01月22日 at 14 51 12
Screenshot 2025年01月22日 at 14 51 05
Before spending any time on getting tests to work, I wanted to make sure everyone was happy with the approach.
It looks reasonable to me in theory, yes.
jonnynews
commented
Jan 22, 2025
schlessera
commented
Feb 5, 2025
Yes, approach looks good, @jonnynews. If we add the tests from #504 , this will be good to go.
swissspidy
commented
Nov 11, 2025
According to the issue description, the following test should reproduce the situation:
Scenario: Network meta is actually network options Given a WP multisite install When I run `wp eval 'update_network_option( 1, "mykey", "123" );'` And I run `wp eval 'echo get_network_option( 1, "mykey" );'` Then STDOUT should be: """ 123 """ When I run `wp network meta update 1 mykey 456` Then STDOUT should be: """ Success: Updated custom field 'mykey'. """ When I run `wp network meta get 1 mykey` Then STDOUT should be: """ 456 """ When I run `wp eval 'echo get_network_option( 1, "mykey" );'` Then STDOUT should be: """ 456 """
Is that accurate?
Because this currently passes for me on main... 🤔
Added overrides for add, update, get, and delete metadata methods to utilize network-specific options when available. This ensures compatibility and functionality for multisite network scenarios. Fallbacks to standard metadata functions are maintained for non-network environments.
Add function exists, to ensure compatablity with 4.2 below.
Fixes #504