The code uses a private Meta tags function

Thanks for pointing this out. I am not sure what's the best way to do here. _nodewords_get_settings() it's really only used for getting the max_size for the keywords field, which I can very well just define it on my module, however, by looking at #290802: Add support for robots meta tag - Using private function of Meta tags which you also pointed something similar, I am also using _nodewords_check_content() which looks like a very useful function this module can use and should be taken from Meta Tags.

This module relies entirely on Meta Tags so in a way is not that bad to use some of their functions, although I understand that if they change, this module will fail. What's your thought about this module and using that function? Possibility of defining a public API of nodewords that can be used by other modules? Possibility of integration of this as part of nodewords? (Wouldn't mind contributing to it).

Personally, I am using both. Actually that's why I first submitted the hook_nodewords() patch and created the module (#263003: nodewords hook (easy entry point for token support in 1.x branch)). I wanted the global meta tags provided by nodewords but for SEO reasons, having finer control on meta tags for certain content types is a very useful feature. As meta tags are really only one (for each page) having two modules that independently set meta tags would not be a good issue, specially if you'd like to use both.

I haven't thought of that particular case of the front page, and I can look that out but as this is not a module that arbitrary associate meta tags to nodes. It is a module that should work fine with meta tags module because it uses a hook that module calls, so the approach of this module looks fine and it can live perfectly along meta tags. It's the decision of the Meta Tags developers (are you one of them, right? :) ) to where invoke this hook and expect other modules to modify tags, which I believe it's a very nice way of providing extensibility, like most modules do.

While I am not against merging this module into nodewords, it might need further maintenance tasks for you unless I can somehow collaborate with it (cvs access?). But if you want to consider this, we can discuss it as well.

Anyway, because the module is fairly simple it might not be a bad idea to keep it separate. For that we have two issues, this front page one you pointed and the use of a private function.

For that I can only think of two good solutions.

For the front page, the logical solution would be to use the hook to indicate what meta tags your module are assigning. Because the hook arguments are somehow extensible, you can add a $front boolean argument or similar. With that argument, any module, such as this one, can decide what to do in that case. On mine, I will decide to either use the front page meta tags (i.e. do not override any tag) or perhaps give the user of this module a setting for him to decide what to do.

For the private function call, I do agree that we shouldn't be duplicating code. For that I have some thoughts. I am not sure what function has changed. On the quick and dirty side, is not that bad that if one function changes (which is the first time that happens since this project is live) I will update the code to reflect that change, which I agree it's not optimal at all. I am using only two simple functions after all. On a better side, If Meta tags accept the idea of the hook and wishes to give other modules the ability to extend its functionality, certain functions may be defined as 'Public', creating a very simple Meta tags API.

Meta tags has an option of letting the user decide what to do with the front page, but that works within Meta tags module. My idea was that it would be useful for other modules to knows what tags are being altered (global or front page or whatever, in the hook itself). There's an option for me to use drupal_is_front_page() but I'd think it's nice to have that in the new tags_alter() hook, just in case in the future nodewords provides some other meta tags setting section, that can be extended as well but only if wanted, so there would be no conflict as the one you pointed out (i.e. If a node is the front page this module should or should not update the meta tag?) To decide what to do I need to know that the front page meta tags are the ones that I will be altering.

What does hook_nodewords_tags_list_alter() do?

As for the group of functions, I'll have to give a proper look. I currently use two private functions:
- _nodewords_get_settings()
- _nodewords_check_content()

I am not sure of the importance of the first one. I am ussing it to use the same character limit for the keyword field. I would think that getting nodewords settings from extended modules would be useful.

The other one is more important, as it cleans the output for a proper meta tag and that should be a very useful function for any module who wishes to set a meta tag.

As for others, well, I'd have to take a look, as this module was created on a particular need and I haven't gone through the whole extent of nodewords module. I think I am not duplicating any code either.

Subscribing.

Actually due to this function : _nodewords_get_settings()
nodewords 6.x-1.x-dev and nodewords_nodetype 6.x-1.1 are incompatible.
The function has been removed from nodewords 6.x-1.x-dev

nodewords_nodetype 6.x-1.1 only compatible with nodewords 6.x-1.0

Here are details of my problem :

nodewords 6.x-1.x-dev (2009-aug-12)
nodewords_nodetype 6.x-1.1

When I want to edit one of my ContentTypes : /admin/content/node-type/xxxxx
I have this error :

Fatal error:
Call to undefined function _nodewords_get_settings() in
/home/drupal/drupal/sites/all/modules/nodewords_nodetype/nodewords_nodetype.module on line 6

with nodewords 6.x-1.2 and nodewords_nodetype 6.x-1.1 same error, when it will be compatible with nodewords 6.x-1.2?

Will look at this probably very soon.

Hi,
Same error here with nodewords 6.x-1.2 and nodewords_nodetype 6.x-1.1; call to undefined function _nodewords_get_settings()

I have just fixed my module to work with the new version of nodewords. Please wait until the -dev snapshot is available or download it from CVS.

Quite a few things changed on the module and I tried to adapt it. So far seems functional and it certainly don't throw the fatal error as no private nodewords function is now currently used.

Please report back if the -dev is properly working on not.

@KiamLaLuno:

Just pinging to see if you are on top of this issue. Maybe you may want to check the changes? While making this work, I had to learn quite a new few things from your module and it's certainly looking a lot clearer. One thing that concerns me now is that there seems not to be any filter on the content, I tried to match the way the content of the configuration fields are used to building the meta tags, but the description field seems not to be filtered whatsoever, isn't that a security issue?

I also think I detected a bug on how the robots keyword is build, should you be using array_keys()? I think that checkboxes form field saves a proper array of values, not like on D5. Will submit a patch on your issue queue later with a proper analysis, but just mentioning here just in case you see this.