WordPress.org

Make WordPress Core

Opened 16 months ago

Last modified 2 months ago

#50165 new defect (bug)

Synchronize get_theme_feature_list() with the Theme Directory

Reported by: SergeyBiryukov Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.9
Component: Themes Keywords:
Focuses: administration Cc:

Description (last modified by SergeyBiryukov)

[41648] removed a bunch of theme features from get_theme_feature_list():

  • BuddyPress
  • Custom Menu
  • Flexible Header
  • Front Page Posting
  • Microformats
  • RTL Language Support
  • Threaded Comments
  • Translation Ready

This resulted in the core list being out of sync with the Theme Directory, and in these strings not being translated when returned from the Theme Directory API.

[42003] then disabled the API call on Add Themes screen "due to inconsistencies and to ensure tags are translated".

With that change, every instance of get_theme_feature_list() as of WordPress 4.9 no longer calls the API and just returns the hardcoded list. One exception is the instance in install_themes_dashboard(), however that function is not used anywhere.

It's not quite clear whether the removing was intentional, as I could not find any justification in the linked tickets. These features are still displayed in Theme Directory filters and are returned in the API response.

If it was indeed intentional, let's update the Theme Directory to match.

If not, let's update the core list to match the Theme Directory.

Change History (11)

#1 @SergeyBiryukov
16 months ago

In 47794:

Docs: Add @since notes for theme features added or removed in get_theme_feature_list() after its introduction in WordPress 3.1.

See #50165.

#2 @SergeyBiryukov
16 months ago

Relevant changesets, for reference:

  • [18327]
    • Added 'Gray' color and 'Featured Image Header', 'Featured Images', 'Full Width Template', and 'Post Formats' features.
  • [21604]
    • Added 'Flexible Header' feature.
  • [26658]
    • Added 'Accessibility Ready' feature.
  • [26711]
    • Renamed 'Width' filter to 'Layout'.
    • Renamed 'Fixed Width' and 'Flexible Width' options to 'Fixed Layout' and 'Fluid Layout'.
  • [28037]:
    • Combined 'Layout' and 'Columns' filters.
  • [37287]:
    • Removed 'Colors' filter.
    • Added 'Grid Layout' option.
    • Removed 'Fixed Layout', 'Fluid Layout', and 'Responsive Layout' options.
    • Added 'Footer Widgets' feature.
    • Removed 'Blavatar' feature.
    • Added 'Blog', 'E-Commerce', 'Education', 'Entertainment', 'Food & Drink', 'Holiday', 'News', 'Photography', and 'Portfolio' subjects.
    • Removed 'Photoblogging' and 'Seasonal' subjects.
  • [37945]
    • Added 'Custom Logo' feature.
  • [41648]
    • Reordered the filters from 'Layout', 'Features', 'Subject' to 'Subject', 'Features', 'Layout'.
    • Removed 'BuddyPress', 'Custom Menu', 'Flexible Header', 'Front Page Posting', 'Microformats', 'RTL Language Support', 'Threaded Comments', and 'Translation Ready' features.
  • [47790]
    • Added 'Block Editor Styles' feature and 'Wide Blocks' layout option.
  • [47797]
    • Added 'Block Editor Patterns' and 'Full Site Editing' features.
Last edited 16 months ago by SergeyBiryukov (previous) (diff)

#3 in reply to: ↑ description @SergeyBiryukov
16 months ago

  • Description modified (diff)

#4 @dd32
16 months ago

[42003] then disabled the API call on Add Themes screen "due to inconsistencies and to ensure tags are translated".

It sounds like the features were removed from Core, but not from WordPress.org, which resulted in the inconsistency in the list of tags.

The intention behind pulling from the API was so that new tags could be removed/added from WordPress.org and have it show up within core.
I believe the idea was that Core would always add a tag before it was removed from WordPress.org's API (Which is why it was version-gated) so that translations would just work.
It was planned that the API would return translations in future, but that was never implemented.

I'm assuming [41648] was made without that knowledge, which is why the follow up commit was made.

#5 @SergeyBiryukov
14 months ago

  • Milestone changed from 5.5 to 5.6

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


11 months ago

#7 follow-up: @johnbillion
11 months ago

  • Keywords 2nd-opinion added
  • Milestone changed from 5.6 to Future Release

@dd32 What's the preferred fix here? Re-align core's list of features with those of the API?

#8 in reply to: ↑ 7 @dd32
11 months ago

Replying to johnbillion:

dd32 What's the preferred fix here? Re-align core's list of features with those of the API?

I would probably suggest realigning with the API, but before doing so, realigning dotorg/API to what Core expects and wants..
so I guess the answer is really, "Make sure WordPress.org/themes is up-to-date with Core."

#9 in reply to: ↑ description @SergeyBiryukov
3 months ago

  • Keywords 2nd-opinion removed

Replying to SergeyBiryukov:

If it was indeed intentional, let's update the Theme Directory to match.

If not, let's update the core list to match the Theme Directory.

Looks like it was intentional after all, as explained in this commit, later included in [41648]:

Rework feature filters in core and dettach from .org API
Place subject filters first, then features, then layouts. Aggressively remove tags from the list that do not provide significant value to the average users. Reasons for removal include: tags that apply to most themes, tags that apply to few enough themes that (roughly) more than half of the results are themes abusing the tag list that should not have the tag, tags that are confusing or unclear to a typical user, tags for features that most themes provide. Detach the .org API from the theme list and only use the list provided in core; we can reconcile the core and .org feature lists the next time the .org directory is reworked.

So apparently the Theme Directory and the API should be updated to match the list in WordPress 4.9+, then the API call can be reinstated in core.

#10 @poena
2 months ago

Hi
I started on this, but I have a question.

Are there no consequences to removing older, now unused items from the feature list in the theme directory Themes API Class?

Can they be removed safely, to make the feature list match the list in WordPress core?

Last edited 2 months ago by poena (previous) (diff)

#11 @poena
2 months ago

Does it need to be a new, separate meta issue?

Note: See TracTickets for help on using tickets.