I'm creating a somewhat redundant issue, because the issue was addressed last year as a feature change in the 6-3.x version, which is still not production-ready.

Given we all need the 1.x-dev to work, I believe this problem should be included in 6-1.x, perhaps not in the 1.12 that is being worked towards, but hopefully 1.13.

Setting defaults for all nodes, means that the nodes use the defaults, but if you edit the node and try to customize your description or keywords, then save the node, you will find that your changes did not take. The defaults, which in my case are tokens, are always there in the form. So, defaults work, but you cannot override them.

If there are form fields in my node form, that means I should be able to edit and save the values in them. Saving them then going back into edit screen and the values not changing, makes me think I'm going quite mad.

The patch in the issue I link to below, adds a checkbox to the Meta tags form elements in your nodes, that allows you to override Global defaults with whatever you put in the form.

Issue patched for 3.x
#650750: Default changes don't reflect on already created nodes

Similar issue, that blanks cannot be used (blank value would mean you're telling nodewords not to render meta tags for that node).
i include it here, because if you can't edit the meta tags form, you can't set it to blank.
#679584: Default values are always used when no values are set for meta tags

Here's hoping that Nodewords can reach its goal of being stable.

Comments

DamienMcKenna’s picture

Status: Active » Postponed (maintainer needs more info)

I believe this should work as intended now with the latest 6.x-1.x-dev codebase, several bugs were caught regarding how defaults work. Please let me know, thanks.

bedlam’s picture

I have this problem too, in the latest (6.x-1.13) version. Specifically, the output can't be altered by editing the field in the node--the contents of the field in the node edit screen are, as far as I can see, always correct.

I haven't tracked the problem down, but I've spent a couple of hours reading through and dumping data from the module(s), and I can give you some clues.

I've been working on the 'keywords' field in particular, so I can't tell if my results are specific to that meta tag only, or if they're generally applicable.

In my investigation, the right values are present at every stage of the insert/update op of hook_nodeapi(), but a problem arises in the load op of the same function. Somehow, the load op is called three times on node load, and returns a different result each time (I can't say, on the basis of the testing I've done, that it's always three, or if it's some peculiarity specific to the site in question...) In other words, if I insert drupal_set_message(nodewords_load_tags(NODEWORDS_TYPE_NODE, $node->nid)) before the return statement in the 'load' case, I get three different arrays when the page loads.

The first value returned is the custom value from the current page. I can't determine what the other values are--they appear to be past values from the same field perhaps. They are:

  • not the same as the value contained in the "Global keywords" field at admin/content/nodewords
  • not the same as the value in the "Keywords" field at admin/content/nodewords/meta-tags
  • not combinations produced by nodewords_unique_values() because they contain words that are not contained in any of the relevant fields (!)

The value that appears in the source of the page is a value, different from all of the above, that used to be the value in the "Keywords" field at admin/content/nodewords/meta-tags.

I hope this is helpful, but I haven't got any further time to spend on tracking down the bug at the moment.

DamienMcKenna’s picture

Status: Postponed (maintainer needs more info) » Active

Thank you, I'll test this further this week.

DamienMcKenna’s picture

Status: Active » Postponed (maintainer needs more info)

I am unable to reproduce this with 6.x-1.13. In my test scenario I assigned some defaults for the Description and Keywords meta tags, edited the tags on a node, when viewing the node the edited values displayed correctly.

Do you have any modules that could be interfering, e.g. a node caching module or anything?

bedlam’s picture

Thanks for looking into it so quickly.

The site doesn't use anything that might obviously be causing this kind of problem--it's almost entirely CCK, Views and Imagecache-based. Even the content type I've been testing with is the unmodified Page type. I've also been testing as an authenticated user and (redundantly) with caching disabled.

As you haven't been able to reproduce it, if I have a little time in the next couple of days, I'll revisit my test site to see if I can find any more details.

vyasamit2007’s picture

Hi Guys,

Any update on this front? I'm facing the same issue with Version 6.x-1.13

Thanks for looking into this. I'll test with the 6.x-1.x-dev if it doesn't have this issue.

Thanks!!

DamienMcKenna’s picture

Please test the latest 1.x-dev as I've recently changed how the defaults are used - they're now only loaded during the output rather than being used to pre-fill the per-node form fields.

If anyone is still seeing this with the latest -dev code please contact me directly if you'd be able to give me access to your site installation.

clemens.tolboom’s picture

The defaults in our case did not work for description using teaser ... both 6.x-1.14-beta2 and 6.x-1.x fixed this. So checkout those version.

See also #1777508: Please publish the 6.x-1.14 versions

marcoBauli’s picture

Still cannot override deault values (even if 'not set') here, on both 6.x-1.14-beta2 and 6.x-1.x. Going to contact in PM, thanks

clemens.tolboom’s picture

Status: Postponed (maintainer needs more info) » Needs work

After trying to reproduce the test I'm not sure this is solved by 6.x-1.14-beta2 (or 6.x-1.x).

We (my customer and I) reinstalled the module and it seemed solve the problem.

But I have my doubts as the nodewords seems to store empty records for nodes like

INSERT INTO `nodewords` (`mtid`, `type`, `id`, `name`, `content`)
VALUES
	(13, 5, 113742, 'canonical', 'a:2:{s:5:\"value\";s:0:\"\";s:4:\"hide\";i:0;}');

and code seemed to test for the existence of a record _not_ on empty values. Maybe that is the problem? I have no time for investigate again. sorry :-/

Set to active for @DamienMcKenna

DamienMcKenna’s picture

Status: Needs work » Active

@clemens.tolboom: Thanks for the extra info.

FYI the "needs work" status is for when there's a patch uploaded that needs further work, rather than just saying "can someone please work on this".

DamienMcKenna’s picture

Status: Active » Closed (won't fix)

Thank you for taking the time to work on this. However, the module is no longer supported, so I'm closing this issue.