I've just upgraded to 1.1, and got a warning that the default meta tags had all been set to blank and that I could reset them at the settings page. I could see that the update.php page had tried to update all the meta tags I had set for specific pages. It all seemed to have worked.
So I went to the settings page to update the defaults. I found nowhere to do so. I then expanded the group heading "Tags to output in HTML", and underneath was written "Select the meta tags you want to appear in the HEAD section of the HTML pages." But there was nothing else. There were no check boxes to tick.
So I went to a page on the site and viewed the HTML source, and there is no Description or Keywords in the HEAD section.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | Voila_Capture_35.png | 58.15 KB | avpaderno |
Comments
Comment #1
edegro commentedYeah, upgrading to 1.1 pretty much bricked this module for all my sites... And length in "Maximum meta tags lenght" is spelled incorrectly.
Comment #2
captcha commentedUpgraded to 6.1.2, and same issue, meta tags cannot be accessed. But running update did convert/update hundreds of them successfully.
Comment #3
pgtremb commentedYou have to activate new module:
Basic meta tags
don't forget to clear your cache
Comment #4
captcha commentedactivated all the new modules, will just try clearing cache and report.
thanks.
Comment #5
gregarios commentedSame symptoms here, even with version 6.x-1.2: No description meta tags anywhere whatsoever. The only tags that show up are taxonomy tags. No ability to edit global tags either. Descriptive text is in the settings, but no fields show up. Already cleared caches, updated database, etc.
Comment #6
captcha commentedclearing the cache solved this issue for me.
activating modules was not enough.
Comment #7
avpadernoSee the attachment; do you see the same on your site?
I am changing the referring version as the development snapshot is the only one that can be changed.
Comment #8
avpadernoSee also the user permissions page, as the module now uses more permissions than before; there is a permission for each meta tag supported by the modules.
Comment #9
gregarios commentedI don't.
UPDATE: Ok, I had to clear the cache on my installation 3 more times to get it to show. Now it seems to be working. Go figure.
UDATE 2: I still do not have settings fields available for Error 403 page, Error 404 page, Front page, Offline site, or Tracker pages still. Default settings page does have fields now though.
Comment #10
dave reidComment #11
avpadernoI am changing the category as the report is not describing any bug, and I am marking it as fixed because the other comments written here.
Comment #12
jamesoakleyI always read the release notes before upgrading a module. If a new module needs to be activated to make the upgraded version perform as before, IMHO that should be mentioned in the release notes for the upgrade. Glad it works though
Comment #13
1websitedesigner commentedLike James, I think this is still active. I think the number of comments in a short time indicates this is critical. I also found that clearing the cache was necessary for this to work.
To save people having to look up how to clear cache, go the following folder on your site:
/admin/settings/performance
Scroll to the bottom and click 'Clear Cache'.
Comment #14
1websitedesigner commentedSmall point, on the following page:
admin/content/nodewords/global it says:
The ROBOTS meta tag offers a simple mechanism to indicate to web robots and crawlers whether the page should be indexed (INDEX or NOINDEX) and whether links on the page should be followed (FOLLOW or NOFOLLOW).
But in the tick box list there are no 'index' or 'follow' options. I'm aware that there doesn't need to be, as it's better to save code and simply not include them, as search engines assume 'follow' and 'index' by default, but this might be best to be explained in this section.
Comment #15
mikeytown2 commentedNeed to coach the users, if nothing is displayed on settings page, tell them to enable basic module and clear cache.
Comment #16
glynster commentedI too upgraded to 6.1.2 after finding this managed to make the module work as expected however I use nodewords by path as well and it appears that the module has broken this module. Now when going to edit any of the rules I get a white screen so I guess something needs to be adjusted to connect everything back up. Is anyone else having this problem?
Not sure if this helps but on this link:
/admin/content/nodewords/path/list
The word "Array" shows
/admin/content/nodewords/path
On this page I get the list of my rules and clicking on any of them I get a white page.
Comment #17
avpadernoThe description of Nodewords already says it does not implement any meta tags.
Comment #18
glynster commentedOK so KiamLaLuno you are saying that nodewords and nodewords bypath modules are no longer compatible? I have not read this anywhere in the documentation. I was not warned that if I upgrade nodewords module that it would break all my nodewords bypath rules. Please explain further as I am very confused at this response and does not help me in any way to resolve this issue - so therefore this is not fixed.
Comment #19
avpadernoNodewords already includes the functionality that is present in ; if you are using version 6.x-1.1 or higher, you don't need to use the other module.
I still have to update the project page, but I thought it was not nice to write that two modules are using two private functions of Nodewords, and they are supposed to break in any moment.
I think I will write a note on the project page, after all.
Comment #20
jamesoakleySorry, but where was that said? I have just re-read the module description page and there was no mention I could see that no meta tags are output by default. More pertinently, nowhere does it say that those upgrading from 6.x-1.0 need to enable an additional module if the functionality they had under the previous version is to continue. All the site administrator sees, then, is that they upgrade the module, run update.php, and all their meta tags have gone. I would have thought the correct way to handle this is to have the update.php script automatically enable basic meta tags if the version being updated from is 6.x-1.0 (or 6.x-1.1 or 6.x-1.2, because users upgrading from those modules may well upgrade to 6.x-1.3 to see if the loss of functionality they have experienced has been fixed)
Comment #21
jamesoakleyThis is a great module. There's a danger of an editing war on whether this issue is active or fixed. (I didn't mean to change the status just now from fixed back to active; I was typing my post while you were typing yours and thought I was just keeping the discussion going without changing the state. Because you changed active to fixed, my post then put it back without me meaning to).
Far, far better would be to make the readme file, the release notes and the module page as clear as possible so that all the site admins using the module know how carry on enjoying its functionality with this latest, very welcome, release.
Comment #22
avpadernoI agree on adding something on the README.txt; I don't expect somebody would notice that, if even the description given for nodewords.module in the modules page has not been noticed (I mean the page where you enable/disable modules).
I think I will add a note in the README.txt, but I will also add a implementation of
hook_requirements()that checks if there is any module that implement one of the custom hooks required by Nodewords; if it doesn't found a module that implements that hook, then the module will report an error the administration user will surely see.The reason I keep to mark this report as fixed is because the original report has gotten an answer. I will create a separate issue for the latest topic.
Comment #23
jamesoakleyThat should do it. Putting a description to this effect in the modules page does not help when someone is upgrading the module because they wouldn't go to that page. They would assume the module is already enabled, so should work. Putting an on-screen note for the administrator warning that the nodewords engine is running but nobody is driving the car should make that clear. Thanks
Comment #24
mcarrera commentedsubscribing
Comment #25
avpadernoCould we stop to change the metadata of the report without to know why they are set as they are? I don't think that to subscribe to a report (which is already marked as fixed) is required to change the referring version too.
Comment #26
avpadernoI created a different issue for what I was talking of; see #586434: Implement hook_requirements().
Comment #27
Web Assistant commentedComment #28
glynster commentedOK thanks for the response I now see what you mean and this new upgrade gives me everything I need.
It was just a shock to see everything gone with no explanation.
I will now reimport all my tags again and see how this progresses.
Comment #29
avpadernoI have marked #586728: Meta tags lost with update to 1.2? as duplicate of this report.
Comment #30
gregarios commentedWHAT? I must be missing something...
The following is the first sentence in the description of this module, as seen at the very top of the Nodewords module project page:
"This module allows you to set some meta tags for each node, view or panels page."
Comment #31
avpadernoI meant the description given in the modules settings page, which lists all the modules present in the directory modules.
The project page refers to the project, which includes nodewords.module, basic_metatags.module, extra_metatags.module, site_verification.module; therefore, the project page is correct.
Just to make it clearer, I will change in .