Default changes don't reflect on already created nodes

I think that the suggested way to proceed is the correct one, and I think I can implement it. Additionally, when the checkbox is not selected, all the form fields should become disabled; in that way, the users would know that they cannot change those values.

Also, the code change should include an update function that would check the values contained in the database, and remove any rows that contains the default value for that meta tag.

Are you planning on implementing this on 1.x or 3.x?

My plan is to add it to branch 6.x-3.

Actually now that i think of it, my module supports token replacement, and I just found out that yours only supports it on 3.x. And merging this module in 1.x would probably make no sense unless you want me to add token support to the 1.x branch.

My plan is to add new features only to branch 6.x-3. Branch 6.x-1 will get only bug fixes, from now on. Also, consider that branch 6.x-3 will require PHP 5.1 or higher (probably 5.2).

Otherwise this can be merged to 3.x but not sure what's your preference, if continuing this on a separate module or actually consider merging it.

If you are talking of merging Nodewords by Node Type into Nodewords, I don't have a preference. If you want to merge it, I would gladly give you access to the Nodewords CVS repository; the module can be a sub-module of Nodewords, and I can help on keeping the module updated with the changes I would make to Nodewords.
Nodewords code could then be made more generic, and allow the admin user to create some conditions (or rules), and to associate to them the meta tags to apply.
I think that the decision about merging the projects is yours; you created the project, and if you see a valid reason to merge them, or you think that merging them can take advantages to your module, then I will give you access to Nodewords CVS. If you decide differently, I will still give you any support for anything you don't understand about how to integrate the modules.

The code has been changed in branch 6.x-3, and committed in CVS.
Thanks for the report.

The attached patch includes the patch given by Dave Reid to update the integration with Vertical Tabs.

• There is a checkbox for each meta tag for two reasons.
  • Having a checkbox per meta tag increase the granularity of the setting. One user could need to just overwrite a value, and leave the other meta tags to their default values. Doing as suggested, the user would have just the possibility to accept all the default values, or to change all the meta tags content.
  • Having a checkbox per meta tags allows to save the value of the checkbox together the meta tags content. Differently, the value of that setting should be saved in a different table, and I don't think it is really a good solution.
• The settings are handled by each handler because only the handlers for the meta tags know what to do; just to make an example, the handler for the meta tag DC.DATE, when it is said to not overwrite the default value, will use the current timestamp as default value. Different handlers can use a different value, as it is done for the meta tag DC.CONTRIBUTOR, which uses the username of node author, when no default value has been set, and it is said to overwrite the default value.

I noticed that the previous commit contained errors (never trust the search/replace functionality, and never code when it is too late), and I fixed them. I also corrected how some meta tags content is generated.

The code has been changed, and committed in the development snapshot for branch 6.x-3; if I didn't commit it on December 11, then I committed it on December 12.