Global settings not shown on settings page

The problem is with nodewords_update_6113(); the update function that copies the default values from Drupal variables to the database table works.

Update #6102

• INSERT INTO {nodewords} (type, id, name, content) VALUES ('default', '', 'copyright', 'dfgdfgdfg')
• INSERT INTO {nodewords} (type, id, name, content) VALUES ('default', '', 'geourl', '45,45')
• INSERT INTO {nodewords} (type, id, name, content) VALUES ('default', '', 'keywords', 'dfgdfg, 4545, 56566, 455445, 45455, 454545')
• INSERT INTO {nodewords} (type, id, name, content) VALUES ('default', '', 'robots', 'index,follow')

Looking at the database content, I notice there is the following value for the location meta tag:

a:2:s:8:"latitude";s:2:"45";s:9:"longitude";s:2:"45";

That is not what serialize() should return for an array like array('latitude' => 45, 'longitude' => 45); the correct value should be a:2:{s:8:"latitude";i:45;s:9:"longitude";i:45;}.

The difference between the first value and the second value is that the first value has been obtained from serialize(), and then passed to db_escape_string() to be saved in the database; the second value is the result of serialize().

I need to check what the function db_escape_string(); I suspect that it removes the curly parenthesis, even if I would not expect such behavior.

I also tried to execute the following snippet

  $a = array(
    'latitude' => 45,
    'longitude' => 45,
  );

  print db_escape_string(serialize($a));

The result has been the expected one (a:2:{s:8:\"latitude\";i:45;s:9:\"longitude\";i:45;}).

I resolved the problem. Rather than using update_sql(), I used db_query().

It seems the problem is passing the result of serialize() to update_sql(). As the result of update_sql() was not used to avoid to fill the update log page with many log lines (one for each meta tag copied from the old table to the new table), it makes sense to call db_query(), which is the function that update_sql() internally calls.

The problem is not using db_escape_string() together update_sql(), but to pass to update_sql() the result of serialize().

As I reported, the update 6102 is working perfectly fine; the result I reported in my previous comment is the expected one; therefore, the problem is not db_escape_sql(), nor update_sql() in the generic case (it means there is a problem in a specific case).

I don't understand why this happens, but that is what I found out. Now that I use db_query(), the result is the expected one.

The only update function that uses serialize() is nodewords_update_6113(), and that function has already been fixed.

I am marking this report as fixed.

Hi, sorry if I reopen this one, I'm testing upgrade to 1.3-beta, there are still
some little details missing to make me switch, and I think this report fits quite well what I am experiencing.

I am starting from nodewords-6.x-1.0, I have these global settings:

Global copyright: Copyright 2009 Antonio Ospite, some rights reserved
Global GeoURL: XX.XXX, YY.YYY
Global keywords: Antonio Ospite, blog

plus

Frontpage Keywords: ao2, theorist attacks, feeds, comments, tags, linux, drupal

Upgrading to 1.3-beta5 goes basically ok, only few touches to become perfect (for me):

1. The old Global keywords value is copied in Default keywords in the Default and specific meta tags tab, why don't put it in the new Global keywords directly?
2. I can't find how to change the Global copyright and Global GeoURL tags, the forms to edit them are not shown in the Settings page.

   The actual meta tags values have been upgraded and render correctly if I look at the page source, tho.

Thanks,
Antonio

The old Global keywords value is copied in Default keywords in the Default and specific meta tags tab, why don't put it in the new Global keywords directly?

Because the global keywords has been reintroduced later than the update function.

I can't find how to change the Global copyright and Global GeoURL tags, the forms to edit them are not shown in the Settings page.

See the default copyright, and the default location.

About Global Keywords, ok, I see why. I will copy the "Default keywords" back to the new "Global keywords" field, the difference is that the Global ones are meant to be concatenated to the page specific ones. If you don't want to change the situation, it could be worth to write about that somewhere, a simple phrase like the following would suffice:
If you had Global keywords defined (in 1.0), they are now considered as Default keywords, and will be replaced when you add keywords specific for a page. If you want the old behavior of Global keywords concatenated to the page specific ones, move the Default keywords back to the Global keywords field.

About Default Copyright, It was hidden because I had only keywords in the Meta tags to show on edit forms list. While I had description, copyright, keywords, robots in Meta tags to output in HTML list. Shouldn't you take into account the second list when proposing Default settings? Does the first list refers to *node* editing form?

About Location... I can only see it in the lists above if I set the UI language to English, if I use the Italian language I don't see it. EDIT: Ahh, it's called Percorso that's quite a misleading translation, what about Posizione?

Thanks,
Antonio

I will copy the "Default keywords" back to the new "Global keywords" field, the difference is that the Global ones are meant to be concatenated to the page specific ones.

That is why there are global keywords, and default keywords.
In the other cases, as for the meta tag COPYRIGHT, it doesn't make sense to have default values, and global values. If the copyright of an article is set to be by a specific entity, I don't see in which way I could unconditionally add another copyright note.

Does the first list refers to *node* editing form?

It refers to all the edit forms that allows you to change the meta tags content; this includes also the edit form that are present in the Nodewords settings pages.

Ahh, it's called Percorso that's quite a misleading translation, what about Posizione?

That depends on the translation made for the word in the Italian translation file. In Drupal 6, there isn't a way to associate a context with a word to translate; therefore, the translation file contains a unique translation for each word / sentence.

Quoting myself:

About Default Copyright, It was hidden because I had only keywords in the Meta tags to show on edit forms list. While I had description, copyright, keywords, robots in Meta tags to output in HTML list. Shouldn't you take into account the second list when proposing Default settings?

What's your opinion about this? Should Nodewords consider both lists (Show on edit forms, output in HTML) when proposing Default settings?

Thanks again,
Antonio

What's your opinion about this? Should Nodewords consider both lists (Show on edit forms, output in HTML) when proposing Default settings?

I guess you mean that in the default settings page, the module should show the form fields for the meta tags that has been selected to be shown in the edit forms, or that has been selected to be output in HTML.
It seems right. If a tag appears in the HTML output, the administrator user should be able to set at least the default value for that tag.

The code has been changed, and committed in CVS.

Thanks for your suggestion.

Great!
I think I can upgrade now :)

Thanks to you,
Antonio

@hass: nothing really blocking.
I's just that forms for default values now behave in a way more comfortable for my needs.