Make WordPress Core

Opened 12 years ago

Last modified 3 years ago

#20194 new feature request

Add Description meta to General Settings

Reported by: jane's profile jane Owned by:
Milestone: Awaiting Review Priority: normal
Severity: minor Version: 3.3
Component: General Keywords: needs-patch ongoing
Focuses: Cc:

Description (last modified by jane)

Add a description field to General Settings b/c these days with themes doing all kinds of kooky things, the automatic excerpt is often not representative of the site content. All the SEO-lovers will be happy, searchers will get more accurate results, and it's a nice end-user feature without high overhead.

Could have sworn I made a ticket like this once before, but can't find it in search, so if anyone remembers it/is better at searching trac than I just was, go ahead and close this as duplicate.

Attachments (3)

20194.diff (5.0 KB) - added by Otto42 12 years ago.
First try at a patch
20194_metadescription.diff (9.5 KB) - added by brianlayman 12 years ago.
20194.2.diff (5.1 KB) - added by Otto42 12 years ago.
Adds automatic use of excerpt for the description on singulars.

Download all attachments as: .zip

Change History (43)

#1 @jane
12 years ago

  • Description modified (diff)

#2 @Ipstenu
12 years ago

  • Cc ipstenu@… added

#3 @scribu
12 years ago

How would this be different from the Tagline setting we already have? which BTW is internally called 'blogdescription'.

Last edited 12 years ago by scribu (previous) (diff)

#4 @brianlayman
12 years ago

The one problem with this is that back in the old days, tagline was called the "Blog description". It's saved to the options table "blogdescription". To distinguish between the existing tagline/blogdescription and the new one, I'm making the new option name "metadescription".

Does that make sense?

#5 @brianlayman
12 years ago

Yeah Scribu is addressing the same issue. The main difference is that the tagline has morphed into a visual thing, compared to the description which can likely be longer and only appears in the source as meta.

#6 follow-up: @brianlayman
12 years ago

Should we define a default value to be replaced:

This site provides information about this, that and the other.

#7 in reply to: ↑ 6 @ericmann
12 years ago

Replying to brianlayman:

Should we define a default value to be replaced:

This site provides information about this, that and the other.

Not a big fan of a default. I'd default to "" but make the page output filterable. (Just thinking out loud though.)

@Otto42
12 years ago

First try at a patch

#8 @Otto42
12 years ago

Attached patch adds the field on settings->general, whitelists the option (named "site_description"), adds two new functions "the_description" and "get_the_description" for use by themes, adds new filters for both, has the option for meta output or "html" output (which is really just returning the option bare for the moment), and adds a new default filter to wp_head to call the_description function, thus outputting the meta tag in the header.

Good enough? Or is more needed?

Last edited 12 years ago by Otto42 (previous) (diff)

#9 follow-up: @Otto42
12 years ago

Thinking out loud here, it might be good to auto-disable this or switch it to using the_excerpt on singular pages. Easily added if desired.

#10 @ericmann
12 years ago

Good looking patch. Smooth, and I don't see a need to force the_excerpt on single pages.

#11 @joostdevalk
12 years ago

I'll be honest, I've got mixed feelings about this. The way it's implemented now, each page would have the same meta description, which is a bad idea. This is the Google documentation for why that's a bad idea: each page should have a different description.

However, having core output the meta description, with a filter in place, would make me happy as a plugin developer as that would mean themes would finally stop doing it. The same goes for meta robots and canonical etc. However, as it is right now, a definite -1 from one of the "SEO lovers".

Last edited 12 years ago by joostdevalk (previous) (diff)

#12 in reply to: ↑ 9 ; follow-up: @joostdevalk
12 years ago

Replying to Otto42:

Thinking out loud here, it might be good to auto-disable this or switch it to using the_excerpt on singular pages. Easily added if desired.

That's not a good idea either, you'd be better of without a description in that case. See link above.

#13 @joostdevalk
12 years ago

  • Cc joost@… added

#14 in reply to: ↑ 12 ; follow-up: @Otto42
12 years ago

Replying to joostdevalk:

Replying to Otto42:

Thinking out loud here, it might be good to auto-disable this or switch it to using the_excerpt on singular pages. Easily added if desired.

That's not a good idea either, you'd be better of without a description in that case. See link above.

Umm. Your link says the exact opposite.

Programmatically generate descriptions. For some sites, like news media sources, generating an accurate and unique description for each page is easy: since each article is hand-written, it takes minimal effort to also add a one-sentence description.

The excerpt is a separate field, which can be generated or manually put in by the user. The excerpt is perfect to use in a description tag.

@Otto42
12 years ago

Adds automatic use of excerpt for the description on singulars.

#15 @brianlayman
12 years ago

I've attached the patch that I worked on too. Reviewing the two, my implementation is very similar to Otto's.

The main differences are:

  • Otto used a textarea vs edit field.
  • The name site_description vs metadescription (I thought of using sitedescription, but did not to avoid any multi-site confusion, but since its now site/network vs blog/site that's moot)
  • In the filters Otto used the type 'meta' and I don't think that is used anywhere else. I stuck with html, xhtml & comment.
  • His filter is added a little higher.
  • I don't return any html/whatever if there is no value stored for the description.
  • I added a description to the help in the help.
  • I added XMLRPC support (untested)
  • I added stub for a default value so that we could find it later if we decided to have a default value, but that likely will be dropped.

I think that's it.

Last edited 12 years ago by brianlayman (previous) (diff)

#16 @mbijon
12 years ago

  • Cc mike@… added

+1 to Otto's use of types 'html' & 'meta'. If we don't add meta, then I'd like some way to get the description's string back out (a 'text' or 'raw' type?). It seems inevitable that someone will create a frontend convention for this string or find some SEO value for it against an algorithm.

If we use Brian's 'html' & 'xhtml' types, this might match the current get_the_meta_description() (line 2284-9) code style better:

case 'html': 
case 'xhtml': 
    $desc = '<meta name="description" content="' . esc_attr( $rawdescription ) . '">'; 
    break;

#17 @brianlayman
12 years ago

I echoed the verbose example of the generator code right above that section. It also returns a meta tag. If we do add a meta type, we should adjust that code too.

It should be noted that you can get at the text/raw data through bloginfo with both patches (or through get_option() or by adding a custom filter to your them for the custom type).

#18 @kovshenin
12 years ago

@Otto42 just a tiny note regarding your patch, don't forget to change <label for="home"> to <label for="site_description"> in options-general.php or to whatever is the id of the input field :)

#19 @kovshenin
12 years ago

  • Cc kovshenin@… added

#20 in reply to: ↑ 14 ; follow-up: @joostdevalk
12 years ago

Replying to Otto42:

Replying to joostdevalk:

Replying to Otto42:

Thinking out loud here, it might be good to auto-disable this or switch it to using the_excerpt on singular pages. Easily added if desired.

That's not a good idea either, you'd be better of without a description in that case. See link above.

Umm. Your link says the exact opposite.

Programmatically generate descriptions. For some sites, like news media sources, generating an accurate and unique description for each page is easy: since each article is hand-written, it takes minimal effort to also add a one-sentence description.

The excerpt is a separate field, which can be generated or manually put in by the user. The excerpt is perfect to use in a description tag.

A handfilled excerpt would be awesome, what I object to is the first paragraph of the post :) descriptions only show up in Google when they contain the keyword that someone searched for. Believe me, as soon as you do it like this, you'll get tons of questions about why the meta description isn't showing up...

The other issue is that MANY themes use the excerpt for the front page or other index type pages and they need more text than the 155 chars you'd want in a meta description...

#21 @alex-ye
12 years ago

I've got mixed feelings about this , there is no need for your idea , let the freedom to themes/plugins developers.

#22 @toscho
12 years ago

  • Cc info@… added

A new field may be okay, a default filter for wp_head will result in many sites having two descriptions. Wait for …

    add_theme_support( 'automatic-description' );

… and don’t just throw some markup into the pages.

#23 in reply to: ↑ 20 ; follow-ups: @Otto42
12 years ago

Replying to joostdevalk:

descriptions only show up in Google when they contain the keyword that someone searched for.

Yeah, that's just false. Sorry, but not close to correct, at all. I can prove this incorrect with every single search I do.

The other issue is that MANY themes use the excerpt for the front page or other index type pages and they need more text than the 155 chars you'd want in a meta description...

You know, this is the problem I have with like 95% of the "SEO" crap out there. They're literally making stuff up out of nothing.

Where, exactly, did you get the "155 chars" from? It's in no standards document. There's nothing preventing you from putting more than that into there. There's nothing anywhere on Google's site that says "we only read the first 155 chars".

Basically, the notion that 155 is what you want is complete nonsense. You're extrapolating a "best practice" from anecdotal BS and from what Google currently does on some sites that you've witnessed.

If there was valuable information beyond 155 chars, then Google would take advantage of it. The problem with "SEO" is that it's too limiting. It relies on the current practices of search engines and doesn't have any sort of notion of creating what's best for people. Create what's best for people and for *sanity* and Google will change their algorithms to accommodate it.

We should NOT be programming our code to accommodate what Google does. We should be programming it to be *correct*, and then let Google adapt to US.

Last edited 12 years ago by Otto42 (previous) (diff)

#24 in reply to: ↑ 23 ; follow-up: @alex-ye
12 years ago

Replying to Otto42:

Where, exactly, did you get the "155 chars" from? It's in no standards document. There's nothing preventing you from putting more than that into there. There's nothing anywhere on Google's site that says "we only read the first 155 chars".

Don't be so sensitive about the "155" , In short joostdevalk mean is :
Most of WordPress users use the tagline option for just 10 or less words and this is doesn't enough to create a complete description meta tag .

Another point in the patch above , Is the duplicated description meta , it is mean the same description for many pages like home sub-pages , taxnomy archive ... etc

I think it's not correct ,Simply Let the freedom to themes/plugins developers.

Last edited 12 years ago by alex-ye (previous) (diff)

#25 @swissspidy
12 years ago

  • Cc hello@… added

#26 in reply to: ↑ 24 ; follow-up: @chipbennett
12 years ago

Replying to alex-ye:

Another point in the patch above , Is the duplicated description meta , it is mean the same description for many pages like home sub-pages , taxnomy archive ... etc

I think it's not correct ,Simply Let the freedom to themes/plugins developers.

This change will actually facilitate Themes, Plugins, and core playing nicely together. It will provide a standardized means for Themes to present site content, and for Plugins to extend core's default generation of content.

+1 to the underlying intent of the ticket, though from a purely bikeshed perspective, I prefer metadescription to sitedescription (though, that may be more semantic than bikeshed, since on single posts and static pages, the meta description would presumably be specific to the page, rather than to the site as a whole).

#27 in reply to: ↑ 26 @alex-ye
12 years ago

Replying to chipbennett:

+1 to the underlying intent of the ticket, though from a purely bikeshed perspective, I prefer metadescription to sitedescription (though, that may be more semantic than bikeshed, since on single posts and static pages, the meta description would presumably be specific to the page, rather than to the site as a whole).

1+ to add SiteDescription option only , we don't need to add description meta .

#28 @hd-J
12 years ago

  • Cc jeremy@… added

#29 @sirzooro
12 years ago

  • Cc sirzooro added

#30 @jamalorg
12 years ago

  • Cc jmlworld@… added

#31 in reply to: ↑ 23 ; follow-up: @joostdevalk
12 years ago

Replying to Otto42:

Replying to joostdevalk:

descriptions only show up in Google when they contain the keyword that someone searched for.

Yeah, that's just false. Sorry, but not close to correct, at all. I can prove this incorrect with every single search I do.

The other issue is that MANY themes use the excerpt for the front page or other index type pages and they need more text than the 155 chars you'd want in a meta description...

You know, this is the problem I have with like 95% of the "SEO" crap out there. They're literally making stuff up out of nothing.

Where, exactly, did you get the "155 chars" from? It's in no standards document. There's nothing preventing you from putting more than that into there. There's nothing anywhere on Google's site that says "we only read the first 155 chars".

Basically, the notion that 155 is what you want is complete nonsense. You're extrapolating a "best practice" from anecdotal BS and from what Google currently does on some sites that you've witnessed.

If there was valuable information beyond 155 chars, then Google would take advantage of it. The problem with "SEO" is that it's too limiting. It relies on the current practices of search engines and doesn't have any sort of notion of creating what's best for people. Create what's best for people and for *sanity* and Google will change their algorithms to accommodate it.

We should NOT be programming our code to accommodate what Google does. We should be programming it to be *correct*, and then let Google adapt to US.

I've waited for days to respond to this because I got incredibly mad with how you treat me, a member of your community who just tries to do well and weighed in when Nacin asked me to. How would you appreciate it if I called your job "crap"? How is it an argument what you think if it's not based on experience and research?

You're adding an SEO feature, whether you like it or not. You can do it well, you can do it wrong, as long as you add the proper filters, I'll make my plugin handle it. Whatever you think you've seen in search results doesn't count. I test these things on a regular basis and I don't think. I know.

Anyway, I'd appreciate an apology. I'm not making stuff up out of nothing and I'm not going to stand here and be insulted.

#32 in reply to: ↑ 31 @Otto42
12 years ago

Replying to joostdevalk:

Anyway, I'd appreciate an apology.

I apologize if you felt personally insulted by my statements. That was not my intent.

However, I do indeed think that almost all SEO is "crap" and I will not apologize for that. I take issue with the idea and concept of SEO itself and many of the unbacked, unsupported, and non-evidence-based practices I see in that industry.

I will not apologize for what I believe to be true, no matter how much it upsets you. Again, this is not an indictment against you personally.

I'm not making stuff up out of nothing and I'm not going to stand here and be insulted.

Then please, by all means, prove me wrong. It's easily doable.

But if you're going to make a statement about what's "best" for SEO, then you had better prove it, because I will question your statement, pick it apart, and tell you that you're wrong... Unless you prove it.

#33 @chriscct7
9 years ago

  • Keywords close added

There are a ton of plugins for doing SEO and making the long description used by it. For example Yoast's SEO plugin or All in One which completely solve the problem of themes doing_things_wrong(). Seems invalid as an issue

#34 @helen
9 years ago

I'm not sure I see a way forward in core - certainly people care very much about this topic, as evidenced by the popularity of plugins that do this and do it quite well. Putting aside all the "what it do" stuff, what area would core need to cover for this to be something applicable beyond the homepage, and how would we play nice with plugins and even themes? Is this something that most users need to see in their UI? That's not a question of validity - it's a question of general usage.

#35 @BrianLayman
9 years ago

Improving a simple WordPress site's appearance in search results is a good thing and is a general usage improvement. Users shouldn't have to know what SEO means and get plugins or special themes to use a basic technique that's been around for longer than WordPress has. If the user has put in a custom post excerpt, that's what should appear in search engines when they describe the page.

This should be a guide in the implementation:
https://www.youtube.com/watch?v=W4gr88oHb-k#t=70

If this wouldn't have blown up with an argument over a side detail, we could have gotten this in back in 2012. Maybe by now we do need a checkbox to enable this behavior; I don't know. I do still think this is basic functionality should be core. I'm not going to the mat for this, but it IMHO SHOULD have been so years ago.

#37 @wonderboymusic
8 years ago

  • Keywords ongoing added; close removed

I like the discussion here, want to make sure it isn't buried in the Close pile

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


7 years ago

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


3 years ago

Note: See TracTickets for help on using tickets.