Parse error on nodewords_tokens.module: new release needed

today's release nodewords 6.x.1.3-beta4 ?

Me too. Today's version. Crashed the site, I removed nodewords_tokens module, and it's back working again.

Parse error: syntax error, unexpected ';' in /home/socalmov/public_html/sites/all/modules/nodewords/nodewords_tokens/nodewords_tokens.module on line 135

There is one missing bracket before the semicolon at line 135, and also at line 136.
Well, even with the brackets, your site will work, but you will get PHP warnings.

same :)

Same error with 6.x-1.x-dev (2010-Mar-22 )

see http://drupal.org/node/749124 for the fix :)

Ronald

Same patch as in #3
It works but doesn't resolves all PHP warnings.

@author,

Don't you test your codes using php -l at the command line for such silly syntax mistakes ???

I know PHP, so fixed it myself. What about those who don't know PHP ?

This version chaos is confusing. I don't remember anymore why I was on beta 3 but I checked the release notes before upgrading from beta 3 to beta 4 and there's nothing in there that says not to use beta 4. You need to put critical information like that in the release notes. Most people don't check the project page when doing a beta to beta upgrade from update status.

Michelle

The release notes are linked to from update status. When you're going thru updating 20 modules and checking the release notes for any "gotchas" you aren't going to go into each directory and look for extra readmes. If you know the release has a critical error that renders it completely unsuable, that should be noted in the release notes.

Michelle

kiam: I think Michelle has a point. This would have caught us too if we were using 6.x-1.12. It should be in both places. Sorry if that's more work.

Don't set something with an upgrade path as the "recommended version" very few people look at the project page, we just update our mods when the status report tells us to and we update to whatever version is recommended.

Perhaps you could suggest a fix for the scores of people who upgraded directly to this version 6x 1.12beta 4 because the update module told them to, as from what I can tell, the only solution given is to downgrade to 6x 1.9...i did that and got:

"user warning: Can't DROP 'path'; check that column/key exists query: ALTER TABLE nodewords_custom DROP KEY path in /xxx/xxx/public_html/includes/database.mysql-common.inc on line 417."

same story downgrading to 6x 1.11

I HAD 6.19 and it worked fine... installed recommended and got:

syntax error, unexpected ';' in /xxx/xxx/public_html/sites/all/modules/nodewords/nodewords_tokens/nodewords_tokens.module on line 135

and lastly, while I'm marveling over this whole issue, you stated several times that you include an upgrade path on the project page...here is what I see there: (bolded text is my commentary on the step)

•update to version 6.x-1.9 (if the currently installed version is older than this version), and run update.php; had 6.1.9
•update to 6.x-1.12-beta5, and run update.php; exactly where would i find this beta 5? I upgraded directly from 1.9 to 1.12-beta4 and it fubar'ed my entire site
•update to version 6.x-1.12-beta6, and run update.php. yet another step in your 'upgrade path' that doesn't exist
A direct update to version 6.x-1.12 will cause database errors. it sure looks like you go directly from 6.1.9 to 6.1.12 from the path outlined above...I see no mention of 6.1.10 or 6.1.11
Version 6.x-1.12-beta5 should be used just to update the database, and to allow the successive update to work; do not install version 6.x-1.12-beta4, or 6.x-1.12-beta5 to use it. "do not install version 6.x-1.12-beta4" yet that is the recommended version.... ok thanks

For the love of all things decent, pure, and mildly responsible, how do I fix this issue? At this point I don't even care if I have to re enter every setting, description and keyword for every page on the site...how do I clean this mess up.

Agreed. This should not have been added as recommended upgrade. This issue is marked as fixed, but what is the official fix?

Personally, I am going to dig into what all needs to be deleted from the database and manually root out all reference to nodewords. I am pretty 'green' at writing queries so I will probably just go through it by hand and delete all the nodewords entries from the system table and the nodewords table in it's entirety. I'll keep track of what I remove and from where and if it resolves the issue upon completion upon reinstall of one of the previous versions; though, at this point, I am unsure which version would be considered the most current stable version.

6x 1.11 threw an error when I downgraded to it and tried to save pre-existing nodes "Location coordinates (latitude, longitude) cannot be longer than 14 characters but is currently 51 characters long." and inserted the following a:2:{s:8:"latitude";s:0:"";s:9:"longitude";s:0:"";} into the location coordinate field. This is issue http://drupal.org/node/735236 and it was marked as duplicate of http://drupal.org/node/669896 though I fail to see how that is in fact a duplicate in any way, but that may just be me misunderstanding the error in the first place).

Unfortunately, the only resolution for http://drupal.org/node/669896 is to again downgrade to 6x 1.9

So I guess (and I use that term lightly) that my best bet is to clean the DB then reinstall 6x 1.9 version that I had prior to updating??

Wow, if someone who understands this better than I do could weigh in here, I'd be very appreciative :)

Edit to add: I thought I'd just try uninstalling the module from the module page and then running update.php and then installing 6x 1.9, but it threw the following error:

user warning: Table 'nodewords_custom' already exists query: CREATE TABLE nodewords_custom ( `pid` INT NOT NULL auto_increment, `name` VARCHAR(60) NOT NULL DEFAULT '', `path` MEDIUMTEXT NOT NULL, `weight` TINYINT NOT NULL DEFAULT 0, `enabled` TINYINT NOT NULL DEFAULT 1, PRIMARY KEY (pid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */ in /home/villacol/public_html/includes/database.inc on line 550

So I guess it's database diving I go :(

Edit 2: ran update.php a second time and the error went away so I *guess* it's OK now... /scratches head...

drush update still pushed this update to a site of mine 20 minutes ago. I added two )s to line 135 and 136 as such:

$values['metatags-frontpage-normal-url'] = nodewords_url(drupal_get_normal_path(variable_get('site_frontpage', 'node'), array('alias'\
=> TRUE)));
$values['metatags-frontpage-url-alias']= nodewords_url(drupal_get_normal_path(variable_get('site_frontpage', 'node')));

It seems to be working fine now.

After getting serious database errors updating to the recommended version, the only thing I could do was delete the module & try to upload the previous version.
Result, no errors after update.php, but no description & keywords on frontpage, even if I can see them on the /nodewords/meta-tags/frontpage page!

Since I had to go through countless pages a couple of weeks ago, cleaning meta tags after they were messed up by some update with this type of characters ... "a:2:{s:8:"...", I'm actually quite worried when I update this otherwise nice & important module.

These are the only tags showing on the front page:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>...</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="copyright" content="..." />
<meta name="revisit-after" content="1 day">

I wonder how to correct this?

Since I had to go through countless pages a couple of weeks ago, cleaning meta tags after they were messed up by some update with this type of characters ... "a:2:{s:8:"...",

That is the issue (http://drupal.org/node/669896) I mentioned in #17 which is why I chose to roll it all the way back to 6x 1.9

These are the only tags showing on the front page:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>...</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="copyright" content="..." />
<meta name="revisit-after" content="1 day">

You got more than I do now... I have

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="meta" type="application/json" title="RDF" href="/rdf" />
<link rel="meta" type="application/rdf+xml" title="Calais RDF" href="/node/150/calais/rdf" />
<link rel="meta" type="application/rdf+xml" title="Calais RDF" href="/node/149/calais/rdf" />

and that's it for meta tags now :(

Cleared cache as suggested elsewhere, made sure all parts of the module were enabled, and made sure that meta categories were checked for both HTML Head and edit forms as well as the checkbox for use meta on front page....

It's outright amazing how one little thing could F* up so many things on what once was a pretty much worry free aspect of my site :(

Meta tags are working appropriately on all other pages, I guess that's a small victory ;)

@Kiam

I also added a line that reports that beta release is not thought to be used for each days use, but to just update to the next version.

Then why is 6.x-1.12-beta4 set as the recommended version? Most modules reserve this for the latest stable version with relatively few unresolved issues. In many cases (modules) this version is often one or two releases behind what the maintainers 'consider' the most current stable release just to be safe.

As best I can tell from the issue queue, your last stable release with no outstanding issues was 6.x-1.9
6.x-1.11 has the aray issues noted above still unresolved and with the 'fix' for the issue listed as 'downgrade your nodewords to 6.x-1.9'

6.x-1.9 should be listed as the recommended version

We are not to use beta4 until beta5 is released, but beta5 is not there and beta4 is..
Issue is marked fixed even though questions keep adding to this post.
So, please clarify which version is the one to use now? Is it beta3 still?

This is the problem for anyone who is currently on a beta:

Now you could argue that we shouldn't be on the beta at all but I don't normally go seeking out versions that aren't listed on the project page to run on my production site. So there was some reason I installed it that I just don't remember right now. This tells me that either it was recommended at some point or something in an issue somewhere suggested installing it. Whatever the reason, there are some of us that are on beta 3 that are now being told by update status that beta 4 is recommended when, clearly, it isn't safe to install.

Michelle

@kiam: No, update status won't recommend you go to a beta unless you are already on the beta. That's the problem here. Some people were already on beta 3 which seems to work or at least not have any critical errors. Then you released beta 4 with a critical error and people unknowingly upgraded because update status told them to.

No, it's not the original topic of this issue but this is coming from your response that people should have read the project page or some special file, which is not realistic. Granted, not everyone reads the release notes either but I think it's reasonable to expect people to do that, at least, since they are linked to right from update status.

Michelle

@kiam , Please let me know which version of Beta to use. Is it beta3? and if so, how will I know WHEN to update?
This issue is again marked fixed, which only makes it harder for others to find it.

@Michelle.. You might have moved to beta3 because the recommended release had bugs and meta tags were not being saved. That's why I moved to beta..

I believe that the beta was recommended as upgrade from stable. I could be remembering wrong, but as I remember it, I thought it was strange that beta was listed as recommended upgrade, but I went ahead and upgraded because I figured the update manager had a reason for recommending that version.

Also, I'm confused as to what the recommended course of action is at this point. Beta4 and dev versions do not install properly. Beta3 does not display description tags for terms. I tried downgrading to 6.x-1.11 but there are database errors when I run update.php. Apparently there are lots of problems with 6.x-1.11 as mentioned in post #22. Perhaps there were even more database updates between 6.x-1.9 and 6.x-1.11.

Should I just scrap the database tables and start from scratch with fresh install of 6.x-1.9?

Here is the fix (as of 23 March 2010 at 1452 central US time):

cd to the sites/all/modules/nodewords/nodewords_token directory
Change lines 135 and 136 of nodewords_tokens.module to exactly this:

      $values['metatags-frontpage-normal-url'] = nodewords_url(drupal_get_normal_path(variable_get('site_frontpage', 'node'), array('alias' => TRUE)));
      $values['metatags-frontpage-url-alias']= nodewords_url(drupal_get_normal_path(variable_get('site_frontpage', 'node')));

save the file

You should be working again.

The problem is a minor parenthesis misplacement in both lines (omitted parenthesis, to be exact).

Joe

Beta is not ready for use.

I uninstalled nodewords, removed all database entries and started fresh with 6.x.1.11. After applying this patch:

http://drupal.org/node/672096#comment-2532618

everything seems to be working properly.

@kiam ... as requested in #33 I opened a new issue: http://drupal.org/node/751054 since I still can't figure out which version to use and my questions here are not being answered. I can clearly see that many people are asking the same questions and are a bit confused when it comes to the versions of this module.

Hi

Does that piece of code solve the problem caused by the latest update from 6.x-1.12-beta3 to 6.x-1.12-beta4?
Yesterday, I was forced to go back to the 6.x-1.12-beta3, but noticed the meta tags on the front page were missing.

I had tried something similar (editing lines 135, 136) suggested by someone earlier, but had some ugly error message I dont remember, but may be I had some "wrong" version of the module.

I had to take the site offline for several hours while desperately trying to get the front page meta tags by reverting to older versions + using recent DB backups, but had seriously problems with this type of tags:

<meta name="keywords" content="a:1:{s:5:&quot;value&quot;;s:15:&quot;about,about us&quot;;}" />
<meta name="copyright" content="Copyright Orbit  Uganda 2010" />
<meta name="description" content="a:1:{s:5:&quot;value&quot;;s:18:&quot;About Orbit Uganda&quot;;}" 

I finally settled back for 6.x-1.12-beta3. Only the "about page" seemed to be having corrupted meta tags, as a random search could not reveal more pages and I hope it is really the case.

After all this trouble, I would settle for anything that would get the frontpage meta tags back and after that ... there will have to be a very good reason to update ... ;)

Any suggestion?

Regards

@Michelle, I got 6x-1.12beta4 as the recommended update from 6x-1.9 a couple days ago, no beta installed. I can't think of any reason the update module would have done this unless at some point the beta was set as the recommended.

And for those looking for a straight answer, 6x 1.9 is the last version that doesn't have longstanding errors (as in that do not require additional patching at a minimum); however, front page meta tags will not work if you recovered from this fiasco and downgrade to that version...even though they were working on my 6x 1.9 immediately prior to the update to beta 4...

Maybe if beta 4 really is fixed and doesn't critical error sites any more, that is the way to go to get front page meta tags back...I may give it a try tonight, but I am a little aprehensive about that because if it really hasn't been fixed and my site throws a critical, I'm going to need sedation to keep from smashing my head off the keyboard till I am unconscious :)

I'm in the process of putting together a site for a client using DRUSH to download and install the modules. It downloads the recommended version unless you specify otherwise. Why is this BETA the recommended version? Why is untested code being committed in the drupal.org repository?

Surely this code should be in a dev branch? Its like the 6x-1.2 update headache last September all over again http://drupal.org/node/585892 and http://drupal.org/node/587020

So is version 1.9 the last stable version to use which will have an upgrade path when the betas are over?

OK, thanks for the clarification.
My request to you though, as someone who knows this module like no other, is how do I get the front page meta tags back?
With beta3, before the upgrade attempt, they were there. Now, they are only on the configuration page but are not printed. Other pages seem to be OK.

I arrived at this point, after a failed upgrade attempt, by reverting to a db backup made before the upgrade + downloading a new beta3 version of the module.

If the question has been addressed somewhere else, please just point me to it. I just want the meta tags back.. that's all.

Thanks in advance & regards

Frontpage metas and the rest of it is working for me after installing 6.x-1.11 fresh and adding this patch:

http://drupal.org/node/672096#comment-2532618

So how does having a version that has serious errors, even if the version is only to be used as an upgrade path, help things? Seems to me it would be worth pushing a fixed version, say beta5, even if it doesn't have everything that you want in it.

This fiasco seriously undermines the credibility of this module and the releases of it. Dev and Alpha's are something people tend to stay away from but beta's are usually used for versions that are functional.

Aye, I'd say this bug is worthy of an immediate beta re-release with a fix, since it was pushed out in an update that will break folks' entire sites. Beta4 is the version that drush downloads by default atm.

I second what xjm says in #44. We don't want people to download an update either from an Update Manager message, or from Drush, that contains code that will kill their site.

Setting to active until new release is made.

listening.

that'll teach me not to drush upgrade right to the live site :)

To second the comments made in #39 and #44, I am in the process of upgrading a D5 site to D6 and rely heavily on drush to automate this process as far as possible. Drush is, indeed, downloading 6.x-1.12-beta4.

Yes, I just confirmed that Drush is still downloading beta4 by default, even on sites that have never installed the module before. That could be why Michelle ended up with the earlier beta to begin with in #25 above; I know I wouldn't have picked a beta intentionally on my production sites unless there were no stable release available. Something's still not quite right in the recommended release information for the project.

Maybe the beta should be in a separate branch? Edit: I just looked at the project page and, wow. There seem to be a lot of invisible branches and releases.

I opened a Drush issue at #761694: Drush downloading non-recommended release of nodewords. I still think it would be a good idea to release a beta5 (or beta6, or gamma27, or whatever fits in the version scheme) with the parse error corrected.

Drush downloads the beta4 version. You really need to make a beta5 release that at least fixes the bug, or revoke the beta4 release. Why tag a release that had critical code errors in it anyway? I can understand stuff getting into CVS (hey, I've done it!), but when a release is that FUBAR, you really gotta fix it quickly. A LOT of people use Drush and this is a huge problem, so I am reopening the issue. Please fix ASAP.

Ouch! Replace a nodewords (beta) module that works with one that breaks every single site? Come on :(

Moshe has committed a fix for #761694: Drush downloading non-recommended release of nodewords, so folks using drush will probably wish to head on over there to test that patch or the latest drush dev and make sure they get the correct version of nodewords (6.x-1.11). (Of course, that doesn't prevent more people from stepping off this same cliff. I imagine a whole lot more people will still have this "learning experience" about not installing or updating modules in production.)

@#56

I'm not sure this is an issue with drush or the update module downloading a non recommended release.

If you go to the modules section here, 6.x-1.12-beta4 IS the recommended version. (see attachment)

beta 4 would not be listed as recommended there unless kiam had set it as such...

Fix in #32 worked for me. I was having a serious WTF moment there... nothing on the site would load.