I'm using this token as a default for canonical url:
[metatags-url-alias]

for nodes/users/taxonomy etc the token is replaced properly.. but for panels pages and views pages the token isn't replaced but printed directly - you can see this at:

http://omaha.net/food-and-dining

it looks like this:

<link rel="canonical" href="http://omaha.net/%5Bmetatags-url-alias%5D" />

also - i've create custom meta tags for this page (keywords and description) but neither are printed

thanks for your help!

Comments

Anonymous’s picture

Title: token not replaced for custom pages » Token is not replaced for custom pages

I cannot reproduce this. Whenever I set the default value, or I set the value for the custom page, I always get the value of that token replaced by its value.

Trying with the global tracker page, I get the following meta tags:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <link rel="schema.dc" href="http://purl.org/dc/elements/1.1/" />
<link rel="canonical" href="http://test/tracker" />
<link rel="shorturl" href="bit.ly/1223" />
<meta name="abstract" content="track page" />
<meta name="robots" content="index,follow" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

I will test it with a default view defined from the module Views, and see if that change anything.

locomo’s picture

strange..

i tried out a couple of more things and noticed that even when explicitly specifying the canonical url in the custom meta tag section, the custom value is ignored

so on that same food-and-dining page i've entered "food-and-dining" in the canonical field. i've confirmed that it is saved in the database.. but when viewing the page source i see the same as above (should i open a new issue for this)

<link rel="canonical" href="http://omaha.net/%5Bmetatags-url-alias%5D" />

another thing i noticed is that i can't actually delete these custom page settings.. i click delete and get confirmation that "My configuration options have been saved" - but the entry is still in my list of custom pages and still in my database

lastly regarding tracker pages.. it gets even wierder.. the token is properly expanded on user tracker pages with URLs like (token IS expanded):
user/100/track/navigation

but not on node tracker pages with URLs like (token NOT expanded):
node/796/track

Anonymous’s picture

Status: Active » Fixed

The problem was that the token replacement was tried even when the module was not able to understand the kind of visited page (for which _nodewords_detect_type_and_id() returns NODEWORDS_TYPE_NONE); in that case, node_replace_tokens() doesn't replace any tokens, and that was the reason the token was output.
Then, the custom page listed as tracker is for pages with a path matching tracker, and tracker/*; the patterns can be extended to include other paths.

The code has been changed, and committed in the repository. Thanks for your report.

locomo’s picture

Status: Fixed » Needs work

thanks for working on this so fast.. unfortunately something is still not working

this is what i'm still seeing on pages i've created with panels

<link rel="canonical" href="http://omaha.net/%5Bmetatags-url-alias%5D" />
<meta name="keywords" content="[metatags-taxonomy-keywords]" />
<meta name="description" content="[metatags-description]" />

any ideas?

Anonymous’s picture

It seems a problem related with view pages. I have the same problem with the front page view; for some reasons, tokens are not replaced, in such cases.

Anonymous’s picture

For the front page meta tags, the option Use front page meta tags must be enabled, or tokens are not replaced.

locomo’s picture

I've now got my front page tags displaying properly thanks to your clarification. But all other pages created with panels are still printing the tag itself rather than the value of the tag for description and keywords.

No pressure, but just wondering where this is on your list of priorities? I need to make a determination about which version to go with.

thanks!

Anonymous’s picture

I marked #777510: Canonical URL for front-page is not assigning the Token Value as duplicate of this report.

To reply about the priority of this issue for me, this issue has the same importance for me as other issue had; the problem with this issue is that I cannot reproduce it.

locomo’s picture

Do you have panels installed? If you do I think you should be able to recreate this by creating a page with panels and then try to add custom meta tag settings for that page.

I'm really not seeing any sign that the custom pages meta tags is working

Anonymous’s picture

Tokens work for me, when there are no panels involved. It could be the problem is just that.

locomo’s picture

are you planning on supporting pages created with panels??

this is a crucial issue for me and I would imagine many users for this module.. there seem to be a lot of people having trouble with tokens not printing on custom pages

locomo’s picture

okay - this is very crude.. but could be the start of support for panels pages - its working for me right now with the current dev release

function _nodewords_detect_type_and_id() {
  $arg = arg();

  if (variable_get('site_offline', 0) && !user_access('administer site configuration')) {
    return array('type' => NODEWORDS_TYPE_OFFLINE, 'id' => 0);
  }
  // **** start new code ****
  // check if this is a panels page
  $page = page_manager_get_current_page();
  if ($page) { 
    // is the panel page path in nodewords_custom table ?
    // try to get pid
    $id = db_result(db_query_range(
      'SELECT pid FROM {nodewords_custom} WHERE path = "%s"', $page['subtask']['admin path'], 0, 1
    ));
  if ($id) {
    return array('type' => NODEWORDS_TYPE_PAGE, 'id' => $id);
  }
}
// **** end new code ****

  $headers = drupal_get_headers();
snorkers’s picture

I've got this problem on 6.x-1.12beta9 (which I'm assuming was taken from DEV on 18 Apr 10), but do not have Panels installed. I'm still getting an incorrect Canonical URL for any Views-generated pages: the token itself is becoming part of the URL (as mentioned earlier, outputs as <link rel="canonical" href="http://www.example.com/%5Bmetatags-url-alias%5D" />).
Only way round it at the moment is to manually create META tags in the 'Custom Pages Meta Tags' option.

1mundus’s picture

I'm experiencing the same problem with views on beta-12. I'm not using panels with the mentioned token. The problem is that I have hundreds of views and I can't manually add their canonicals.

Vuds’s picture

I can also confirm that (and I'm not using panels). Canonical URL is not working for Views pages neither for the front page in my website.

I'm using DEV from May/11.

twod’s picture

The change made in #3 (Which I assume is http://drupalcode.org/viewvc/drupal/contributions/modules/nodewords/node...) looks incorrect:

The code

function nodewords_preprocess_page(&$variables) {
  $output_tags = array();

  $head_tags = variable_get('nodewords_head', array());
  $options = nodewords_detect_type_id();

if ($options['type'] != NODEWORDS_TYPE_OFFLINE) {
   // nodewords adds the metags

was changed to

function nodewords_preprocess_page(&$variables) {
  $output_tags = array();

  $head_tags = variable_get('nodewords_head', array());
  $options = nodewords_detect_type_id();

  $bool = (
    $options['type'] != NODEWORDS_TYPE_NONE ||
    $options['type'] != NODEWORDS_TYPE_OFFLINE
  );
  if ($bool) {

This will cause $bool to always be true as any type will be either "not none" or "not offline".
No page type will ever be "none" and "offline", as nodewords_detect_type_id() only sets one type.

Shouln't this be

  $bool = (
    $options['type'] != NODEWORDS_TYPE_NONE && //<---
    $options['type'] != NODEWORDS_TYPE_OFFLINE
  );

If the page type is "none" or "offline", $bool will be false and Nodewords ignores that page.
This way, no default tags are added for /user, /guestbook /whaterver_else_that_is_not_a_known_page.

locomo’s picture

for the specific case of a page generated by views i still can't get any meta tags to appear

the change in #16 helps a bit in that this no longer appears:

<link rel="canonical" href="http://omaha.net/%5Bmetatags-url-alias%5D" />
<meta name="keywords" content="[metatags-taxonomy-keywords]" />
<meta name="description" content="[metatags-description]" />

yay and thanks!

but with this fix, when i create a custom page for a views page meta tags still do not appear

Anonymous’s picture

The code was not correct as the meta tags were added even when the module was not able to understand the type of the viewed page ( NODEWORDS_TYPE_NONE) or when the site was offline (NODEWORDS_TYPE_OFFLINE); in those case, the condition $options['type'] != NODEWORDS_TYPE_NONE || $options['type'] != NODEWORDS_TYPE_OFFLINE is always true (NODEWORDS_TYPE_NONE <> NODEWORDS_TYPE_OFFLINE).

I changed the code, and committed it in the development branch. Thanks to TwoD for the help.

locomo’s picture

Cool - that solves part of the problem.

Any new ideas why the module can't "understand" that a page was created by views and to add meta tags when a custom page has been created?

Anonymous’s picture

Project: Nodewords: D6 Meta Tags » Meta tags tokens
Version: 6.x-1.x-dev »

I am moving the report to the project that will handle meta tags tokens in the next official release of Nodewords.

Anonymous’s picture

I have marked #817356: [metatags-description] not working as duplicate of this report.

Anonymous’s picture

Status: Needs work » Active
jcisio’s picture

Project: Meta tags tokens » Nodewords: D6 Meta Tags
Version: » 6.x-1.12-beta9

I don't have access to http://drupal.org/project/metatags_tokens project. Problem? Then I move to nodewords.module, as it seems all code is there. I'll move it back when it is published.

In 6.12b9 I don't have "Use front page meta tags" option as instructed in #6. Token is not replaced in my frontpage (which in turn is a Panels custom page).

modctek’s picture

subscribing

damienmckenna’s picture

Version: 6.x-1.12-beta9 » 6.x-2.x-dev

This now belongs to the v6.x-2.x codebase.

damienmckenna’s picture

Status: Active » Postponed

Marking all v2 issues as postponed while v1 is finished off.

damienmckenna’s picture

Issue summary: View changes
Status: Postponed » Closed (won't fix)

Unfortunately this module is no longer supported, so I'm closing this issue.