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 |
Jump to:
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
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
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
#3
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 likearray('latitude' => 45, 'longitude' => 45); the correct value should bea: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 todb_escape_string()to be saved in the database; the second value is the result ofserialize().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
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
I resolved the problem. Rather than using
update_sql(), I useddb_query().It seems the problem is passing the result of
serialize()toupdate_sql(). As the result ofupdate_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 calldb_query(), which is the function thatupdate_sql()internally calls.#6
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
The problem is not using
db_escape_string()togetherupdate_sql(), but to pass toupdate_sql()the result ofserialize().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(), norupdate_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
The only update function that uses
serialize()isnodewords_update_6113(), and that function has already been fixed.I am marking this report as fixed.
#9
Upgrade of copyright and robots works well now.
#10
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 reservedGlobal GeoURL: XX.XXX, YY.YYY
Global keywords: Antonio Ospite, blog
plus
Frontpage Keywords: ao2, theorist attacks, feeds, comments, tags, linux, drupalUpgrading to 1.3-beta5 goes basically ok, only few touches to become perfect (for me):
Global keywordsvalue is copied inDefault keywordsin the Default and specific meta tags tab, why don't put it in the newGlobal keywordsdirectly?Global copyrightandGlobal GeoURLtags, 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
Because the global keywords has been reintroduced later than the update function.
See the default copyright, and the default location.
#12
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:
About Default Copyright, It was hidden because I had only
keywordsin the Meta tags to show on edit forms list. While I haddescription, copyright, keywords, robotsin 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
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.
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.
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
Quoting myself:
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
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
The code has been changed, and committed in CVS.
Thanks for your suggestion.
#17
Great!
I think I can upgrade now :)
Thanks to you,
Antonio
#18
What have been changed?
#19
@hass: nothing really blocking.
I's just that forms for default values now behave in a way more comfortable for my needs.
#20
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
Automatically closed -- issue fixed for 2 weeks with no activity.