Add examples for access callback and access arguments to the menu examples

I think that's reasonable.

menu_example/permissioned/controlled has a comment explaining how it works, but probably an explicit example would improve it.

In other words, I think that adding an example in menu_example that shows the callback being user_access (which is the default), and another one with the callback being menu_example_funky_access(), which has specific logic. We could do more with the arguments in the same way.

A custom "access callback" function has been defined which takes permission defined by hook_permissions() as arguments.

Thanks for the good work on this!

+++ b/menu_example/menu_example.moduleundefined
@@ -118,7 +118,36 @@ function menu_example_menu() {
+   * This function takes takes permissions as arguments and checks if the user has the permissions required
+   * to view the page. ¶

Actually, it doesn't necessarily take permissions as an argument. It could take anything as an argument. It just happens that user_access() takes permissions as args.

+++ b/menu_example/menu_example.moduleundefined
@@ -118,7 +118,36 @@ function menu_example_menu() {
+   * This is just an example the permissions are set accoeding to our need and convinience.

Typos "convenience" and "according"

I note that somehow the menus in this example never got set correctly. They're supposed to be examples/menu_example/*. Would you mind fixing that (for all of hook_menu) in this patch? Normally I wouldn't want to do that, but since you're explicitly mentioning menu items, it is something that might not get caught later.

@rfay I coudnt understand why the patch failed testing,it's working perfectly on my host, could you help me please !

@bobbyaldol, does it test successfully locally?

My bet is that the test for menu_example uses the old menu path to access the items it's testing (menu_example instead of examples/menu_example). Not sure why the details aren't available on http://qa.drupal.org/pifr/test/276998

You might consider updating the test to take into account your new example as well.

Congratulations!

Since we're doing a custom access example, I'd like to have it show more than the regular does. The access callback does *not* normally depend on Drupal permissions, but rather on some other factor.

You might something arbitrary like this:

/*
 * Access callback that checks multiple permissions.
 *
 * Takes a list of UIDs that are to be denied, demonstrating how various conditions other than permissions
 * can be used to allow or deny access. Here we deny access to listed user uids.
 *
 */

function menu_example_custom_access(){
  $arguments = func_get_args();
  global $user;

  foreach($arguments as $uid){
    if($uid == $user->uid){
      return FALSE;
    }
  }
  return TRUE;
}

@rfay: it was on my mind , while writing the patch, but unfortunately they failed previously, and I removed them for my convenience and never put it back I think this fixes it....

For menu_example_custom_access(), please use and document named parameters. Really we should only use func_get_argument() in unusual and difficult cases.

Please don't use permissions at all for menu_example_custom_access(), because you're trying to show *non* permission-based access. Don't forget to update the docs there.

But this is looking great! Thanks for all the great work. It's much appreciated.

@rfay: you wanted me to get rid of the permissions, then we have to entirely depend on uid for access.

I rather think it would be great if we have an amalgamation of uid and permissions(like the patch submitted), this would give the user a much better understanding(just my opinion).

Please give it a second thought , and you still think it is not worth then I would change it as required.

@bobbyaldol, a great way to do this would be to provide access by *role*. That does what you seem to want to do, but doesn't confuse everybody with the similarity to user_access(). So if you create an access callback that only allows access for 'authenticated user', and use the role name as the argument, it should be good enough.

@rfay: awesome idea, seriously even after thinking about it for a million times, I am sure I wouldnt get an idea of that sort. THANKS.

Committed with minor changes. Thanks!

@bobbyaldol, as you see in http://drupalcode.org/project/examples.git/commitdiff/70f4bc2, I added a better function block (it should usually have parameters) and made the function simpler with in_array().

Nice work!