Closed (fixed)
Project:
Block Class
Version:
6.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
22 Sep 2011 at 15:20 UTC
Updated:
8 Mar 2012 at 20:10 UTC
Jump to comment: Most recent file
Comments
Comment #1
berenddeboer commentedThanks, I've disabled the dev snapshot for now until I've time to work on it.
Comment #2
lonehorseend commentedI'm still running into the problem and it's because of this:
user warning: Specified key was too long; max key length is 1000 bytes query: CREATE TABLE block_class ( `module` VARCHAR(255) NOT NULL, `delta` VARCHAR(255) NOT NULL, `css_class` VARCHAR(255) NOT NULL, PRIMARY KEY (module, delta) ) /*!40100 DEFAULT CHARACTER SET utf8 */ in includes/database.inc on line 550.
If you do a Google search on the error, you'll find it's a known issue with MySQL. However, there are other modules that are reporting the same problem and their install schema had to be fixed in order to make it work.
To get around it, I went into PHPMyAdmin and manually created the table via the query that was created. However, I do not recommend this unless you are comfortable with PhPMyAdmin and the Drupal DB.
Comment #3
berenddeboer commentedComment #4
sunCurrent code of block_class in the repository has been completely hi-jacked.
Attached patch fixes the schema of block_class in 6.x-1.x, which is the scope of this issue. There seems to be a new 6.x-2.x branch, but that's not the point here.
#1020846: 7.x-1.x fails to install database schema ("Specified key was too long") needs to account for this fix afterwards.
Comment #5
clemens.tolboomThis should be 64 in length
This should be 32 in length
This should be length instead of size.
Comment #6
clemens.tolboomI ran into this problem using drush make which fetched the 6.x-1.4-beta1 which is really not a decent beta :(
Could you remove this 6.x-1.4-beta1 version?
Comment #7
sunre #5: No, existing module updates must not be changed.
Comment #8
clemens.tolboom@sun Yes and no.
You are right not to change an existing hook_update_N. Sorry about that.
But the patch then need a new hook_update_N to make sure the index are not exceeding 255 chars.
See http://drupalcode.org/project/block_class.git/commitdiff/965e79bf487f274...
This commit contains parts of patch #4 :(
So the patch still needs work against the latest dev version. http://drupalcode.org/project/block_class.git/blob/refs/heads/6.x-1.x:/b...
Darn.
Comment #9
sunSorry, but it doesn't seem like you properly looked at this patch.
The patch already contains a new update to fix the mess.
I've tested both the update from the current version as well as the installation from scratch.
Comment #10
clemens.tolboomOk ... I'm now testing the upgrade / update process.
Updating from 6.x-1.3 to 6.x-1.x
Running update.php fails on
block_class_update_6100()With readable output
This is due to
Size is not a valid field attribute
Fails due to key too long.
Comment #11
clemens.tolboomDoing the same from #10 for the update
From 6.x-1.3 to 6.x-1.x + patch from #4
With readable text
So patch #4 needs work as the primary key didn't made it.
(patch is underway)
Comment #12
clemens.tolboomI moved the update_6101 update to update_6102
Next inserted a fix for update_6100 into update_6101.
Removed the failing field update and index key update_6100
The update now only fails on dropping the primary key.
Comment #13
sunok, that complicates things a bit.
6.x-1.3 didn't contain any updates at all, and a very bogus schema on top: http://drupalcode.org/project/block_class.git/blob/a58723ec455a8fa7a84f2...
Latest 6.x-1.x, however, already contains update 6100, and I can only guess that many updated to that snapshot as the latest stable is quite old and buggy.
This means we need to support two update path branches. Not a big issue, Drupal core had to deal with more complex scenarios already.
Attached patch empties out 6100 (which possibly ran for users on 6.x-1.x already) and adds a new update 6101 (which will run for all users).
I hope you don't mind a format-patch. Only the second commit is new.
Comment #14
clemens.tolboomShould be something like 'updates from 6.x-1.3' not 'new installations'
Ehrm ...
is abracadabra to me. But nm. We now agree on update_6100 was wrong.
If you want people to review the patch against 6.x-1.x a 'normal' patch would be better I guess.
Comment #15
sunSorry, ok, regular patch attached, including suggested comment tweak.
Comment #16
clemens.tolboomPatch from #15 looks ok.
Attached a patch against 6.x-1.3 as 6.x-1.4-beta1 is bad and drush_make grabs 6.x-1.4-beta1 for some reasons.Edit: The 6.x-1.3 patch is not applicable to 6.x-1.3.tar.gz download as that was before the git migration.
Comment #17
clemens.tolboomNew patch applicable with drush make
(Lesson learned ... patching against non git version the $Id$ is expanded and this part was used as a patch context)
Comment #18
sunTo clarify once more: #15 is the patch to commit to 6.x-1.x.
Comment #19
sunAny updates? This is a critical bug.
Comment #20
clemens.tolboomI'm afraid that @berenddeboer said in #1 this will take some time :(
According to http://drupal.org/project/usage/block_class people are (fortunately) stuck to 6.x-1.3 version. (Only drush make users feel the pain :p)
Comment #21
todd nienkerk commented@sun: I will grant you commit access. Feel free to commit any changes you like. I could certainly use a co-maintainer.
Comment #22
berenddeboer commentedPatch #15 applied in git.