Posted by JamesOakley on December 8, 2009 at 10:39am
Jump to:
| Project: | Nodewords: D6 Meta Tags |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Trying to upgrade 3 of my sites from 6.x-1.5 to 6.x-1.7 gave me the same problem. The update.php execution gets stuck at "Updating Nodewords... remaining 2 of 2". The percentage shown is between 40 and 50%. (One site had 43%, one 44% and one 49%). The update doesn't progress any further.
Sorry: I've not got time to look at the update code to see what queries it's running; I've put 6.x-1.5 back for now, hoping that the queries that did run don't give me problems when running against 6.x-1.5
Comments
#1
Hi, it's me again. The update hangs at 41% on my site. I cancelled the update-process after 60 minutes. Cheers Marbot
#2
Same here the update hangs at 47% on my site. I rolled back to version 1.5 but it added some funky stuff on my Meta Tags, went in manually to fix them.
#3
array_keys(): The first argument should be an array in /home/xxxxxxx/public_html/sites/all/modules/nodewords/nodewords_basic/nodewords_basic.module on line 627
#4
It hangs for me from 1.5 to 1.6 & 1.5 to 1.7
#5
Same here.
The metatags are showing:
<meta name="keywords" content="a:1:{s:5:"value";s:36:"metatag1, metatag2, metatag3;;}">#6
at my site the same problem
update 6156 is not running, update.php is runnding endless
#7
Same here.
#8
Hi,
similar problem on one site; update pending for nodewords: 6156; update.php?op=start&id=182 "hangs" at 49% for about an hour. I tried this several times, but it never finishes in a reasonable amount of time. Same story when running
drush updateordrush updatedb, but without any percentual progress indication. This appears on one site, while the update runs smoothly on several other sites.When monitoring MySQL with mytop during
update.phpis running and letting mytop "explain" the running queries, I'm getting...this query at ~32% and ~45%:
EXPLAIN SELECT * FROM nodewords WHERE name NOT IN ('dc.date','location','robots') ORDER BY mtid ASC LIMIT 9520, 10:[...]
...and queries like this at 49%:
EXPLAIN SELECT COUNT(*) FROM (SELECT node.nid AS nid FROM node node WHERE (node.status <> 0 OR (node.uid = 0 AND 0 <> 0) OR 0 = 1) AND (node.vid IN ( SELECT tn.vid FROM term_node tn WHERE tn.tid = 2660 )) ) count_alias:
[...]
EXPLAIN SELECT n.nid AS nid, n.vid AS vid, n.title AS title, n.type AS type, COUNT(*) AS cntFROM node nLEFT JOIN term_node tn ON tn.nid = n.nid AND tn.tid IN(181,216,217,205,183,213,197,1455,1978,2678)WHERE n.type IN ('blog','{OTHER NODETYPES} [...]') AND n.status = 1 AND tn.tid IS NOT NULL AND n.nid NOT IN (30806)GROUP BY n.nidORDER BY cnt DESC, n.created DESC, n.nid DESCLIMIT 10:
[...]
EXPLAIN SELECT * FROM nodewords WHERE name NOT IN ('dc.date','location','robots') ORDER BY mtid ASC LIMIT 9520, 10:
[...]
Queries like this are hitting the database for at least an hour with 2000-4000 qps; during this time, the progress bar of
update.phpis (in my case) not updated beyond 49%. However, in the background lots of database queries continue to be executed. This causes some load on the database server (load average > 2 on a dual core machine), so be careful when and where you execute this database update.I'll report back if/when the queries slow down. However, that hanging "49%" progress indicator is quite irritating.
Greetings, -asb
#9
Same issue here (1.5 to 1.6 and 1.5 to 1.7) for sites with Nodewords activated AND configured : the database update 6156 can not be applied and data in the "nodewords" table seem like corrupted (?) : "a:1:{s:5:"value";s:211:"a:1:{s:5:"value";s:184:"a:..."
However, both databases updates (1.5 to 1.6 then 16. to 1.7) worked on sites where Nodewords is activated but not configured.
#10
Now I see this line "a:1:{s:5:"value";s:211:"a:1:{s:5:"value";s:184:"a" in EVERY nodes!!!
#11
same here.. subscribing..
#12
same, I'm back to version 1.5 and restore the database to eliminate "a: 1: (s: 5:" value "; s: 211:" a: 1: (s: 5: "value"; s: 184: "a :..." in all nodes
#13
Same here on three sites. This upgrade should be pulled immediately.
I downgraded, and was able to get all sites running again, but lost all my keywords. Thankfully, searching for my sites on Google and looking at the "cached" versions of my sites let me quickly restore them.
Next time I upgrade, I'll be sure to do a database backup!
#14
wich DB table I need to restore for my nodewords backup?
#15
I had recently followed the instructions at #613376: How to downgrade broken nodewords 1.1+ to 1.0 for a smooth upgrade to 1.3, so basically did it again.
That boils down to:
WHERE name in ('nodewords','nodewords-repeat','nodewords-use_front');.To be extra safe, and because I knew I had just done it and it worked, I went through the drill of uninstalling Nodewords entirely, cleaning out the database of any reference to Nodewords, installing and enabling 1.0, putting my data back as described in #613376: How to downgrade broken nodewords 1.1+ to 1.0 for a smooth upgrade to 1.3, then upgrading to 1.5 again.
For future Nodewords releases, I will take a DB backup immediately prior, and probably wait until 24 hours has elapsed from the release. Once bitten, twice shy - and I move to take precautions I had carelessly grown too lazy to take each time!
#16
Same problem CPU at 40%~90%.
With version 6.x-1.x-dev (2009-Dec-08)
#17
I have marked #654530: Version not updating from 1.2 to 1.7 - Updation process stops while running update.php as duplicate of this report.
#18
@#8: The only query executed from Nodewords update is
SELECT * FROM nodewords WHERE name NOT IN ('dc.date','location','robots') ORDER BY mtid ASC LIMIT 9520, 10, which is simply changing the way the data are saved in the database.The other query you report is not executed from the update, which is not trying to access the table node.
#19
subscribe
#20
New release please!
#21
same here.. subscribing..
#22
subscribe
#23
same here.. subscribing..
#24
same here.. subscribing, looks like the update needs to explode the content of the meta fields? the dev release is quite a lot different...but thats me for tonight, will check back in the morning.
#25
Same, suscribe.
#26
Why you don't remove the update 6.x-1.7? !!!!
#27
subscribing.
#28
subscribing
#29
Sure Glad I had the Backup & Migrate running with automated backups. Just restored 1.5 and restored from this mornings backup. Dodged a bullet.
#30
Did you not bother testing this or something? And why hasn't it been pulled? Every person that downloads this new version and tries to update is having all of their meta tags completely screwed up. Looks like I won't be getting updates for this module anymore.
#31
Subscribing - hanging and files corrupt corrupt :(
Meta tags now include additional characters eg a:1:{s:5:"value";s:41:"
#32
Yes, I did; it works on my test site work, and I am not having any problem with the update.
#33
#34
Same. Updated 4 sites before running database update then had to re-install all 4 back to 1.5. What a pain.
#35
ditto on this, upgrade from nodewords 6.x-1.0 to 6.x-1.7 there were about 134(i think?) changes to make to the DB, update.php froze on the final 2, repeat run of update php freezes at 50%
#36
Please remove this update - as the day goes by more and more people are corrupting their installations
#37
#38
#39
So, three faulty upgrades in just a few days? This one is the worst. My keywords now look like this:
a:1:{s:5:"value";s:243:"lichaams[...]en";}
I maintain 7 sites and I only had the stuck update on the last 2 sites (all sites have different databases and I try to make updates as fast as possible so I usually start them all at once). All sites, though, have broken meta-tags.
Funk you very much. Please pull this upgrade now.
#40
@ErikJanVens: Be careful of the words you say.
It is not clear to me what you meant with , but I advice you the word is too close to another word that is not too nice to say; if you are then going to tell me that you mean , then I tell you that I don't believe that.
#41
kaimlaluno,
I'll say thank you, though: I know you are working very hard to find the problem and fix it. Thank you, on behalf of all of us who use and appreciate this module.
Having said which, the other sentence that Erik signed off with suggested that 6.x-1.7 (possibly, 6.x-1.6 as well) are removed from the releases list. I don't know how Drupal releases work - is such a thing possible? I still get daily e-mails from the update status module in all of my sites telling me that there is a new release for download. I ignore them, knowing that installing 6.x-1.7 will corrupt data. But others may not know this, not having checked the issue queue.
Is there any way we can roll back so that the current recommended version is 6.x-1.5 again, so that others don't try to install the update?
#42
I am not one to say the unnice version, a) because I do not feel that way and b) because it's not my style. I do realise you put in your hard work for free.
But I am rather ticked off because I have to do loads of cleaning up now. And I think that it could have been avoided by better testing.
#43
I committed the code after I tested it on my test site, where it worked and updated it without any problems.
If you would have read my previous commit, you would have noticed what I said.
#44
In general, bugs are not a nice thing. But I would agree with kiamlaluno.
I installed this update twice. In testing environment and at productions servers. Please note, that my staging server is exactly (as much as I know) same as production servers.
For staging server everything went well, I got new version, didn't see any error.
But the update failed at production servers, and currently I am restoring the database...
A bad thing, but some bugs are difficult to reproduce. I am really unhappy at the moment, but appreciate kiamlaluno's work. Such thing happens sometime.
#45
"#44
Lonebuddha - December 9, 2009 - 11:41
I am really unhappy at the moment, but appreciate kiamlaluno's work. Such thing happens sometime."
Sometime? This module is having too many "incidents"...
#46
Very serious problem. I'm sticking with 1.5
#47
I have learned a painful lesson - backup your database before upgrading! Is there any way version 1.7 can be pulled and the previous version posted instead? This request is in the interest of limiting the damage to those already impacted. Thanks!
#48
same problem here...
#49
I agree with Lonebuddha. Of course it is not nice to have a bug in an module but things like that may happen. I also would like to remind people that only a few of us, if any paid for this module and that it is developed for free. In addition, these bugs are not here purposely. Please keep this in mind. I appreciate that kiamlaluno is here and puts his effort into making available such a great and helpful module.
#50
Same here. My keywords are now "< lin k rel="canonical" href="/a%3A1%3A%7Bs%3A5%3A%22value%22%3Bs%3A103%3A%22a%3A1%3A%7Bs%3A5%3A%22value%22%3Bs%3A77%3A%22a%3A1%3A%7Bs%3A5%3A%22value%22%3Bs%3A51%3A%22a%3A1%3A%7Bs%3A5%3A%22value%22%3Bs%3A25%3A%22a%3A1%3A%7Bs%3A5%3A%22value%22%3Bs%3A0%3A%22%22%3B%7D%22%3B%7D%22%3B%7D%22%3B%7D%22%3B%7D" />"
My upgrade frooze at 41%
#51
I think everyone has got the message that there is a problem... is there anyone out there who can help with diagnosis of & perhaps resolution of the problem as I think the update worked for the maintainer (kiamlaluno) ... if he needs further info that is...
#52
Same problem. Subscribing.
#53
When I attempt to run the update I get the usual stuck on 49%.
Error appears to be in function nodewords_update_6156, as mysql log shows 000's of
SELECT * FROM nodewords WHERE name NOT IN ('dc.date','location','robots') ORDER BY mtid ASC LIMIT 156, 10
My nodewords table prior to upgrade has 158 entries (which explains the 156 plus the removed location and robots values)
Only changes I'm seeing to the database are that the 'content' field for each row is now serialized.
Am going to keep investigating
PS line 1162 in nodewords.install should it read
variable_set('nodewords_update_6157', TRUE);not
variable_set('nodewords_update_6156', TRUE);#54
I changed the code that should now not give anymore problems.
The problem could have been caused by the primary key used in the table nodewords, which in my test site had progressive values. Infact, I used a module to create meta tags for 1500 nodes, and the values for the primary keys were progressive.
I tested the new update function after I changed the values of the primary key, and I didn't get any errors, nor the update hanged.
#55
Just tried updating from 1.5 to the new dev version .... update froze like before... as I couldn't update from 1.5 to 1.6 maybe there were 2 problems? Should I open a new issue?
#56
Update not working.
Tried updating using dev version, the update indicator has stucked where it was, "updating remaining 1 of 1".
PLEASE SEE
#57
@JamesOakley: The post that you reference has no instructions for restoring nodewords data, it seems to be talking about the different way Nodewords is handling pages that are Views. Is this the post you meant to reference? If not can you point me in the right direction?
I attempted to update from 6.x-1.0 to 6.x-1.7 and, same as others, the update.php script stalled (in my case at 96% with 2 updates remaining). I have a number of other modules to update on my site, so I need to downgrade this one ASAP. I have a database backup but would prefer not to go that route since I updated a number of other module before this one gave me problems. I'd prefer to restore only the nodewords affected data. Any help is appreciated. Thanks for all the efforts here.
#58
The new archive for the development snapshot will only be available on 12:00 AM UTC.
#59
Replaced nodewords_update_6156() with code below
<?php
/**
* Implementation of hook_update_N().
*/
function nodewords_update_6156() {
$names = array('dc.date', 'location', 'robots');
$ret = array();
$metatags = db_query("SELECT * FROM {nodewords} WHERE name NOT IN (" . db_placeholders($names, 'varchar') . ") ORDER BY mtid ASC", $names);
while ($metatag = db_fetch_object($metatags)) {
if (@unserialize($metatag->content) === FALSE) {
$content = serialize(array('value' => $metatag->content));
db_query(
"UPDATE {nodewords} SET content = '%s' WHERE mtid = %d",
$content, $metatag->mtid
);
}
}
variable_set('nodewords_update_6156', TRUE);
return $ret;
}
?>
and run the installer with no errors and nothing showing in logs, removing the batch API stuff with sandbox and ret['#finished'] seems to allow it to complete.
#60
Re: #57
Sorry: My mistake. I've corrected the comment above (#15) where I linked to the wrong issue.
I'll post the correct one here as well. I meant #613376: How to downgrade broken nodewords 1.1+ to 1.0 for a smooth upgrade to 1.3
That will tell you how to restore 6.x-1.0 from backup, from where you can install a working release. At the time that post was written, that entailed avoiding 6.x-1.1 and 6.x-1.2, hence it gives instructions on how to upgrade to 6.x-1.3 cleanly. Probably, you want to restore 6.x-1.0 from backup, then go straight to 6.x-1.5 (which is what I did). I'm still on 6.x-1.5, given that I know 6.x-1.7 is broken, and that 6.x-1.7 came out so quickly on the heels of 6.x-1.6 that I suspect there must have been some problems with 6.x-1.6 as well.
When 6.x-1.8 is out, and people report that the upgrade has gone smoothly, I'll move to that.
Sorry again for the wrong link
#61
Please change the recommended version to 6.x-1.5 to avoid anyone else having to waste 5 hours of their time trying to rectify what 6.x-1.7 does to their websites.
I applaud your work on this module to date, but think it is irresponsible to still have an update showing as the recommended version which is obviously seriously flawed as can be evidenced by the multitude of reports here and my own personal experience.
#62
The reccommended version is decided by the module project.module; it is not something that can be changed from the maintainers.
@#59: Try having 1200 meta tags, and you will see the update function will hang.
See comment #58; please stop changing the status if you didn't try the latest development snapshot, which is where the code has been changed. There are 13 hours before it is midnight UTC.
#63
Upgrade from 6.x-1.3-beta5 to 6.x-1.7 failed.
Freeze at 85 %
Back to 6.x-1.3-beta5
#64
#65
@JamesOakley Thank you very much and thanks to hass who posted the downgrade steps you referenced.
All went smoothly, I downgraded to 1.0 after uninstalling, restored the nodewords table then upgraded to 6.x-1.5. I was then able to finish my sites upgrade. I upgraded core and 20 contributed modules in total and this was the only issue I ran into. Not bad I'd say.
#66
no backup, so for me, not fixed.
#67
subscribing
#68
subscribing
#69
It's not just hanging. It's pinning the CPU at 100%. I'm running on a VPS so I can see that. Hosed on 4 separated setups. Luckily I was able to re-install 1.5 and looks like it never killed my databases.
#70
@mustardman:
Just be sure: Check what the keywords and description are set to for a page that had meta tags defined, or what the default values are for the whole site.
#71
Thanks to the developer for the great work on this module. Eagerly awaiting a fix. Subscribing.
#72
Thank you again kiamlaluno for all the great work on this module.
- Murphy's law
#73
@mustardman: When you wrote your comment was 8:59 PM UTC.
You didn't try the development snapshot that would fix the database; that's for sure. In that case, how can you mark the issue as needing work if you didn't try the last committed code?
#74
Thanks kiamlaluno,
The development snapshot works perfectly. Thanks for all you do!
#75
OK. I've been thinking.
Yesterday I was slightly angry. Not only with kiamlaluno but also with myself. I should have made a backup before applying a patch.
What this slight uproar made clear for me, is any patch or update needs to be more thoroughly tested than just the developers website. Even 5 testers give much more certainty that it will work on other sites too.
I volunteer for testing. Anyone else? Kiamlaluno, if you accept, we should make arrangements outside of this forum. You can contact me through PM.
Erik-Jan
#76
A very general comment:
1. We appreciate the work of module mainatiners, and are grateful for the code (extra functionality) you are providing to us (for free)
but
2. Everything became so seriuos (this stuff is used on production servers!) that we also expect certain quality of what we are getting
So, I wonder how this module can have so many "final" releases in so short time?!
I can see only 2 options:
1. Changes were actually minor - so, not so big that each of them would really deserve to be called a new version (I hate such approach, as it is quite misleading - why not mark such releases 1.0 1.0.1, 1.0.2 etc. rather then 1.0, 1.1, ... 2.0, 3.0... ?!)
2. There was by far not enough testing between those releases (we know also alpha end beta releases, which are known to be "quite delicate" generally + release candidates, which are published to the wider community later...)
This is not the only such module, but why we don't use this approach:
- when the maintainer believes something can be a new version (and, before he starts to significantly change the functionality...), he/she publishes alpha or beta releases (depends on how much he/she believes the code shall be stable / how significant changes from previous version actually were...)
- when there are some positive feedbacks (or, at least there are no serious bug reports...), this becomes a release candidate
- based on the feedback, release candidates are improved (or not, if not needed) and finally one of them becomes a new version
This way, we are not bothered with Drupal update system when new alphas and betas are out (and, we are also aware that these shall not be put on production servers just like that...). The ones who have test installations (and, enough time at that moment to spare to recover, if something goes wrong...) can however test them. After, we are informed that there is a new release candidate. If server is not mission critical, some may decide to put it on. But, we are still not requested to update (yes, the new mailing option is actually bothering us - it is great, but only as long as we can trust the new versions!). Only after there is no unresolved serious bugs and there is some positive feedback, we get the information that we have to update.
This way, there would be much less complains as we can see in this thread, and much much less time wasted (counting the sum of time many people spent to recover - it was perhaps much more that the maintainer spent to do the changes...). And, no excuses that Drupal system is the one who is keeping and pushing the 1.7 version.
kiam, I suggest you publish now the -dev version as 1.8 ASAP (so there will be no new victims of 1.7...), but after that publish new versions as betas and release candidates (and, wait for some feedback...) before you declare them as new verisons.
Just don't become as Micro$oft - with every fix for 1 bug you get 2 new bugs... That's why I rely on linux for servers, and my life if much easier since that decision (and, there maintainers are much more humble about versioning - you can see many very stable release candidates being out for months, before being approved as new releases...)! ;-)
#77
thank you for this, good work
#78
@Luti: I agree with what you say, but that is possible only if there are people who help in testing, and suggesting changes to the code.
If you look at the statistics, version 6.x-1.x-dev is used on 236 web sites, and only 21 web sites are using version 6.x-3.x-dev (out of 34,704 web sites using a version for Drupal 6); that means most of the people don't even know there is a version that supports tokens, nor they are interested in the future of the module.
I perfectly understand that not all people are developers, and not all people can be involved with Nodewords when they are busy with completely different projects, but I also think that one single maintainer cannot do miracles.
So far, I only received the offer to collaborate on the development of the module from ilo, who started with pointing out things that should be changed, and writing a SimpleTest suite (see also #640902: Nodewords, future plans and possible Roadmap ).
What it is really necessary is to extend the SimpleTest suite so that any changes of the code are completely verified before the code is committed in CVS.
I am already writing a module that automatically generates meta tags content; that module would allow to test the code when the number of meta tags is very high, and would allow to find which parts need to be optimized. It would a big help, but it doesn't resolve the problem of having a test suite that would allow to effectively verify if the code works in every conditions.
#79
just updated with dev code with no issues,
@#62 had just rewrote again (slightly differently) to use current mtid in sandbox when the dev code became available, apologies for changing status and thanks for all the hard work getting it fixed.
re: #76 would happily test and feedback on betas/RCs if they were made available.
#80
A general comment about applying module updates:
Anyone who applies an update to a production site without first taking the site off line and making a code and database backup, is acting foolishly and is going to get hosed sooner or later. Module developers are responsible for their code, but you are responsible for your site. If you test updates on a staging site first, then problem updates such as this one will never get past the testing phase and won't take up a minute of down time on your production site.
kiamlaluno, thanks for maintaining nodewords.
#81
Have successfully done a straight upgrade from 6.x-1.5 to 6.x-1.8 thanks....
As a final thought, it just goes to show that something positive has come out of this with volunteers for future testing etc....
And for the rest of us who can't help, no matter which modules we install (especially many modules at once scenarios), theres no excuse for not installing in a controlled manor with backups and using a test > development > live type set up etc etc as this kind of thing can happen anywhere, anytime!
#82
kiam,
don't misunderstand me, please. I don't blame you, I am sure that whatever you've done you've done with best intensions and that you've also tested the new version.
But, the fact is that you simply can not test all possible combinations that appear around (updates from different old versions, other modules that can interfere somehow, different versions of MySQL etc.), and there will probably never be such a suite or tool which could do that (if nothing else, such thing will probably also always be more or less buggy...).
So, the best "test tool" is always a community.
There are many reasons why it seems as you say - that there are very few people who test version 3.0. You must know that people who have Drupal 6 mainly have it for stability reasons, and you can hardly expect them to test much. Maybe they would put some release candidate on the test installation, if they are attracted with some new functionality (or, some serious issue in the previous stable version), but to risk with development versions is hard to expect. On the other hand, peole who have enough time, and are keen to experiment a bit, probably today "play" with Drupal 7 already. So, you have to look for a "test base" for novelties among those, not Drupal 6 users, by my opinion (and then backport new features to older versions, when they are quite well tested already...).
But, there will always be a group of people who need some new functionality or some issues of current stable version (which maybe only they and some other have because of a very particular configuration...) to be resolved (otherwise, why to introduce changes at all...). These people will probably grab any new development version immediately, to see if they are any closer to their target with it. As soon as it would be declared as beta (based on positive feedback of first few testers - or, no feedback at all, despite it has been downloaded about 500 times...), probably some new would appear, who maybe doesn't need something new so much, but it still sounds interesting to them enough (as beta shall mean that there are big chances to avoid serious breaks installing it in one side, but that something will probably not work exactly as expected on the other; in such a case, I say to myself - what the hell, I can still go back to the old one...). When it is at release candidate stage, probably some of the rest will decide much easier to risk a bit, and put it maybe even on the production machine (because the new functionality will attract them more than a fear from bugs; in any case, bugs here shall not be the critical ones anymore, generally...). That's at least how I think...
I am confident respecting those stages would help all of us. This system prooves itself in linux world every day in one side, while there are more and more users, who are not impressed anymore (comes with experiences...) by software, which grows in one year from version 1.0 (this is usually as soon as it appears, without any previous beta or so...) to version 5.4 (meaning usually that 5.0 - 5.3 had serious bugs and were released within a few days one after another...). I am much more impressed by version 1.0.2.1 or 1.0.2-rc4, for example... ;-)
#83
I'm glad to report that update from 1.2 to 1.8 (my production site) and from 1.3 to 1.8 (my test site) went smooth and without any issues. Everything seems to work well.
#84
Hi,
getting back from #8 - indeed the queries were dying after a few hours, but updates could never be completed. However, as far as I can see, no harm was done.
6.x-1.8 fixes the issue with database issues, so adjusting the version.
Thanks kiam!
#85
How do I get rid of all the of the meta tags that now are prefaced by all that junk like a:1:{s:5:"value";s:243:"xxxx[...]en";}
#86
1.8 worked smoothly.
Thank you for this terrific module, kiamlaluno, and for all the work you put into Drupal.
#87
asb - the problem IS with 1.7, not with 1.8 (setting version back)
I'm with rkudyba - how do I fix the data that got thrashed? Thanks
#88
#89
To restore corrupted metatags, I went to Google's cached copy of my website (see #13)
While not an acceptable solution (many may not have the site cached by Google), at least for some, is fast and effective.
Thanks kiamlaluno!
#90
Hello everyone,
Try following steps:
1. Unselect nodewords/Metatags module options from modules page of your site. Remember not to uninstall them
2. Go to your server and find nodewords in your modules folder.
3. Delete nodewords folder
4. Upload new nodewords folder
5. Run update.php
6. Go to modules page again and select required options.
and its done.....
If you don't know how to do above steps, please pray that developer of this module find the problem very soon.
Thanks ;-)
#91
Thanks dispa, I'll try it.
Why does everyone insist on changing the version of this bug report? The bug is with version 1.7 and no other.
Rugman, your steps are to upgrade to 1.8, I think everyone knows how to do that, but it doesn't address the problem of remaining corrupted data.
#92
#93
Hello starminder,
This solution applies for those left with "hanged" update status.
:-)
#94
Rugman, I tried that and still the "junk" code appears in the pages/stories.
#95
subscribing
#96
Rugman - thanks, I can only guess that perhaps 1.7 did not corrupt your data, or you haven't yet seen the mess. Thanks for offerring your solution, but it does nothing to fix the disaster that got left behind. You may want to install SEO Friend and run a meta tags report to be sure.
#97
The version is set on the version that can be fixed, and that has been fixed ASAIK.
You cannot fix a problem in version 6.x-1.7 because you cannot release that version twice; you can only fix the problem in the development snapshot, and that is the reason the referring version is that one.
As reported from users here, the update doesn't fail to complete anymore; therefore, the problem has been resolved.
If there are problems lefts from the previous update function that is a different issue.
The that somebody says to see is simply the serialized form of an array, which is what it is seen because the update function has been run twice or more times.
I will create another update function, or I will think to another way to fix the saved meta tags; probably it is better to do it in a cron task, or to use job_queue.module.
#98
@LUti: I know you are not blaming me, and I have not taken your words like a blame.
If there would be more people interested in the development of Nodewords, and who have a test site as you said, then more people would be testing the branch 6.x-3.
I reported in the issue queue the changes I made on that branch so people can know which features has been added to that branch; I also started attaching a patch for the changes described in the report.
The fact one is already testing the development snapshot for the branch 6.x-1 doesn't mean s/he cannot test the other branch as well. In my test site I have two installed Drupal 6 twice, so that I can test two different branches of a module.
I am not putting the blame on anybody, but if we are facing the truth, then the truth is that the module is not able to involve more people, and that has been so even before I started to co-maintain this module.
I was using this module from when Drupal 6 was released, but at that time I was still learning how to create a module in Drupal 6; from then to when I offered to become co-maintainer, nobody else has offered to be co-maintainer. That is a matter of fact, and it shows how much interest there is in this module.
I am not putting the blame on anybody, and I thank all who pointed me to problems the code had in some installations, especially when using PostgreSQL. Still, the involvement of the community is very low, compared to other modules.
#99
kiam,
we have to be aware of the fact that web sites are mainly just "a tool", not "a toy for itself"... I mean, consider how much are you involved in testing (and reporting back) the issues of your operating system or some other software (php, mysql...). There is always a group of people who - we can say - live with some (relatively small, comparing to the complete system...) subject, but all of the others mainly just use it, if it works. Or, find another solotion, if it doesn't work stable enough for their needs... Not because they wouldn't mind, but noone has so much time to discuss everything, and work on it (unless deeply involved due to some particular reason...).
So, also for your module, you have to do all you can that users can rely on it all the time. New features are great, but stability is by far a major concern for production use. So, I really suggest you to be a bit slower publishing new final releases (so we can be quite sure we will not damage something; the major issue is to corrupt data, or something appears later - if it doesn't work immediately, I am relatively happy, as I revert the update and this is it...). I support your efforts, but please keep that in -dev version, and publish it as some beta or so before declaring it as working. Then, if in a week or two (at least, maybe even more, unless there are only positive feedbacks before, from very different environments...) there is no noise about, go ahead. But, it is just my advice (and, I see you have been doing as I suggest not far back in the past, and things went relatively good then - but, when you started to "jump to new versions" quickly, it bited you...).
About the version, I'd say you are not right (as I understand and use those versions...). 6.x-1.x-dev is not affected by the bug, which is the subject of this issue (as at today). I wouldn't say it never was, but it was maybe a very shord period of time, and mainly people were reporting that for version 1.7, not -dev! On the other hand, 6.x-1.7 is, and will always stay buggy (and very dangerous). So, it would be much better to keep version for this issue 1.7 by my opinion. I wouldn't say that some issue has to be resolved within the same version. Or, better said, it is even not possible - as you can not have 2 different versions with the same number, teh buggy one and the good one (fix for a bug in some version is always a new version!). So, with every new version, the discovered issues from older versions are (should be) resolved. But, the issue remains the issue of the old version (and, you are referring to it like that also in the future, after this version is already obsolete...).
Why is this important? When I see a new version coming out, I read all newer issues for that version and for a -dev version (which may already be newer, and with some fixes for the latest version - but with some new issues introduced...) - just to see if to go on with the suggested (latest) final version or maybe with development version (or, to wait a bit more, as in this case...). But, I skip all issues of older versions, which are marked as fixed - as I really don't have so much time to read everything (my core business is something totally different); maybe (if I have enough time...) I take a look in some other as well, but only the ones marked as opened or as "won't fix" - just to see if the issue is still unresolved (and if I shall expect it to affect me as well...). So, why should prople read this relatively long thread through, if this is not the issue anymore?!
If nothing else, if it would be as you say, all closed (fixed) issues should be marked as belonging to -dev (as they can not be resolved within the same = unchanged = release, but it definitely is not so). Just take a look, you also have fixed issues of final versions (as #619646: Table nodewords_custom doesn't exist for example...), not to mention the other modules...
So, I'd say this should be (and always remain) the issue of version 1.7 and not -dev (hopefully it will not reappear...). I will not touch it (it's your court at the end...), but that's my opinion.
#100
@Luti: I was replying to your .
Though I agree with that, I have to say that the community is simply watching, right now.
So far, I get only a request to become co-maintainer from ilo, who is now busy with different projects. If I would not have offered to become co-maintainer, the module would have been not changed at all. I imagine it is so because, differently, there would have been more people asking to become co-maintainer, which is not happened.
To reply to your affirmation, how can use the if there is nobody who offers to help? Do I stop the first person I find when I go out, and force him to write code for Nodewords?
To note that if somebody wants to test the module code, he doesn't need a special invitation; the development snapshot is always available to anybody, and all people are free to download it to test it. If people would really like to help testing the code, they don't need me to give permission as the code I write is publicly available.
#101
kiamlaluno - This is your project and you can do what you like regarding the version, but I am a Release Manager for a living, so please hear me out. The bug was reported under version 1.7, and therefore it should stay that way until closed. If you fix this problem and then change the release tag to 1.9, everyone will think there is a problem with 1.9. When you report as fixed, you should instead note which version contains the fix in your entry, but again, overall the problem tag should still always say it is 1.7, so people understand there is an existing problem with that release.
I'll leave it alone after this, I am merely trying to help - but changing the release tag is a disservice to everyone. The bug was reported under 1.7, and since 1.7 cannot be fixed, 1.7 will always have this bug. Changing the tag just confuses the situation. Rant over, thanks.
#102
Also, I for one do not consider this problem resolved. The Title indicates the bug corrupts data, and my data is still corrupted.
#103
@Starminder: The code for version 6.x-1.7 is the same code that is in the development snapshot because a stable release is created from a development snapshot, in Drupal.
Also, if an issue still needs to be fixed is because the development snapshot didn't fix the issue; therefore, the problem is always in a development snapshot.
To resolve the corrupted data, I need to know which meta tags seem corrupted, and what the content for those meta tags is.
I tested the update changing the content of the meta tags in the format used before, then I executed the update; when I checked the meta tags content, I didn't see any corrupted data.
#104
The tag value of my tags "keywords" appear to have a:1:{s:5:"value";s:25:"a: mixed in. I'll probably next go try fix it in the table if a fix isn't provided. I was able to go to the default meta tags and delete a bunch of this stuff directly.
I completely disagree with you on the bug report tag issue, but I promise not to lose any sleep over it. :) Do as you wish, but you're not doing it right. The bug was in a released version. That won't change. By changing it, it will lead others into thinking that 1.7 is a safe release. It's not, it is pure evil. Also, it now appears that the current dev version of the module contains this bug. I know it doesn't, you know it doesn't, but by changing that tag, that's exactly how it looks.
#105
It seems then that the meta tag KEYWORDS has been serialized twice; I will create an update function as soon as possible.
#106
@Starminder: To be sure I am writing the code correctly, I need to see the complete string.
#107
The code has been changed and committed in CVS (#300940).
#108
So, using this logic, the version for EVERY issue should be 6.x-dev because that's where the problems are fixed. Why even bother with a version at all in that case?
Sorry, but I agree with Starminder. And so, I believe, does everyone else.
#109
I've been following this thread and can't believe some of the comments:-
1.7 was released with a bug, it happens get over it! 1.7 is no longer on the project page so no one else should install it. It's pretty clear that 1.7 should have remained a "dev" version for longer so there is a lesson to be learned there.
However, everyone who had a problem with 1.7 should have restored back to the stable 1.5 version (or 1.6 if that was ok for you) and then upgraded to 1.8.
Anyone who didn't take a back up only needs to look into the mirror to see who is responsible for any outstanding issues from that faulty release!
I sympathise with anyone who didn't take a back up but what you are looking for is a one off fix for the corrupted data. If it was me I would be "grovelling" for help (and acknowledging my own foolishness) or fixing the data myself.
I would count myself lucky that the maintainer has been willing & more importantly "available" to help at all.
If anyone has a problem with the way the Drupal release system works then they should join the relevant group & argue for change as an individual maintainer cannot unilaterally change "the system".
#110
kiam,
I'm not sure we understand each other well...
If the community is just watching, you should have nothing to do. OK, maybe to fix some still unfixed bugs (remaining from the past) and issues (which were reported, so there was some feedback...), but if there are no feature requests, why to introduce new features at all? ;-)
When you fix everything still opened, you publish a beta version of next final release. If there is no feedback within certain period, you publish it as RC. If there is still no new issues reported, you publish it as next final release.
This has nothing to do with how much help you mainatiners get from the others (community). I agree it should be more, and try sometimes to something small by myself (altogh I am not a programmer and to do anything like that I need hell of the time practically guessing and experimenting...). I am not complaining about how quick do you resolve the issues or so. I understand you need time. I understand also you are spending your free time, and you owe us nothing. I appreciate what you do for us. But still, don't spoil all your efforts and time you put in the maintenence of this module just by publishing new "final" releases (which than cause some serious problems to the users of your module) too quickly, please. Mark them somehow so that we know they should be it, but are still not tested much in many different real environments yet...
#111
I don't agree with what you are saying.
If it would be as you said, then Microsoft should have not created new versions of Microsoft Office because nobody asked Microsoft to do so. Talking of Drupal modules, no new branch should have been created because nobody asked to the maintainers to create new branches.
#112
I'm with MJD on this. Chill guys, chill - things happen. (ps, I really do the the version should be set to 1.7 and node-dev, but hey). Thanks for a great module kiamlaluno!
#113
kiam,
are you sure you are not mixing things a bit? ;-)
M$ is selling their Office, while you are making a kind of favour to us (for free). If they wouldn't develop something new, their customers would be happy with the old version, and wouldn't believe they need a new one. So, no fresh money for M$... If we are happy (and don't ask for something new), you are not loosing money, you can just relax a bit... ;-)
I personally would even be happy if there wouldn't be those last new releases. I like the basic functionality of this module, and appreciate when this module (as many others) are adapted to work on new Drupal releases. But, recently I've been reminded a couple of times (within very short time) by Drupal that there are new versions out (and, I am not up to date anymore). And, I've updated just because of that (alternative would be to go carefully through all issues, to see if there is some security issue fixed, or some incompatibility with some other module or so - why also I should update - or I can skip this update, because there are just some new features I don't need; I believe this would be even more complicated and time consuming for me...). So, those new features are not really some benefit for me (at least at the moment, according to my current needs), just more work. If they would be published as RC or Beta (so, not as recommended releases), I probably wouldn't installed them, and would live happy without all those troubles. This way, only some people who are attracted by new features (and probably need them / will have a benefit of them) would install those releases, and most probably they would also provide some feedback to you - at least this issue would be reported for sure (saving much time to all the others, who doesn't really need something new, but just want to be up-to-date...). Why do I have to be a victim of development of something I don't really need? I would find it fair to have at least the opportunity to decide if I want to take the risk or not...
#114
@LUTi: You are too mixing things. :-)
First you talk of community support, and then you say you would not install a release candidate or a beta release; if all people would do so, from where do the community support come from?
The support is not only to test a beta release or the development snapshot, but it is also to chime in, and report a comment in the issue reports. There are people who open a bug report, and then don't come back to give more information as requested by the maintainers. As a matter of fact, I created an issue to report something was wrong in the code, but the interested person who opened an issue about the canonical URL not using a path alias will not notice that until the new code is in an official release.
About changing the code without an explicit request, what should I do if I notice a bug that has not been reported? Or what should I do if the current code need to be rewritten to make it more extensible or ? If I would have wait for any report, the module would not have changed a lot from the original code, and I don't think that is called to maintain a project.
#115
Has there been a fix published for the serialized keywords issue?
#116
@rkudyba: Yes.
#117
I'm lost - how do I apply the fix?
#118
Is it in the dev version? Just install that?
#119
I wrote a very big comment, and after that I can brief into:
"Keep going KiamLaluno, go and keep doing the good work."
I personally found release status for this project a little bit tricky also, so I did open issues about that (some are to better document the status of a single release, others to stablish a roadmap for future releases). Probably this is the way a "community" meets an issue queue. Don't expect, do.
I also agree with kiamlaluno about 'community' feedback.. I've seen kiamlaluno talking to himself or just me in many, many of the issues. So, feel free to subscribe to the issue queue, and comment on any issue you want to do, but proposing release management cases in the middle of a bug request is not the way, I'd say.
Don't forget, maintaining a module requires a lot of work, thanks kiamlaluno.
#120
I agree with LUTi in #113. Maintaining a module does not mean rewriting the module to "make it more extensible" or adding new features when very few people want these new features. And especially not when rewriting the code (which previously worked fine for 90% of the people using the module) causes new bugs to be introduced.
To rewrite the module and take it a completely different direction, with different focus, well that sounds to me like it should be a fork.
#121
Except that version 6.x-1.0 (the version I have not developed) had a security issue, and I fixed it in the development snapshot before the issue was even reported me from the security team. The changes I made when I known of the security issue were to optimize the code, and make it more generic. If I would have done what is suggested here, you would not be using Nodewords anymore.
Then, most people don't even know the datatype used for a field. Does that mean I should not change a field defined as varchar (which is excessive for just containing 10 distinct values) to an integer just because I didn't get any report about that?
If then you all are telling me that maintainers of modules such CCK, Views, Rules, released a first release of the module, and then waited for any feedback from the users, then I don't believe that not even for a second.
#122
I think we have gone a little OT, with this issue report; considering that has been marked as fixed, there are no more comments to do.
#123
Automatically closed -- issue fixed for 2 weeks with no activity.