Make WordPress Core

Opened 9 years ago

Last modified 3 years ago

#31387 assigned enhancement

New core API for adding Meta tags to the header

Reported by: georgestephanis's profile georgestephanis Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: General Keywords: 2nd-opinion needs-patch
Focuses: template Cc:

Description

There is often a conflict between one or more plugins about registering meta tags in the header. Meta tags that shouldn't be duplicated, it's difficult to know which one should 'win'. A lightweight framework in core that multiple plugins could use to register meta tags seems like it would be useful.

It would need to handle several different attributes for all use cases -- name property http-equiv charset -- possibly generic data-* attributes? Uncertain.

Twitter discussion: https://twitter.com/nacin/status/562109983069061120 (up and down the thread)

My first swing at it:

https://gist.github.com/georgestephanis/0f0cca2c5f1a6cd4aab2

Change History (13)

#1 @georgestephanis
9 years ago

  • Summary changed from New core API for adding Meta boxes to the header to New core API for adding Meta tags to the header

#2 @joostdevalk
9 years ago

+1 from me!

#3 @pento
9 years ago

  • Component changed from Themes to General
  • Keywords dev-feedback removed
  • Version trunk deleted

Ignoring the implementation for the moment (which @nacin has some opinions on... ;-) ) I think we need to look at this from the perspective of the problems we’re trying to solve.

  • How to do allow a single plugin to be the authority for a particular set of meta tags?
  • How do we define a group of related meta tags, or related groups? (i.e., there is overlap between OG and TwitterCard tags, but neither is a 100% subset of the other.)
  • If a plugin provides a certain set of meta tags (say, a plugin providing OG tags), how do we allow another plugin to selectively override some of those tags (say, Jetpack providing Photon support for og:image)?
  • How do we define which tags there can only be one copy of, and those that can have multiple instances?
  • Do we need to care about other header tags?
  • What about different tags with the same or similar meaning? Ie, <meta name=“author”> vs <link rel=“author”>, or whatever the next dominant search engine decides will be the canonical way to identify authorship?

And regarding implementation:

  • How do we keep this backwards compatible, with plugins that will update to using this new method, with plugins that won’t, and with themes that may never be updated?
  • How do we do all this, while keeping the public API simple to use?

My primary concern is that a lightweight framework will suffer from the same problems we currently have, where a more complex framework won't be lightweight any more.

I'd also really like to see some more specific use cases - I haven't hit this problem before, so I'm running on a lot of speculation and guessing. :-)

#4 @joostdevalk
9 years ago

There are several well maintained plugins (Jetpack, Facebook's, our WP SEO, etc) that run into this problem. If we could encourage people to switch to this API and at the .org level maybe prevent new plugins from using straight echoes, we could prevent a whole lot of issues.

One thing I'm thinking now is it'd be nice to add the originating plugin to the call, so you could easily debug why your og: output is being overridden.

As for the problem we're trying to solve: multiple meta descriptions, og:descriptions, etc on a page.

One bug in the current implementation: some tags actually could validly be there multiple times. There are, for instance, reasons to have several og:image tags...

#5 @georgestephanis
9 years ago

Yup, realized that afterwards (re duplicate tags)

I'm also not 100% happy with how I'm specifying the type of tag (the awkward way of handling charsets in there comes to mind) -- perhaps we could ignore http-equiv meta tags entirely and just have it default to name unless it starts with og: and then swap to property?

I'd sooner run off a static than a global variable personally, but it's more personal preference than anything I'd really fight over.

I'm not sure the ideal way to specify the plugin generating it ... maybe an optional FILE parameter? Running debug_backtrace to snag the calling file doesn't feel right.

#6 @joostdevalk
9 years ago

If you know the calling plugin you could decide to override based on that...

This ticket was mentioned in Slack in #forums by georgestephanis. View the logs.


9 years ago

#8 @swissspidy
8 years ago

  • Keywords needs-patch added

#9 @swissspidy
7 years ago

  • Owner set to swissspidy
  • Status changed from new to assigned

Document titles in 4.4 come to mind here: https://make.wordpress.org/core/2015/10/20/document-title-in-4-4/
Resource Hints as well: https://make.wordpress.org/core/2016/07/06/resource-hints-in-4-6/

As for the problem we're trying to solve: multiple meta descriptions, og:descriptions, etc on a page.

+1

How to do allow a single plugin to be the authority for a particular set of meta tags?

Hook priorities?

How do we define a group of related meta tags, or related groups?

(Why) is that needed?

How do we keep this backwards compatible, with plugins that will update to using this new method, with plugins that won’t, and with themes that may never be updated?

Thinking of add_theme_support() here.

If a plugin provides a certain set of meta tags (say, a plugin providing OG tags), how do we allow another plugin to selectively override some of those tags (say, Jetpack providing Photon support for og:image)?

My first thought was a simple key=>value array.

How do we define which tags there can only be one copy of, and those that can have multiple instances?

A whitelist of such tags, maybe almost a simple schema.

What about different tags with the same or similar meaning?

If we only provide an API, this would be up to the SEO plugins.

#10 @swissspidy
7 years ago

See also #20194. A description field could be added to the settings screen or customizer when the theme did use add_theme_support()

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


7 years ago

#13 @swissspidy
3 years ago

  • Owner swissspidy deleted
Note: See TracTickets for help on using tickets.