| Project: | Nodewords: D6 Meta Tags |
| Version: | 6.x-1.3-beta5 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I happily used nodewords with D5, now i'm struggling to use mata tags in D6 with an easier project...
I wanted to use primarily a "by path" scheme and i discovered that the features we used to add with the "by path" module is now included in the meta tags module.
But i can't make it work, regardless of what i'm setting using the "other pages" setting get overwritten by the deafult settings, first.
Then i saw that removing that default settings simply erases the <meta> in the head even if we have "by path" matching settings and i think this is not the intended behaviour.
So, i'm a little bit confused.
Once we had the "by path" module overwriting the node's inserted tags, what should be now the right behaviour?
If i'm correct we could use token replacement with the "by path" module and now it seems we can't do this anymore, so i found the "meta tags nodetype" module that supports token, but i can't get it to work too, i always see the default meta tags.
The default settings and the node's specific meta tags works correctly but i'd like the use even the "extended" features.
I cannot delegate "admins" to enter meta tags when creating nodes, indeed, i have to build an automatic system to add dynamic meta tags...
Are these known problems or am i the only one with such limited features?
Thank you for this powerful module, anyway :-)
Da.
[Edited by KiamLaLuno to show a hidden HTML tag]
Comments
#1
I got the same kind of issues.
I'm trying to set a specific description to the following url : http://www.soulfulbits.com/content/wikisoul
It fails and takes the content of the page.
On a other side, i'm trying to build a pattern for category/tags/* , i leave the description blank in order to have the first words as description.
It fails, the default description override all.
Example : http://www.soulfulbits.com/category/tags/daptone-records
#2
The default values are applied when there is a value for a meta tag in the specific context.
The other pages settings were not thought to override the other settings, but to complement them; therefore, the settings for other pages are applied when the other settings could not be applied.
I can easily invert the order how the settings are applied. In this way, it would be possible to override the settings for a specific node, user, or taxonomy term.
Bear in mind that it makes sense to do so if the meta tags change basing on the URL used; differently, if I need to change the meta tags for a node, I can easily do it from the node edit form, without the need to set meta tags for a specific page (the same is true for user profiles, or taxonomy terms).
#3
Ok, i think that in a perfect world we would have something like this:
META TAGS
working like this:
There should be an option to choose how we'd like to use every setting, if we want to combine with the default meta tags or to override them.
The order i've placed the settings in is the one i'd like to see as a hierarchy, in order to have something like this:
The most specific settings should be applied, so that the meta tags for the single node or the single view should always override the other settings except for the default ones, like said before.
The content type setting should overcome the path one that we could simply use as an alternative to the views one, or better as a slightly changed "default" settings for url patterns in a hierarchycal website.
This is what i can imagine as the best way to manage meta tags inside a drupal website, this way we could have an dynamic and automated system with the chance to overwrite the default behaviour by settings meta tags for specific contents.
I know this could not be in the mood for this module, i just wanted to share these thoughts...
Thanks,
Da.
#4
If the problem is the default values overriding the meta tags values when they are empty strings, it is enough to add an option that allow to decide if to use the default value or not; in the case it is chosen to not use the default value, then the empty string will not be overridden by the default value.
The analysis about the settings is interesting. It has some interesting points, but it is too specific for content types / nodes, and it forgets some specific details.
I am not sure how the list has been ordered, but the default values should be taken in consideration when there are not values set for any of the other categories. If I am reading the list correctly, then the module is already implementing the settings in that order, with the exception for the content type settings that are not currently implemented.
What should the difference between system tokens, and CCK tokens be? Using token.module there isn't such difference.
#5
Yes, indeed. I just had problems with the "by path" settings, everything i've tried failed, so it is a missing step apparently.
The content type settings are crucial, since they are the only way to automate the meta tags attribution, i've seen this working perfectly with the int_meta module.
I know there's an helper module "nodewords_nodetype" but it seems not to work with the latest stable nodewords module release.
Nothing :-) You're right, i've just written that thinking about the data we could really use, but that's not important. It makes sense to use cck tokens only when dealing with nodes i guess, not when using a path's match...just this
That's perfect, i suppose we are confused because we saw the "by path" setting being apparently overwritten by the default one, but it could have been simply different...the path one wasn't working at all, i guess.
I think that the best way is to have 2 options for every setting: override or combine the default one. It doesn't make sense to make a new setting if we want it to be overwritten by the default one, so there's no need for a third option like "let override this...", indeed.
So, i think that having nodewords working with content types too, supporting tokens and fixing the issues about the "by path" settings this could be definitively a "must have" module.
Ops..there's a final issue about the internationalization i was forgetting to speak of... I didn't see how's the views 2 integration, but is there only a general "meta tags" form or one for every display? Because i think many of us like to use the same view with different displays to show content in a multilanguage website, so there should be the chance to set different meta tags for every display we provide...i guess this could be annoying but i don't know, there's always the fallback...to build different views :-)
Thanks,
Da.
#6
There is already a feature request about content type settings, and tokens will be implemented in version 6.x-3 (actually, both features will be implemented in that branch).
There is also a report about the use of different meta tags for different languages. I think this can be easily resolved by adding a new database field for the language currently set for the node; in this way, the database will contain a different row for each of the enabled languages.
About the settings for other pages, I am not sure if you would prefer if the module would check first if the currently shown URL has settings reported under , and then check if the currently shown page is for a node, a user profile, a taxonomy term. As I reported, that can be easily changed; if it can be useful for some pages to override the meta tags even if the page shown is a node, I can do the change.
#7
No, i think we're fine with the present behaviour, i had problems using the "other pages" preset, that means that it didn't work, but i'm looking forward to the 6.x-3 branch to be released.
Thank you,
Da.
#8
The node ID is unique. Nothing special to do for nodes...
#9
That is true; the problem is when it is possible to change the language associated with a node (see the attachment). In that case, it is not sufficient to save the node ID.
#10
This makes not much sense to me... in such a case the current NID is kept as is and the nodewords need to be updated by the user. This is not the job of nodewords what is entered inside the input fields.
#11
Hi Guys,
same problem here! I need to use different metatags for different languages but only default values are displayed.
Other way is to modify nodewords metatags in any single node, but with a hundred of nodes per language is a suicide!
I tried to delete all the default values in the nodewords table and leave the only metatags per path ( en/* ) but no metatags is displayed.
Any idea?
Bye
#12
I believe you need to configure i18n variables for the meta tag fields.
#13
As this support request has been already replied, I am marking this report as fixed.
#14
Automatically closed -- issue fixed for 2 weeks with no activity.