Can't enable meta tags for editing

I just installed 6.x-1.2 from new install and also have the same problem and therefore cannot use the module...

Clear your cache!

Lol thanks!

I am changing the category of this report, which doesn't report any bug.

How is anyone to know to clear the cache? I ran into this same problem.

Consider adding drupal_set_message to let the user know to clear their cache after turning the module on or upgrading.. if not for this thread I'd have never known.

Try admin_menu module, in the first menu you can select which cache to clear

Actually got rid of that module because it was impacting overall performance...

The update function does clear the cache used by the module.

I had the same problem and had to enable the "Basic meta tags" module and clear the cache like @undoIT. This isn't very intuitive...

The description for nodewords.module says that:

Allows users to add meta tags, e.g. keywords or description. This module doesn't actually implement any meta tags, but requires other modules to implement them.

It should be clear that nodewords.module alone doesn't do anything.

I didn't have any problems with the module, and the cache; that is the reason I have not reported anything about that.
Actually, the update function does clear the cache used by the module; maybe it should clear the cache used by Drupal as well.

I added the code to clear also the cache tables used by Drupal (development snapshot 6.x-1.x-dev).

I was also highly confused by this.
Had used nodewords before; included meta tags.
So, after upgrade, seemed very odd when seemed I couldn't have any tags.
Found this thread; googled in search of "basic meta tags" module - only to find it doesn't exist as a distinct module, but is part of Nodewords module-complex (or whatever such things might be called). Also found I had to clear cache.

Maybe can check if any tags output on settings page; if not, suggest people try enabling basic meta tags (within Nodewords complex), and clear cache.

On the module page, says:

This module allows you to set some meta tags for each node, view or panels page.

- which to me suggests it indeed does something. (As Nodewords by itself used to do.)

I felt the same way as the other people who posted here.. updating the module to the latest version seem to break the current implementation of meta tags. So basically we needed to the following extra steps:

a. enable basic meta tags in the admin/build/modules.
b. clear cache.

Both Steps were "NOT" reported in drupal_set_message.

Thanks, for you explanation on this one. I can now enable wich tags to use under admin/build/nodewords.

BUT, do I need to set all the metatags again? It seems that they were disappeared :(
Is there a way to set the old ones back? /I have db backup if needed/

There should be install/upgrade documentation and a warning that existing configurations will be reset on upgrade.

The upgrade, basically renders the module unusable. This is because you need to enable another module that wasn't there before for the module to work. In other words, after the upgrade, you are warned (AFTER) you upgrade the the settings have been reset (so you lose all your existing settings).

Then when you go the the settings, there is nothing you can change or configure.

If you edit a node, you don't see the nodewords field anymore. This is because you have to enable another module - Basic Meta Tags, which was previously not required.

This upgrade SUCKS in regards to intuitiveness.

@16: Seconded. I have done all steps shown by @14, and still I get no keywords. Fer crying out loud. This is a simple problem! We have taxonomy terms and we want them to show up in the keywords string. Why is that such a huge problem? What on earth are the developers doing? Was this mess tested? The basic function of the module is stuffed.

The upgrade, advertised as a critical security fix, has upended the planet and made everything nonfunctional, requires extra settings that weren't there before, requires an extra module enabled. Heavens, when you get a security issue, you put out a simple fix. You don't send it out with a massive untested and unworkable change. I may be dense, but I cannot understand what this module is trying to do here. Hands up: who here is trying to get anything going except some basic info in the keywords and maybe description headers? And as for the 'enhancements' themselves - who 'improves' something by requiring more work to get the old functionality up and running? Someone's crazy here and I don't think it's me.

So now we have a stuffed up setup, can someone please explain in simple terms what must be done to get the keyword tag back?

And PLEASE! Retract this version immediately before a few thousand more drupal sites are wrecked. I apologise for losing my temper here, and I agree it's bad form to be annoyed with folk doing stuff for free, but even when doing things for nothing one incurs at least a moral duty of care to take basic precautions to not wreck things. Yet everything has been done wrongly: the concept behind the new features is bad (requiring more to get the same stuff working); the upgrade is broken (deleting people's data, not operating properly); the upgrade obviously wasn't tested; and a security fix was released along with major enhancements. Nothing more could have been done to mess this thing up any more completely.

Update: I went round in circles, unchecking and checking options, clearing the cache, and suddenly keywords appeared again. But I am quite certain I left all options the exact same way they were set when keywords were not appearing. Well, getting it to work has calmed me down a lot from my previous comment, so please let me try to explain what I see as the basic problem with how this upgrade was done.

A whole lot of new options have appeared, which no doubt give a lot more flexibility, but they must all be set in order to get back the same old behaviour. I wrote some code for module taxonomy list, adding new settings and a lot more flexibility. The equivalent values in my new options that corresponded to the old settings were not the optimal ones with my new feature, but nevertheless, if my new fields were blank, I defaulted them to equivalent values to the old settings. That was so that, if someone upgraded and never visited the module admin interface, the module would work precisely as before. Only people going to that page and reading why other settings were better, would be able to change the settings and get the enhanced functionality. I once developed a codebase in C++ that was about four times larger than nodewords. Over 15 years, slowly increasing and changing functions beyond recognition, changing the file formats umpteen times etc., every single version cleanly accepted old data from every previous version and defaulted new fields to values that exactly emulated old behaviour. That is how you make sure software keeps going without tears, and I see no indications that this kind of thought has gone into this module. It looks as if, as soon as the developers got it working, they released it as a new stable version without any kind of data adaptation policy at all. Add to that a security fix that demands action, and the brew becomes far too rich.

The module is still a danger to every drupal user, because there are no big red letters on the module main page warning people that the change is troublesome and how to get it working. I still don't know what I did that made it go at last. I am certainly terrified of putting it into my other drupal sites. I have no confidence that I can get them to work if I do so.

Apparantly you have to clear the cache for the options to appear, and also have Basic Meta Tag enabled.

Really all there needs to be are better checks in the upgrade/module req's, a couple drupal_set_message()'s during enabling/upgrading and some method to not require cache be cleared.

This is kinda minor though, given a bug that crashes your entire site with certain versions of Ubercart/nodewords.

No anger or pessimism, just empathetic stoicism. It's open source, we can only go up from here.

Amazing. It is very, very basic programming wisdom to never 'optimise' at the cost of correctness. Consider: Here is a menu that will be used by the site managers only, and perhaps be run only a few times a year or even that, in order to get keywords working as desired. It should not be cached at all! Every single time it is wanted it should be dynamically created from the current values of other fields as set on the settings page. But settings go unnoticed and site developers are left mystified, not knowing what to do to get things going - I would hazard that thousands of hours have collectively gone down the plughole due to this mashup - because someone thought "Hey! I can save a few microseconds every six months if I use cached data!"

I agree with RTH that upgrades need to replicate past functionality.

Just for those with this problem (because it doesn't seem clear) here's how I got my meta tags back:

- In Modules (/admin/build/modules/list) enable the "Basic meta tags" module
- Go to /admin/content/nodewords/settings and make sure to enable "Tags to show on edit forms" and "Tags to output in HTML"
- Flush cache just in case

As frustrating as this upgrade is, the new functionality looks tasty.

All my tags got wiped out. This update was not a good one. :(

Another problem with 1.2 is that views support is now gone. It used to be that you could control the meta information on a views page, but these are now gone.

Another problem with 1.2 is that views support is now gone.

That is not true; the support for Views is present, as you can add meta tags to pages of which you know the URL. The settings are under admin/content/nodewords/global/other.

As others have noted, enabling the Basic Meta Tags module (which didn't exist before, and wasn't mentioned during update.php) and clearing all caches fixed this problem for me.

Hardly intuitive...

All my tags got wiped out as well.

About clearing ones cache. This most probably the biggest problem with Drupal and all of it's modules so is there a module that automatically clears the cache? How does one clear one's cache? Does the ctrl + F5 option do it? I have done that and the meta tags still do not show up on the front page or any other pages

@battlingnewbie - install the Administration Menu module (which is indispensable anyway) and there will be an option to flush one, or all, of your caches.

This is a bug, that should have been fixed by #591524: Caching issues are still present, so duplicate.

battlingnewbie: have you checked Performance, under System Configuration of Administration? Here, you can choose various options for cache, as well as clear cache. [ctrl-f5 may affect cache in your computer, but not in your website, I think]

Nodewords are not creating any meta tags. If I create a new node I can add keywords and decsription but nodewords only uses the global meta tags that you set in admin. It does not create any new meta tags. On my other site after upgrdaing it completely wiped all my meta tags and descriptions plus now it does not want to generate any meta tags not even for the front page.

The wiping issue is #587142: update_6113: No rows written to nodewords_tmp and therefore all data lost

Why not add these functions to the end of the install file of the module:

cache_clear_all('*', 'cache', TRUE);
cache_clear_all('*', 'cache_page', TRUE);
cache_clear_all('*', 'cache_menu', TRUE);
cache_clear_all('*', 'cache_filter', TRUE);

Thus solving the clear cache issues.

chris

One of the update functions already clears some of the cache tables used by Drupal.

I'm still not sure why this extra cache clear is required in an update hook... core clears all caches automatically if you run update.php. I'm only not sure what will happen with custom module cache tables... maybe there is a cache clear hook I never seen/used yet... it could be unlogic code that causes the cache issue.

There is a hook that is thought to return the name of custom cache tables, and the hook is implemented in Nodewords.
I am not sure why the cache was not being cleaned, and that is the reason I added the code to clear the cache in the update function.
Each module also cleans Nodewords cache when it is enabled/disabled; the code actually cleans the cached list of implemented meta tags, which was the one that was creating problems.

This sounds bad. Nevertheless the module manually cleared it's cache the issue existed in all versions. So I need to expect this is still not fixed. Needs more testing.

Just to add my 5 cents.

Installed Nodewords 6.x-1.2 on a fresh install of Drupal 6.14, enabled Basic meta tags, Extra meta tags and Nodewords modules. Had the same problem of the author of this issue.

I solved it running update.php
Didn't tried to clear caches.

Update clears all caches :-). There is a workaround in latest dev to solve this for future, but in deep - its a design bug, see http://drupal.org/node/591524#comment-2133482 as a follow up.

I updated my modules via Drush, result: "Tags to show on edit forms" and "Tags to output in HTML" under Nodewords Settings (/admin/content/nodewords) were empty, and meta tags on pages didn't show anymore.

I had to enable Basic meta tags, to be able to select which meta tags to show, and to get them to be displayed.

I think this should be done automatically, when the module is being updated.

I had to enable Basic meta tags, to be able to select which meta tags to show, and to get them to be displayed.

I think this should be done automatically, when the module is being updated.

The code is already present in version after 6.x-1.2.

Great! Drush automatically chose 6.x-1.2, that explains it.

I can not get meta tag settings to show up when editing a view... Any ideas here?

I can not get meta tag settings to show up when editing a view... Any ideas here?

Per #25 above, meta tags are not available on the views edit screen. You have to go to the nodewords settings and add an entry under Other Pages using the path for your view.

This solution is something of a bummer because if you change the path to your view the nodewords attached to it will become disconnected.