When drupalforfirebug module (drupalforfirebug 7.x-1.x-dev 2010-07-10) is enabled in the latest drupal core release (Drupal 7.0-beta1) it causes a fatal PHP error (and "white screen of death") on the permissions page (/admin/people/permissions).
This is because it provides the wrong type of array in the drupalforfirebug_permission() implimnetation of hook_permission()
Here's the function as it exists :
/**
* Implementation of hook_permission()
*/
function drupalforfirebug_permission() {
return array('Access Firebug Debug', 'Execute Firebug PHP');
}
Here is the corrected function:
/**
* Implementation of hook_permission()
*/
function drupalforfirebug_permission() {
return array(
'access firebug debug' => array('title'=>'Access Firebug Debug'),
'execute fierbug php' => array('title' => 'Execute Firebug PHP'),
);
}
A diff of these changes is included bellow. Forgive me if it is not in the right format. I'm still new to patching.
Comments
Comment #1
manimejia commentedComment #2
vikingew commentedI think the correct code should be something like this:
it still doesn't solve a WSOD problem with accessing Modules page after enabling this module. As is Modules are totally unaccessable but I'm not sure if it's the same issue though. I will role back my db and redo it and see if I can catch what went wrong.
Comment #3
vikingew commentedNot that I really want to sound negative, but... running this module through coder flags about 60 breakages of drupal coding standards, which in itself is a bad sign pointing to a high risk for sloppy coding may have lead to the current state where enabling the module results in a WSOD error.
One such thing that coder doesn't catch is in drupalforfirebug.install where
function drupalforfirebug_update_1() {should be
function drupalforfirebug_update_7000() {or possibly
function drupalforfirebug_update_7001() {but I think the first one (7000) is correct.
Again, appreciating the work going in to this important module, but it's still no excuse for and it's not hard to understand that coding standards are there for a reason, and shoudn't be neglected.
Comment #4
vikingew commentedHere is a more comprehensive patch that also fixes the WSOD problem, it appears to have been caused by weight set to 100000 and not -100000 as in the preprocessor module, or if it was the bug in preprocessor.info file which had .info assigned to files[] instead of .module, I don't know as I fixed both at the same time. I haven't bothered about the coding standard issues as I like to leave that to the maintainer ;-)
btw, the weight bug is in D6 version as well
Displayed here for a visual but attached further down as well, and don't bother about the revision number, it's because I import and keep all my stuff in subversion.
Comment #5
populist commentedThe permission issue was fixed in version 1.1 in this issue - http://drupal.org/node/1017202
Comment #6
populist commentedAnd the installation issues were fixed in the last commit (ac0c5f4..8a2bf68) and should be ready for action soon!