Global settings not shown on settings page

hass - October 22, 2009 - 23:05
Project:Nodewords
Version:6.x-1.x-dev
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed
Description

I tried to verify if #611042: Global geourl is lost after upgrade (data loss) has been fixed and looking into the database shows me the data seems ok, but if I access admin/content/nodewords/global - none of the default settings are shown in the forms. I have also some other defaults that have been upgraded, but they are also not shown (copyright and robots).

This is inside the robots content field a:6:s:9:"noarchive";i:0;s:8:"nofollow";i:0;s:7:"noindex";i:0;s:5:"noodp";i:0;s:9:"nosnippet";i:0;s:6:"noydir";i:0; of type "default".

#1

hass - October 22, 2009 - 23:08

ups, it's all 0, so all robots checkboxes need to be unchecked, what is the case... so - this may be ok. Nevertheless copyright and geourl values are empty in the form.

#2

kiamlaluno - October 23, 2009 - 06:17

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')

#3

kiamlaluno - October 23, 2009 - 06:40

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.

#4

kiamlaluno - October 23, 2009 - 06:45

I also tried to execute the following snippet

<?php
  $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;}).

#5

kiamlaluno - October 23, 2009 - 08:11
Status:active» fixed

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.

#6

hass - October 23, 2009 - 08:50
Status:fixed» needs work

The module updates must have more issues... hook_update_6102 also use db_escape_string() with update_sql(). Please take a look into all .install files... there are many more db_escape_string() used in update_sql().

#7

kiamlaluno - October 23, 2009 - 08:57

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.

#8

kiamlaluno - October 23, 2009 - 08:58
Status:needs work» fixed

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.

#9

hass - October 24, 2009 - 08:18

Upgrade of copyright and robots works well now.

#10

ao2 - November 6, 2009 - 19:22
Status:fixed» active

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

#11

kiamlaluno - November 6, 2009 - 19:35

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.

#12

ao2 - November 6, 2009 - 23:48

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

#13

kiamlaluno - November 7, 2009 - 10:25
Status:active» fixed

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.

#14

ao2 - November 8, 2009 - 14:13

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

#15

kiamlaluno - November 8, 2009 - 15:33

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.

#16

kiamlaluno - November 8, 2009 - 15:47

The code has been changed, and committed in CVS.

Thanks for your suggestion.

#17

ao2 - November 8, 2009 - 17:01

Great!
I think I can upgrade now :)

Thanks to you,
Antonio

#18

hass - November 8, 2009 - 19:01

What have been changed?

#19

ao2 - November 8, 2009 - 20:42

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

#20

hass - November 8, 2009 - 22:27

I'd like to understand! Only telling "code has changed" does not help anyone to understand the changes and why and how something has changed.

#21

System Message - November 22, 2009 - 22:30
Status:fixed» closed

Automatically closed -- issue fixed for 2 weeks with no activity.

 
 

Drupal is a registered trademark of Dries Buytaert.