#24010 closed task (blessed) (fixed)
Look into meta key standardization or upgrade with Crowd Favorite's post format UI plugin
Reported by: | markjaquith | Owned by: | |
---|---|---|---|
Milestone: | 3.6 | Priority: | high |
Severity: | normal | Version: | 3.6 |
Component: | Post Formats | Keywords: | has-patch needs-testing |
Focuses: | Cc: |
Description
Crowd Favorite has a reasonably popular and prescient plugin for post format UI, which we used as some inspiration for the feature in 3.6: https://github.com/crowdfavorite/wp-post-formats
Alex King notes that we've slightly changed some of the meta keys here. We should look to see if there is a way that we can standardize, or look into an upgrade strategy.
Attachments (7)
Change History (19)
#2
@
12 years ago
Fair enough point, though I think the keywords in the description is "popular and prescient" - his plugin was (more or less) the catalyst for the entire feature, and . I'd think (and hope) that would change the level of compatibility that we would strive for here. Especially given the fact that those most desirous to use this feature are already doing so with his plugin.
#3
in reply to:
↑ 1
@
12 years ago
Replying to markoheijnen:
Not to be rude but since when do we care to work nicely with other plugins? Isn't it the task for plugins developers to build a upgrade strategy?
When plugins lead the way for a particular feature, we have worked to play nicely. This is particularly the case when we are dealing with content and data, as the upgrade strategies when involving databases are far more, um, interesting.
We haven't done this to a wide scale in a very long time — in part because our features are not often predicated by a particular pioneering plugin, especially one storing a lot of user data. But, some examples include the original Automattic Widgets plugin (~ 2.2), and the tag converters for Ultimate Tag Warrior and Simple Tagging (~ 2.3).
#4
@
12 years ago
- Keywords needs-patch added
Whomever wants this ticket to happen: make a patch. I can't foresee anyone caring one way or another if the key names change
#5
@
11 years ago
I can be wrong but we didn't really used the code of that plugin and I have seen more plugins creating an UI for post formats. Not saying we shouldn't do it. I'm curious now how we did it with 3.0 for menu's.
#6
@
11 years ago
When I pulled in the code that stores slug changes and redirects them (from a plugin I wrote), I changed the meta key to be prefixed with _wp_. But I also write an upgrade routine (in core). See: [4556]. But note that my plugin used a key that was not underscore-prefixed, so that resulted in a material change when I changed the meta key — perhaps a better reason for changing it than we have now.
If there's no major objection, I say we do the following:
- Change the keys back to match the CF plugin ones.
- Put in a temporary routine in to rename them, which we can remove during RC (just as a kindness to people testing trunk/beta). That's the least amount of data churn.
See also #24009.
#8
@
11 years ago
- Keywords has-patch needs-testing added; needs-patch removed
24010.diff this required dramatically altering a fair bit of code - please test
Not to be rude but since when do we care to work nicely with other plugins? Isn't it the task for plugins developers to build a upgrade strategy?