Create a 6.x-1.1 release
SiliconMind - April 16, 2008 - 14:53
| Project: | Flexifilter |
| Version: | 6.x-1.1-rc1 |
| Component: | Code - Misc |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
due to drupal 6.2 API changes drupal will throw 'access denied' (403) when user tries to edit or create filters. this also applies for UID1 !!!
To fix this flexifilter_menu() function needs to be updated to include 'access arguments' => array('administer flexifilter') for every menu array item returned. implementation of hook_perm is also needed:
<?php
function flexifilter_perm() {
return array('administer flexifilter');
}
?>
#1
this should have been fixed in the dev version. Are you sure you are using the latest dev version and that you ran update.php?
#2
will be fixed once http://drupal.org/node/235039#comment-810199 is done.
#3
I'm using 6.2 and the latest dev version, ran update.php; and still get the access denied message. Is there something else I should do? I'm not sure where to implement the above mentioned code. Thanks
#4
just edit flexifilter.module file and replace flexifilter_menu() function with this code:
<?php/**
* Implementation of hook_menu()
*/
function flexifilter_menu() {
$items = array();
$items['admin/build/flexifilters'] = array(
'title' => t('Flexifilters'),
'description' => t('Create new flexible input filters without writing any code.'),
'page callback' => 'drupal_get_form',
'access arguments' => array('administer flexifilter'),
'page arguments' => array('flexifilter_filter_list_form'),
'file' => 'flexifilter.admin.inc',
);
$items['admin/build/flexifilters/list'] = array(
'title' => t('List'),
'access arguments' => array('administer flexifilter'),
'type' => MENU_DEFAULT_LOCAL_TASK,
);
$items['admin/build/flexifilters/add'] = array(
'title' => t('Add new flexifilter'),
'page callback' => 'drupal_get_form',
'access arguments' => array('administer flexifilter'),
'page arguments' => array('flexifilter_filter_edit_form'),
'type' => MENU_LOCAL_TASK,
'weight' => 1,
'file' => 'flexifilter.admin.inc',
);
$items['admin/build/flexifilters/import'] = array(
'title' => t('Import a flexifilter'),
'page callback' => 'drupal_get_form',
'access arguments' => array('administer flexifilter'),
'page arguments' => array('flexifilter_filter_input_form'),
'type' => MENU_LOCAL_TASK,
'weight' => 2,
'file' => 'flexifilter.admin.inc',
);
$items['admin/build/flexifilters/defaults'] = array(
'title' => t('Load a default flexifilter'),
'page callback' => 'drupal_get_form',
'access arguments' => array('administer flexifilter'),
'page arguments' => array('flexifilter_filter_default_form'),
'type' => MENU_LOCAL_TASK,
'weight' => 3,
'file' => 'flexifilter.admin.inc',
);
$items['admin/build/flexifilters/%flexifilter'] = array(
'title callback' => 'flexifilter_get_field',
'title arguments' => array(3, 'label'),
'type' => MENU_CALLBACK,
'page callback' => 'drupal_get_form',
'access arguments' => array('administer flexifilter'),
'page arguments' => array('flexifilter_filter_edit_form', 3),
'file' => 'flexifilter.admin.inc',
);
$items['admin/build/flexifilters/%flexifilter/edit'] = array(
'access arguments' => array('administer flexifilter'),
'type' => MENU_DEFAULT_LOCAL_TASK,
'title' => t('Edit'),
);
$items['admin/build/flexifilters/%flexifilter/export'] = array(
'title' => t('Export'),
'type' => MENU_LOCAL_TASK,
'page callback' => 'drupal_get_form',
'access arguments' => array('administer flexifilter'),
'page arguments' => array('flexifilter_filter_export_form', 3),
'file' => 'flexifilter.admin.inc',
);
$items['admin/build/flexifilters/%flexifilter/preview'] = array(
'title' => t('Preview'),
'type' => MENU_LOCAL_TASK,
'page callback' => 'drupal_get_form',
'access arguments' => array('administer flexifilter'),
'page arguments' => array('flexifilter_filter_preview_form', 3),
'file' => 'flexifilter.admin.inc',
);
$items['admin/build/flexifilters/%flexifilter/delete'] = array(
'title' => t('Delete'),
'type' => MENU_CALLBACK,
'page callback' => 'drupal_get_form',
'access arguments' => array('administer flexifilter'),
'page arguments' => array('flexifilter_filter_delete_form', 3),
'file' => 'flexifilter.admin.inc',
);
$items['admin/build/flexifilters/%flexifilter/enable'] = array(
'title' => t('Enable'),
'type' => MENU_CALLBACK,
'page callback' => 'drupal_get_form',
'access arguments' => array('administer flexifilter'),
'page arguments' => array('flexifilter_filter_enable_form', 3),
'file' => 'flexifilter.admin.inc',
);
$items['admin/build/flexifilters/%flexifilter/disable'] = array(
'title' => t('Disable'),
'type' => MENU_CALLBACK,
'page callback' => 'drupal_get_form',
'access arguments' => array('administer flexifilter'),
'page arguments' => array('flexifilter_filter_disable_form', 3),
'file' => 'flexifilter.admin.inc',
);
return $items;
}
?>
don't forget to add this:
<?php/**
* Implementation of hook_perm().
*/
function flexifilter_perm() {
return array('administer flexifilter');
}
?>
#5
scor, i am sure :)
just checked filedates.
flexifilter.info is dated April 15th so i'm pretty sure it's one of the latest. but flexifilter.module - the one that implements hook_menu() is dated way back to Feb 29th :/
#6
Yes all this stuff is already fixed in HEAD, I'm experiencing CVS difficulties, grr...
#7
The above code worked for me, thanks.
#8
I have fixed several CVS issues, the code already in HEAD should now be available in the dev release.
#9
Automatically closed -- issue fixed for two weeks with no activity.
#10
Still not in the release version.
Mentioned patch seems functional, but new error message appears if I edit a filter, and click on preview:
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'flexifilter_filter_preview_form' was given in /home/czigola/public_html/online/includes/form.inc on line 358.
#11
..yeah. When it's stable enough.
#12
Can I recommend creating a flexifilter 6.x-1.1-rc1 or even a flexifilter 6.x-1.1-alpha1? And setting it so that it appears on the front page?
#13
Is the dev version as unstable as warned? I'm looking forward to a fix of this issue.
#14
subscribing
#15
Please note, that the current rc1 version is from January '08, and still throws the error mentioned. Should perhaps the 1.1-dev version be listed in the front page, as a '1.1-rc2'? The currently listed rc1 - which is 'recommended' for D6 - is actually unusable with the latest D6.4, because of this error...
Many thanks in advance! :-)
#16
+1
#17
+1
#18
+1
#19
Code of post #4 (http://drupal.org/node/247416#comment-811270) works. It is necessary that the current rc version gets this update. Marked as critical because the current version isn't usable without modification.
#20
#21
This weekend. I promise. Now stop messing with the issue queue, please.
#22
I am not messing the issue queue; I simply changed the issue title to something more significant.
Create a 6.x-1.1 release could be a title for a feature request, not a bug report; as the issue described here is exactly the access denied problem caused by an incomplete implementation of
hook_menu(), I titled the issue Access denied for UID 1.Giving to the issue report a wrong name will cause other people to report the access denied issue again, and again simply because they will not see any issue which reports about that.
#23
But its category is set as "bug report". That seems pretty self-explanatory to me.
This is actually not the wrong title, believe it or not. There were multiple issues with the present release, that eithere were already fixed or still need to be fixed in the dev version and an updated release needs to be published for them, too. Renaming this issue to the specific bug you encountered does not help me in my organization here; the more organized I am, the faster bugs get fixed, the faster the new release gets out there. I promised a release for this weekend, and I intend to live up to my word. But please, leave the issue title reflective of the actual issue here. The issue is not that I have to solve the access denied for uid 1 stuff; it's that I need to reverse several bad cvs commits to the wrong branch and re-commit them to the right branch and tag everything properly.
#24
An issue title is not thought to be used by the maintainer to organize better the work to do on a project.
The title helps who wants to report an issue he found with a module, without to write an issue report for an already reported issue; or it can be used by who can be interested in the use of the module, and wants to check first if there are any problems using the module.
The title doesn't reflect the actual issue which is the access denied problem that happens with the last releases of Drupal 6.
It seems that the intent is to hide that there is such a problem with the module; there was another issue titled Access denied for UID 1 but first it has been reported like fixed (which is not true), and then reported like duplicated.
#25
+1 for Kiam, it makes a lot of sense, since a new release should be issued as a "task" which is different for the issue to be followed (whether it's fixed or not)
#26
I think that the next release could rather difficulty be called 6.x-1.1.
It would be better to fix the problem introduced with Drupal 6.2, and release a 6.x-1.1-rc2; only after that, a version 6.x-1.1 can be planned.
#27
Is there an estimated date planned for this next bug-fix release? I can't find any recent commits in the CVS repository.
#28
Committing a few other patches and then releasing a new release candidate (not at 6.x-1.1 yet, sorry).
#29
Automatically closed -- issue fixed for two weeks with no activity.