-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Stabilize the PreSavePost and SavePost filters #64198
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
'editor.__unstableSavePost', | ||
Promise.resolve(), | ||
options | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If anyone ever registers an editor.__unstableSavePost
legacy filter, I'd like to log a deprecated
warning. But not sure how to do that. Did anyone do something similar before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't seem like it'd be as effective as a deprecation message on a call to addFilter
, but core has this PHP function, so replicating it might be the way to go - https://developer.wordpress.org/reference/functions/apply_filters_deprecated/
There's no JS equivalent unfortunately, so it'd need to be implemented in the hooks package, which makes this a bit more involved. 😅
I guess the reason it's not handled on add_filter
in core is the deprecation messages would have to be added within the add_filter
function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, apply_filters_deprecated
is exactly what I need 🙂 It does nothing when no filter is registered, but complains otherwise.
It needs to be added to @wordpress/hooks
first, but why not, I'm already adding async filters anyway. Seems that the hooks
package will get a nice upgrade in 6.7.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a apply_filters_deprecated
port to JS will make a lot of sense in the package, especially as we deprecate filters/actions in the future. Work for another PR of course 😉 It doesn't seem like the unstable hook was used anywhere (I've checked extensively on wpdirectory.net
and a few more places)
Size Change: +5 B (0%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
Flaky tests detected in 19c6326. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10214362037
|
packages/editor/src/store/actions.js
Outdated
'editor.__unstablePreSavePost', | ||
Promise.resolve( false ), | ||
edits = await applyFilters( | ||
'editor.PreSavePost', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most examples in the codebase are lower case first letter:
'editor.PreSavePost', | |
'editor.preSavePost', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I'll change that to lowercase. I've been looking at prior art for editor filters, and there are names like editor.BlockListBlock
, editor.BlockEdit
or editor.MediaUpload
, but these turn out to be exceptions: they are filters that wrap React components of the same name. By default filters should start with lowercase.
packages/editor/src/store/actions.js
Outdated
if ( ! error ) { | ||
try { | ||
await applyFilters( | ||
'editor.SavePost', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'editor.SavePost', | |
'editor.savePost', |
What are the blockers on this PR? We should probably ship stabilized names before WP 6.7. |
@Mamaduka We're experimenting with support for async hooks in #64204. See the discussion in #58022 (comment) I also plan that all this is finished in time for 6.7. |
830664f
to
f6c7cf5
Compare
Async hooks were just merged in #64204, so I amended this PR into a final form: it now gives the Please have a look. The next big question is whether we can still backport this into 6.7. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes a lot of sense and I like the new way it works 👍
I wonder if we should get an approval from @adamsilverstein who worked on these hooks before shipping and attempting to get it into 6.7 though.
} ) | ||
async ( options ) => { | ||
if ( ! options.isAutosave && select.hasMetaBoxes() ) { | ||
await dispatch.requestMetaBoxUpdates(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Returning here previously didn't make much sense, and that's why we're removing it, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously we were returning a promise, so that the next filter can .then
on it. Now this is all handled by the async runner: it will ensure that the next handler runs only after the previous one finished and succeeded.
That's also why this hook is no longer a filter, but an action. Action handlers don't return anything.
'editor.__unstableSavePost', | ||
Promise.resolve(), | ||
options | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a apply_filters_deprecated
port to JS will make a lot of sense in the package, especially as we deprecate filters/actions in the future. Work for another PR of course 😉 It doesn't seem like the unstable hook was used anywhere (I've checked extensively on wpdirectory.net
and a few more places)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good from my perspective 👍 ✅
Thanks!
Yes, this is going to be a very nice and simple addition 🙂 Too bad I didn't get to finish it for 6.7. |
* Stabilize the PreSavePost and SavePost filters * Use lowercase names * Use async hooks
I just cherry-picked this PR to the wp/6.7 branch to get it included in the next release: fbd2119 |
* Stabilize the PreSavePost and SavePost filters * Use lowercase names * Use async hooks
…)" This reverts commit 4f97ebb.
@fabiankaegy Yes it's true, this PR is also a good candidate for a dev note. I'll take care of it. |
Followup to #58022 which stabilizes the filter names as
editor.preSavePost
andeditor.savePost
, removing the__unstable
prefixes. The oldeditor.__unstableSavePost
filter continues to work because it's been there for some time.I'm also changing the behavior a little bit:
edits
as the first parameter of the filteredits
, not an error. You need to throw or return a rejected promise to signal error.This example from #58022 no longer works:
The right thing to do is now:
or (the same thing with different syntax:
Now when the
hooks
package supports async hooks, I also turned thepreSavePost
filter into an async filter, andsavePost
can now be an action. Because it doesn't need to pass the promise from the previous handler and wait for it, it's all handled by the framework indoAsyncAction
.