This is from the info on the meta tags config form:

Select the vocabularies which contain terms you want to add to the keywords meta tag for nodes. The terms of these vocabularies are added before the global keywords but after the page-specific keywords.

This implies that the order is:
1. page-specific keywords,
2. vocabulary keywords,
3. global keywords.

And this is indeed how it worked in the 5.x module which we just updated from.

But in 6.x-1.11 this happens:

- Global keywords are inserted first before the page-specific ones, rather than appended last.
- Vocabulary keywords do not get inserted at all.

Also we found that the Meta description is no longer auto-populated from the teaser. Even though we have set the auto-generation options to generate from the teaser.

By accident while doing something else I found there were content-type specific auto-generation settings which override the global ones, and every content type had that option disabled without telling us. A week later and google webmaster tools reports 1000s of pages without meta descriptions! There should at least be a visible warning on the global settings page that these auto-generation options are overridden by content-type specific settings.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mr.j’s picture

After emptying caches, playing around a bit, it looks like vocabulary keywords are now being appended.

The order is still wrong:

1. global
2. node-specifc
3. vocabulary

Thomasr976’s picture

I experienced the same thing. Is there anyway to turn this off and just have the node author manually add the meta description and keywords. I tried unchecking the token module and of course on the node administration form the meta description and keyword fields were empty. When I mannually added a meta description/keywords and saved the node, I could not see them when I viewed them in my browser under source. Of course when i edited the node the meta description and keyword fields were empty.

If anyone can suggest a work around please do. Thanks

sahuni’s picture

Waiting for a solution, I suppressed global metatags to have a better render of my specific keywords

Thomasr976’s picture

Can share with me how you supressed the global metatags? Thanks.

sahuni’s picture

On /admin/content/nodewords, I let nothing in the section Global meta tags

quicksketch’s picture

Status: Active » Needs review
FileSize
943 bytes

This patch makes the default meta tags output in the expected order. We will need a more extensive re-architecting to make this work with 3rd-party modules, but a quick fix is just to output the default meta tags in the advertised order. This patch isn't going to hurt anything at it works as advertised, it's a step forward if not a complete solution.

Status: Needs review » Needs work

The last submitted patch, nodewords_global_order.patch, failed testing.

quicksketch’s picture

Version: 6.x-1.11 » 6.x-1.x-dev

Hm, different branch? Should apply just fine.

quicksketch’s picture

Status: Needs work » Needs review
quicksketch’s picture

Patch in Git format.

DamienMcKenna’s picture

Issue tags: +v6.x-1.12 blocker

This should get in the next version.

mr.j’s picture

I just updated to the latest dev release and I see that patch isn't in there.

Anyway what we get now is this on a node, in this order:

1. Global Keywords
2. Taxonomy Keywords

And the node-specific keywords are completely missing.

A quick debug shows that the $content parameter passed to nodewords_basic_keywords_prepare is always an empty array.

Edit: problem solved. There is a bug in nodewords.module:

--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -540,7 +540,7 @@
         return;
       }
       // If the visitor doesn't have access to this node, don't load anything.
-      elseif ($options['type'] == NODEWORDS_TYPE_NODE || node_access('view', node_load($options['id']))) {
+      elseif ($options['type'] == NODEWORDS_TYPE_NODE && !node_access('view', node_load($options['id']))) {
         $tags = array();
       }
       // Otherwise, load the tags for this page.
mr.j’s picture

Status: Needs review » Reviewed & tested by the community

This is still not in the dev version released 30-Oct-2011.

DamienMcKenna’s picture

Status: Reviewed & tested by the community » Fixed

The bug referenced in #12 has been resolved and the patch from earlier was committed.

Status: Fixed » Closed (fixed)
Issue tags: -v6.x-1.12 blocker

Automatically closed -- issue fixed for 2 weeks with no activity.

mw4ll4c3’s picture

Issue summary: View changes
Status: Closed (fixed) » Needs review
FileSize
1.22 KB

This seems to have snuck back in, possibly after 1.12 was scrapped?

DamienMcKenna’s picture

Status: Needs review » Closed (won't fix)

Thank you for taking the time to work on this. However, the module is no longer supported, so I'm closing this issue.