#28578 closed defect (bug) (fixed)
Re-add install_themes_tabs filter
Reported by: | ghost1227 | Owned by: | SergeyBiryukov |
---|---|---|---|
Milestone: | 4.0 | Priority: | normal |
Severity: | normal | Version: | 4.0 |
Component: | Themes | Keywords: | has-patch dev-feedback |
Focuses: | docs, administration | Cc: |
Description
As I discussed with Andrew in Chicago, while the install_themes_tabs and install_plugins_tabs filters aren't necessarily common use, they do have uses. One of my most-used plugins actually depends on them. As the new theme installation page (and likely the upcoming rework of the plugin installation page) no longer provide these filters (and with good reason), I propose reworking the filters such that rather than the menubar being filterable, the add-new-h2 buttons take their place. The proposed patch implements this change for the themes page, and suits the needs I have for such a filter quite nicely.
Attachments (2)
Change History (23)
#4
@
10 years ago
- Component changed from General to Themes
- Milestone changed from Awaiting Review to 4.0
- The patch should keep the context on 'Browse' string:
_x( 'Browse', 'themes' )
vs.__( 'Browse' )
. - Filter docs are needed. Since
WP_Theme_Install_List_Table
is no longer used, I'd suggest copying the docblock from there (with updated defaults) and replacing it with a duplicate hook comment there.
#8
@
10 years ago
I can review the linked patch when I update this one if you'd like, but since a patch is provided...
#10
@
10 years ago
In fairness, me and Andrew are probably the only ones who've ever USED this filter, so I can't really blame anyone for removing it. But I want it back! :P
#11
@
10 years ago
I was also thinking whether we should introduce a new filter instead of repurposing the old one. But it looks like these links are used in the same way the old tabs were used, and have a similar structure, so I guess it makes sense to reinstate the filter.
#12
@
10 years ago
I put a lot of thought into that, but the implementation ends up being roughly the same. As such, any other plugins that may happen to utilize this filter won't need much tweaking to be updated for this implementation... as such, I chose to leave the name the same.
#13
@
10 years ago
For what it's worth, renaming hooks is not without precedent if going that route makes it clearer what's actually filterable in the new context.
See pre_get_search_form, add_option_{$option}, and upload_post_params just to name a few.
#14
@
10 years ago
@DrewAPicture I don't think changing the filter name would make it clearer, though someone with more core experience can certainly correct me if I'm wrong. What it DOES hasn't changed, just which tabs on that page it's applied on.
@SergeyBiryukov Little confused on one thing... it's not actually a duplicate hook, so not sure how a duplicate hook comment is relevant. The hook that it's duplicating was actually removed from core with the last update. I'm simply re-adding it in a slightly different spot.
#15
@
10 years ago
- Owner set to SergeyBiryukov
- Status changed from new to reviewing
What's left here?
By Andrew he means me.