After installing the "Recommended version: 6.x-1.x-dev (2011-Mar-17)" all menus disappear.
Had to revert back to "Menu token 6.x-1.x-dev (2011-Feb-25)".

Comments

paul555’s picture

Same issue here.

mjstone323’s picture

Same here - and I stupidly didn't keep the previous version.

Anyone care to share it with me until this gets resolved?

Edit: Spoke too soon - I did have a backup.

alexbk66-’s picture

Any update?

If this release is broken - it should be removed from the server, so status report doesn't complain all the time.

dealancer’s picture

Assigned: Unassigned » develcuy
Priority: Normal » Critical

You should run update.php. It should work ok. Please backup your base before doing that and post your feedback.

We were working on the new feature that allows to keep data in database rahter then in variables (http://drupal.org/node/1087212). New branch was created by develCuy. Somehow new commits to this branch was also made to dev branch. Fore more information see http://drupalcode.org/project/menu_token.git/shortlog/refs/heads/6.x-1.x

@develCuy: could we update project information page and provide reference to this issue?

alexbk66-’s picture

Well, I always run update.php when updating modules.

Here's the result. First time I ran update.php I get the following error:

user warning: Table 'menu_token' already exists query: CREATE TABLE menu_token ( `mlid` INT unsigned NOT NULL, `link_path` VARCHAR(255) NOT NULL DEFAULT '', PRIMARY KEY (mlid), INDEX mlid (mlid) ) /*!40100 DEFAULT CHARACTER SET utf8 */ in .../public_html/includes/database.inc on line 551.

The following queries were executed
menu_token module
Update #6000
Failed: CREATE TABLE {menu_token} ( `mlid` INT unsigned NOT NULL, `link_path` VARCHAR(255) NOT NULL DEFAULT '', PRIMARY KEY (mlid), INDEX mlid (mlid) ) /*!40100 DEFAULT CHARACTER SET utf8 */
Update #6001
Failed: Could not add records to databse

The table was probably left from previous update and restoring database didn't remove it. I remove the table manually and run update.php again.

The following queries were executed
menu_token module
Update #6000
CREATE TABLE {menu_token} ( `mlid` INT unsigned NOT NULL, `link_path` VARCHAR(255) NOT NULL DEFAULT '', PRIMARY KEY (mlid), INDEX mlid (mlid) ) /*!40100 DEFAULT CHARACTER SET utf8 */
Update #6001
Failed: Could not add records to databse

In phpMyAdmin the table is created, but there's a message:

The indexes PRIMARY and mlid seem to be equal and one of them could possibly be removed.
Field       Type            Collation      Attributes  Null Default
mlid        int(10)                           UNSIGNED No   None		 	 	 	 	 	 	
link_path varchar(255) utf8_general_ci             No
Keyname Type     Unique Packed  Field Cardinality	Collation	Null	Comment
PRIMARY  BTREE  Yes      No       mlid	0	A		
mlid    BTREE   No       No       mlid	0	A
alexbk66-’s picture

On the module page there's no 6.x recommended version. The 6.x-1.x-dev version is still dated 17 Mar, so it doesn't look updated.

dealancer’s picture

Hey alexbk66-,

After update is is working now, despite on errors?

If you see

Update #6001
Failed: Could not add records to databse

You should run update again.

I have created release 6.x-1.0-alpha1 with and old version of this module, so if you want you could use it.

alexbk66-’s picture

Hi dealancer, if I run update again, I get 'Table 'menu_token' already exists'.

It works fine with 6.x-1.x-dev (2011-Feb-25).

Are you saying that 6.x-1.x-dev (2011-Mar-17) should work even despite update errors? No, with the new version there are no menus displayed at all.

dealancer’s picture

I am not sure if it would work in 100% cases. I thought the last commit should fix this issue (at least it worked good for me). In this case I need to ask you some questions. Could you updating module to the dev again, please, download latest dev release and in case of errors " Could not add records to database", please run update second time, it should continue to do update from #6001.

You could also comment issue http://drupal.org/node/1087212 (which is related to latest update) as we have been collecting reviews for it.

alexbk66-’s picture

1. Disable menu-token
2. Remove old module folder
3. Copy new folder (6.x-1.x-dev)
4. Ran update.php

user warning: Table 'menu_token' already exists query: CREATE TABLE menu_token ( `mlid` INT unsigned NOT NULL, `link_path` VARCHAR(255) NOT NULL DEFAULT '', PRIMARY KEY (mlid), INDEX mlid (mlid) ) /*!40100 DEFAULT CHARACTER SET utf8 */ in /home/hobbyblo/public_html/includes/database.inc on line 551.
Update #6000
Failed: CREATE TABLE {menu_token} ( `mlid` INT unsigned NOT NULL, `link_path` VARCHAR(255) NOT NULL DEFAULT '', PRIMARY KEY (mlid), INDEX mlid (mlid) ) /*!40100 DEFAULT CHARACTER SET utf8 */
Update #6001
Failed: Could not add records to databse

5. Ran update.php again

The following queries were executed
menu_token module
Update #6001
Failed: Could not add records to databse

6. Revert to previous version :(

dealancer’s picture

Hi Alex,

I appreciate your doings to improve this module.

It is a little weird that menu_token table was already exist. Probably table was there because of previous attempts to update module. Probably queries in update 6001 was not run because of error in update 6000. Could you try to delete menu_token table manually and try to do this again, please. The previous version of the module doesn't use tables so you could delete it without worry. BTW was menu_token table empty?

alexbk66-’s picture

Hi dealancer,

I installed 6.x-1.0-alpha1 (recommended) version, looks ok, but it doesn't create the new table. At least the status report doesn't complain anymore.

Did you mean 6.x-1.x-dev?

dealancer’s picture

6.x-1.0-alpha1 is really and older version which does not use tables at all. Yes, I mean 6.x-1.x-dev.

alexbk66-’s picture

Hi dealancer,

As only me seem to have this problem, I'll leave it as is for now. When I have time maybe I'll give it a try...

~~~~~~~~~~~~~~~~~

HobbyBlob.com

Showcase your Hobby to the whole world!

mjstone323’s picture

Hi dealancer -
I just tried your suggestion (deleting the menu_token table manually, then re-installing menu_token) and it did not work for me. My menus were still wiped out by the module.

alexbk66-’s picture

develcuy’s picture

@mjstone323, since the new version tries to migrate from a system variable to a table, perhaps there is some corruped data in such variable or the migration script is not working properly, may you provide us with a dump of the generated menu_token table?

dealancer’s picture

@develCuy,

Yep migrating script need to be fixed. And it seems it it really difficult to reproduce the error. In some cases I can do it but not really often.

dealancer’s picture

Guys, I could not reproduce error now. What have done:

a) installed drupal 6
b) downloaded and enable menu_token 6.x-1.0 alpha-1
c) configured menu items, used tokens
d) downloaded menu_token 6.x-1.x dev
e) run update.php

Result was:

The following queries were executed
menu_token module
Update #6000
CREATE TABLE {menu_token} ( `mlid` INT unsigned NOT NULL, `link_path` VARCHAR(255) NOT NULL DEFAULT '', PRIMARY KEY (mlid), INDEX mlid (mlid) ) /*!40100 DEFAULT CHARACTER SET utf8 */
Update #6001
No queries

"No queries" was because drupal_write_record does not return sql of executed queries.

dealancer’s picture

@mjstone323,

If you uninstall alpha-1 version module, obviously you will get wiped menus, because variables that are used for storing data will be removed.

Please try to do actions below to update menu_token from alpha-1 to new dev version of this module:

1) download dev version
2) run update.php (be sure that update #6000 is selected for the module)
3) see what happens

dealancer’s picture

Assigned: develcuy » dealancer

@DevelCuy

Initially error was in that we used there drupal_write_record function which made call to drupal_get_schema($table) , which have no any meny_token in the cache, that's why I decided to run: drupal_get_schema('menu_token', TRUE); with a TRUE parameter to clear cache.

However using of drupal_write_record and drupal_install_schema in hook_update_N is bad practice because it always deals with a new schema, but not the schema we need in this update. That is why we need to store schema both in hook_install (always actual) and hook_update_n (we need for update) and user db_create_table instead of drupal_install_schema, also we need to use sql_update instead of drupal_write_record. Also sql_update returns executed queries.

I am going to fix it.

dealancer’s picture

Status: Active » Fixed

@alexbk66, @mjstone323

I have completely rewrote update function, so please check it now. It should work, I hope.

Status: Fixed » Closed (fixed)

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