Hello,
I am using Nodewords 6.x-1.11 together with Nodewords Node Type at the moment.
As 6.x-1.12 Beta 9 finally has token replacement, I am interested in updating to that version and deinstall Nodewords Node Type. So I tested the new version today...
It generally works, but the token replacement list in the custom pages area is missing lots of tokens (compared to the list offered in Nodewords Node Type). For example, there are no “CCK text” or “Location“ Tokens. Of course, these tokens are not only missing in that list, but they are not replaced either. As I use these tokens very much in my metatags keywords and descriptions, this is a big problem for me.
Will these Tokens be supported in the future? Or is there a patch available that makes Beta 9 handle these tokens?
Thanks.
| Comment | File | Size | Author |
|---|---|---|---|
| #39 | 781440-token-replace-context-followup.patch | 10.15 KB | dave reid |
| #37 | 781440-nodewords-token-followup.patch | 9.69 KB | dave reid |
| #33 | nodewords-n781440-29.patch | 3.61 KB | damienmckenna |
| #32 | nodewords-n781440-29.patch | 3.61 KB | damienmckenna |
| #29 | nodewords-n781440-29.patch | 3.61 KB | damienmckenna |
Comments
Comment #1
Druppy-dupe commentedI have the same problem:
I use custom pages meta tags to create meta tags for all nodes in the path news/*.
Only the global tokens are replaced at the moment. All node-based tokens are not working and are not in the replacement list.
This should be changed as soon as possible.
Comment #2
Anonymous (not verified) commentedActually, there is a wrong call to
theme('token_help')in the other module.Without giving a value for
$type, the theme function will consider the value'all', which means the list of tokens will include all the tokens, even the ones that the module will not use because it callstoken_replace()passing a node as object.Comment #3
summit commentedSubscribing, would love to see the arg() tokens also supported!
greetings,
Martijn
Comment #4
Anonymous (not verified) commentedIf those tokens are added as global tokens, then Nodewords is able to use them. If they are added as a category apart (I mean different from the usual categories like node, user, etc), then Nodewords cannot use them, with the actual code.
Comment #5
Brian294 commentedThis patch doesn't work; see what reported in comment #7.
I have attached the .patch and nodewords.module (zipped) using the -dev version dated 6/15. This also addresses the feature request #837108 (http://drupal.org/node/837108) to provide better token integration with the nodewords_pagetitle module.
Comment #6
Brian294 commentedThe code contained in this archive doesn't work as expected; see comment #7.
For anyone using beta9, here is the nodewords.module file you can use that will give you more token options for your custom pages.
Comment #7
Anonymous (not verified) commentedThe patch in #5 is not in the correct format; see http://drupal.org/patch/create to understand how a patch is created.
The code as changed from the patch doesn't work.
In the case of custom pages,
$options['id']is not a user ID, nor a node ID; the calls to_nodewords_node_load($options), anduser_load($options['id'])would return a random node, and a random user object that are not related with the page being viewed.Comment #8
Brian294 commentedYes, you're correct with all of those observations. A perfect patch would need to take into consideration the type of path being accessed and then make sure only the relevant tokens are being loaded. This patch makes the assumption that the person creating the custom page knows which tokens are appropriate. For example, I would never use the user tokens if I am building a custom page for a node.
I'll give some more thought into how to address this issue.
Comment #9
Brian294 commentedkiam,
Here is the revised code that will address the issue. I unfortunately could not create a cvs patch because the "HEAD" for nodewords appears to be radically different from the current -dev version. Perhaps I'm doing cvs wrong. Let me know which tag I should be using in CVS for patching.
Anyway, review the code starting a line 589 to see how I address the token loading issue.
Peace,
Brian
Comment #10
Brian294 commentedI think I figured it out! DRUPAL-6--1 should be used, yes? Here is the patch.
Comment #11
Anonymous (not verified) commentedThe patch is still using
$options, but for custom pages that array doesn't contain any node ID, nor user ID.Comment #12
Brian294 commentedkiam, I think this is because of a bug in how custom pages are handled in -dev. See:
http://drupal.org/node/835158#comment-3142624
Arguments are not returning correctly because the following file and function are missing:
nodewords_custom_pages\includes\nodewords_custom_pages.nodewords.hooks.inc
-> nodewords_custom_pages_nodewords_type_id()
Comment #13
Brian294 commentedComment #14
Anonymous (not verified) commentedFor some strange reason, the file has been removed from CVS, but it was still present in my local repository from where I commit the code. Thanks for pointing out that.
As per the patch, it is not correct yet. Let me see if I make myself clear.
The array
$optionsreturned by the module nodewords_custom_pages.module contains information about the custom page; in particular,$options['id']is the identifier associated with the custom page, the same value that is saved in the module table.node_load()doesn't make sense.user_load()doesn't make sense.I hope it's clear what I mean.
Comment #15
Anonymous (not verified) commentedTo be sure to be clear enough, I will make an example.
Comment #16
Brian294 commentedkiam, you're right. my tests were faulty! grrrr. I will submit a patch to address the issue in dev sometime later tonight.
Comment #17
Brian294 commentedI have attached a revised patch that should fix the issue. It also takes into consideration other arg(0) parameters that I previously overlooked. Patch is for latest -dev release.
Comment #18
Brian294 commentedComment #19
rjbrown99 commented#17 worked for me on the latest dev. Cleanly applied, tokens show up, and they work. Thanks.
Comment #20
summit commented#17 worked for me also.
greetings, Martijn
Comment #21
wxman commented#17 worked for me. Of course I had already torn all my hair out trying to find a workaround before I read all this. I'm using Pressflow by the way.
Comment #22
Mercury500 commentedCan somebody please post a nodewords.module patched from #17?
This whole patching thing is crazy. Why not just post the file? Why force everybody to go thru extra hoops to get a few lines changed? Yes, in general, post the patch file for developers, but the changed FILES also.
Comment #23
rjbrown99 commented#22: Here are directions for applying a patch.
http://drupal.org/patch/apply
If there are bugs, enhancements, or fixes, creating a patch is the standard mechanism to report those changes to the module developer. This is why there are recommended releases vs development releases - if users don't want to hassle over patches, just use the release version of the code. Using the development branches means you also wade into the world of patches and diffs.
I'm also moving this to RTBC because of multiple positive replies.
Comment #24
Mercury500 commentedThanks. I know how to apply a patch. It's just grossly inefficient for things like this. there is "getting things done" and there is "playing developer / programmer." I frequently just need to get things done.
And using the recommended releases is frequently NOT an alternative - many, many modules are:
1) use dev
or
2) use something ancient / unusable / unsupported / un-whatever.
It's not a "choice" to wade into development - you frequently have to use DEV to USE Drupal in any meaningful way.
Sorry, this rant has nothing to do with this nice module.
It's the patch mentality. The patch system is needed and and useful, but why force everybody to rebuild something already built? E.g. I could have used this file in seconds. Seconds. Instead, it's going to take 5-15 minutes. It's frequently even faster to manually apply the patch than starting up any patch software.
Comment #25
wxman commentedI'm assuming the #17 patch hasn't been committed yet? I just upgraded to the latest dev, and I lost the token again.
Comment #26
damienmckennaTagging.
Comment #27
Brian294 commentedAgreed! :-)
Comment #28
damienmckennaRe-rolled against the latest CVS and resolved some coding standards violations (tabs, incorrect nesting).
Comment #29
damienmckennaAdded some additional comments, more for our own benefit.
Comment #31
damienmckennaRe-queuing.
Comment #32
damienmckennaIncluded the patch this time.
Comment #33
damienmckennaI'll eventually work out how to do patch queuing properly.
Comment #34
damienmckennaCommitted.
Comment #35
damienmckennaComment #36
dave reidThis patch caused a metric load of PHP notices now when viewing a node page:
Comment #37
dave reidFollow-up patch to fix all the notices and cleanup the $arg and global token logic. Tested with all PHP error reporting settings enabled, and I don't get any notices anymore.
Comment #38
damienmckennaApologies for missing that, and thanks for fixing it. The patch looks good. Committed.
Comment #39
dave reidAnother follow-up. :)
Also discovered tonight there is a waaaaay better way to support finding the current token context without the giant switch statement by just letting the implementations of hook_nodewords_type_id() alter the context if they have decided they should. That way if we do have the context changed, we can just drop down to the basic set of token type loaders.
Also found that the user_nodewords_type_id() function was misnamed user_metatags_type(), so it currently fails. Added contexts for blogs and trackers, as well as improved the context detection for nodes and user pages. And the token code called the forum function for the uc_catalog switch case...another completely broken section of code.
This also has the benefit of removing the completely unnecessary _nodewords_taxonomy_object_load() and _nodewords_node_load() functions.
Comment #40
Brian294 commentedDave,
I think this latest round of patches effectively killed nodewords_pagetitle.
http://drupal.org/project/issues/nodewords_pagetitle
Did we remove/rename _nodewords_custom_pages_load_data()?
Peace,
Brian
Comment #41
Brian294 commentedcorrected url of nodewords_pagetitle issue:
http://drupal.org/node/960672
Comment #42
dave reidYes we did, since it was an internal function... I'm on helping patch up nodewords_pagetitle
Comment #43
dave reidCommitted #39 to CVS:
http://drupal.org/cvs?commit=447600
http://drupal.org/cvs?commit=447602
Comment #44
msti#39: 781440-token-replace-context-followup.patch queued for re-testing.
Comment #46
dave reid