Admin Toggle allows site admins to toggle the display of admin items on a page with the press of a single key. This allows admins to easily preview what their site looks like to non-admins.

This is meant to be a much more robust version of Admin Menu Hider, allowing admins to toggle all admin items rather than just the toolbar. More features are in the works.

Click the screenshot for an animated preview of Admin Toggle.

Drupal version: 7.x
Project page: http://drupal.org/sandbox/jessepinho/1799242
Git:
git clone --recursive --branch 7.x-1.x http://git.drupal.org/sandbox/jessepinho/1799242.git admin_toggle
Review bonus:
http://drupal.org/node/1475404#comment-6898834

CommentFileSizeAuthor
#3 1799252.patch359 bytesjessepinho
Admin-Toggle-demo-trimmed.gif102.81 KBjessepinho
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

klausi’s picture

Welcome,

please get a review bonus first. Some leftovers from the automated review: http://ventral.org/pareview/httpgitdrupalorgsandboxjessepinho1799242git

superspring’s picture

Probably one of the best projects i've seen so far in terms of coding standards.

In the file admin_toggle.admin.inc:

Drupal Coding Standards:
- $w should be renamed $weight

In the file admin_toggle.module:

Drupal Coding Standards:
- Line 122 - (integer) should be followed by a space
- @return should specify the type, eg integer

Javascript:
- Line 56 - Drupal.settings should be passed in the initial call (after jQuery parameter) to ensure they are not corrupted later.

jessepinho’s picture

FileSize
359 bytes

Thanks for the feedback, guys!

I've committed all the changes you both listed (including the ones from ventral.org) and pushed up to the Drupal.org git repo—with one exception. superspring: I've never seen the Drupal or Drupal.settings variable passed into the main anonymous function in a .js file, so I wasn't sure how to do it. (I want to be able to access all of the Drupal variable, but passing it in will just create a reference to it, right? And what do you mean by corruption... like, if someone else's module code corrupts the settings?) I attached a patch that I created to see if this is what you had in mind.

Re: review bonus: I'll try to do this ASAP! I guess I was a little overwhelmed by everything a reviewer has to read before reviewing, haha.

Thanks again!

Jesse

superspring’s picture

Hey,

I've included an example below.
The main idea is to ensure that your code is completely independant of other pieces of code, so that other code cannot accidently break yours with namespace crossovers or similar.

-------------------------------------------

(function($, settings) {
// This code now has a copy of jQuery and Drupal.settings at the point it was initially run.
// All changes to either of these variables later will not affect the code inside this block.
})(jQuery, Drupal.settings);

// Now, if a new version of jQuery is added, the script still works with the version of jQuery that it was initially loaded with.

Drupal.settings.secret_hacker_variable = true; // oh nos!
// The code also contains it's own copy of Drupal.settings, so other scripts loaded afterwards are unable to modify it's internal reference.

jessepinho’s picture

Ah, gotcha. Just fixed it! I passed in Drupal.settings, and removed all references to Drupal.settings inside the main anonymous function. I also removed the "settings" variable from the :attach() function signature to avoid variable collision. I've pushed it up to the repo. Thanks!

larowlan’s picture

I think the toggle menu callback should have CSRF protection via drupal_get_token. Look at flag and masquerade for examples.

jessepinho’s picture

larowlan: I was actually wondering about this... but isn't it safe enough since it uses a POST request? I can understand the need for a token if it were making a GET request, but POST should provide adequate protection, no?

jessepinho’s picture

By the way, I just pushed up another commit that adds toggling of contextual links menus.

peterx’s picture

Product description: "non-admins"? Clarify, you mean Anonymous.

I went looking for a module to switch to a user with a specific role, your module looked good, and I had to look in the code to see what was meant by non-admin. I ended up using Masquerade. Adding the clarification to the description removes the need to read code.

jessepinho’s picture

Fixed; thanks!

cubeinspire’s picture

Status: Needs review » Needs work

Hi, nice module !

I've installed and I see the following bugs.

Major bugs:

1. It doesn't works as expected:

Here is the screenshot:
http://www.logicdesign.be/sites/default/files/Screenshot-17.png

1.1. There is a white space band on the top.
1.2. The admin links to create content didn't disapeared.
1.3. If we are an Anonymous user this should be there neither.

Minor bugs:

2. It would be nice if the default key choice is usable to international keyboards.
Some keyboards (as mine, from Belgium) need to press a combination of keystrokes to have the `symbol, and when I press that combination the module doesn't do anything.
It forces to pass to the module config to change the keystroke, what makes me think that the `is maybe not the best choice for the default key.

jessepinho’s picture

Status: Needs work » Needs review

logicdesign:

Thanks for the testing/feedback! You actually raise a question I've been wondering about: how much stuff should be toggled? The idea is that users should be able to see the page as a non-admin would see, which means hiding the admin toolbar, contextual links menus, etc.—but not the "my account" and other user links. I mean, I *could* hide the user navigation menu when toggling admin items; but if other links have been added to that menu that apply to all users, they would be hidden too. As for the "Add new content" link: some websites allow even anonymous users to add content (depending on the content type), so that was another thing I wasn't sure about whether I should remove.

I have some ideas for future iterations of this module that include stuff like super-granular settings for what should be toggled, where the user can set preferences for what they want to have toggled. So, the user could choose to hide all contextual links and admin toolbars, but not action links or user navigation menus (for example). I'm still playing with how this could be done exactly, but just wanted to get a first iteration of the module out there and see what there's demand for. Thoughts?

(I'm supposed to switched this back to "needs review" when I ask a question, right?)

Jesse

peterx’s picture

Some of your future development ideas start to overlap with other modules. You might want to consider using the other modules to help yours achieve some of your long term plans.

You might want to do is let people see things for a role or a test user. Roles are used to control blocks and things. You could switch the page to anonymous + role abc, or to a test user with role abc. If you implement that type of change, you might want to link to Masquerade to perform the user switch and switch back. I have reused the Masquerade user switch functions in one of my modules. People would then have a progression of flexibility and complexity from Admin Toggle up to Masquerade when they want to test updates.

Another approach might be similar to Echo. You request the page via a HTTP request then present the other page. You would probably have to open a new window to make it realistic. You could probably make Echo a dependency and use some of their functions. This could give you more flexibility.

cubeinspire’s picture

The question that was pointed out by peterx on comment https://drupal.org/node/1799252#comment-6560378
is very important...

what do you mean by non-Admins

When I made the review I understood you meant Anonymous user.
If not, then there should be a form that performs a keymapping, one key for each role.
In that way you would have a unic interesting functionnality that Masquerade doesn't have.

About the add new content link, in a fresh install this link doesn't appear to the Anonymous users.
The toggle functionnality should parse all menu items and hide them if they are not visible by anonymous (that's what I was expecting). If this is not the functionnality you wanted to create, I think the module description should be more explicit.

From my point of view the must have of this module is the Roles - key mapping setup on the config page,and very important that the result is exactly seen as an user of that Role.

This fast switch would speed up production, and in that situation I would be very interested on using this module on my custom dev profiles !

Keep it up !

jessepinho’s picture

Just an update: Added toggling of the node-unpublished class, so that you can preview nodes as they would look when published.

jessepinho’s picture

peterx: I've been thinking a lot about your comparison with to Masquerade. I looked up Masquerade, and I wondered if perhaps Admin Toggle should simply function as a shortcut key add-on to Masquerade...? i.e., you could program shortcut keys for different roles: tilde would be Anonymous, 1 would be authenticated, and so forth. I'm a little concerned about it feeling a little less seamless than it currently does since the current approach doesn't actually reload the page, but that may be an OK trade-off. It could be called Role Toggle, for example. And you could toggle to any role from any other role. This also addresses logicdesign's concern with wanting to have role-based key mapping. Do you guys think this sounds like a good direction to take this module?

The main concern I have with this is the fact that, unless I'm missing something, I believe this would require creating a dummy user that could be switched to. So, if switching from admin to anonymous roles (for example), the dummy user (which would be created via admin_toggle.install) would be assigned the Anonymous role, and then would be switched to. Then, switching from Anonymous to, say, "Moderator," the dummy user would be assigned the Moderator role. Does this sound like the correct approach? I'll look into Masquerade a bit more and see how they tackled this problem.

jessepinho’s picture

EDIT: oops, damn duplicate posts.

jessepinho’s picture

One other concern: actually switching roles means that certain things you can see as an admin—unpublished nodes, for instance—would no longer be visible. It would make it impossible to preview what an as-yet-unpublished node would look like to another user. This may not be a problem, though; just something to keep in mind.

peterx’s picture

switching roles

Admin can see everything, making it hard to see what someone sees with less access. Switching roles is the next step after switching classes but not everyone will need the extra step. Get your module working and published first then, perhaps, add other things.

On one of my sites we have role specific blocks. Role A can see block A and role B can see block B. Admin could see both but they occupy the same space and B does not appear if A is visible. To test B, we need a user with role B and no other roles, not admin or anything. I could use Masquerade to log in as a test user for B or I can keep the admin user in Firefox and open another browser, say Chromium, for user B.

There are a few approaches people can use. Instead of making release one of your module do everything, get it working and published with what it does now. Add other features when someone steps forward with a specific use case and is willing to test it.

wimcms’s picture

Hi! I download this module with git and install but is empty.

jessepinho’s picture

Just an update: been overwhelmed with other work and haven't had much time to spend on this. Have some really cool ideas about how to make the minimum viable product for this. Will report back soon.

wimcms: Did you switch to the 7.x-1.x branch? (The master branch is intentionally empty.)

peterx’s picture

Change the default selection: Edit -> Default branch. Then people will get your current branch.

jessepinho’s picture

Didn't know I could do that! Thanks! Fixed.

DanZ’s picture

Status: Needs review » Reviewed & tested by the community

This works great! I'm going to use this.

Well-written code, with useful comments.

You have a master branch with skeleton .info and .module files. Officially, you can keep around the Master branch with just a README.txt file. Personally, I prefer removing the Master branch entirely. See http://drupal.org/node/1127732.

There is no apparent online help. It could really use a little, especially for adding more elements to hide.

Set the '#size' => 1 for shortcut key field.

The '#weight' => $weight++; lines in admin_toggle_admin_form() are not required. By default, the form elements are placed on the page in the order they are added to the $form array.

Why get the default toggle state from the session? Why not just pull it straight from the Drupal variable? Maybe that's the right thing to do, but an explanation would be nice. Now, if you mean the current toggle state, not the default toggle state, maybe you should call it admin_toggle_current_state() instead of admin_toggle_default(). Actually 'toggle' can be a verb, so admin_toggle_default is confusing to start with.

This is all nitpicking, and nobody else here has any serious complaints. So, I'm going to go out on a limb (for a first-day code reviewer) and call this RTBC. Good luck!

jessepinho’s picture

Thanks DanZ! I've committed the #size and #weight changes.

As for the default toggle state: I imagine different admins might have different preferences. So, I want each admin to be able to toggle their own view independently of each other. In a later version, I may want to (optionally) integrate with the user_variable module, for more persistent preferences. (Right now, your preference is lost as soon as you log out.)

Thanks again! Excited to get this approved!

DanZ’s picture

It still has to be promoted, and that might take a while. You can participate in the review bonus program to get it looked at sooner.

DanZ’s picture

Issue summary: View changes

Added tag to git repo.

jessepinho’s picture

FYI: Added one review bonus. Hope to add more soon.

DanZ’s picture

Older posts get get looked at first (in theory), so don't reply unless you have all three reviews.

Also, look at the rules for changing the priority as the request ages.

jthorson’s picture

Hmmm ... I'll promote this, but with a few reservations.

In an overlay screen, the admin toggle only toggles items on the overlay page. This could result in the admin not seeing local task items in the administration interface, which could in turn lead to confusion in administering a site. Given that the admin menu is still visible, one may assume that the admin toggle is not enabled; when in fact it is. IMO, it should not disable any items within an admin-only overlay page when the whole page is not actually accessible to anonymous users. Perhaps checking the overall page permissions before enforcing a toggle would get around this.

After closing the overlay page (using the 'x'), the admin toggle appears to stop working until the window loses focus and gains it again, or you navigate to a new page.

In a standard out-of-the-box build, using the toggle does not actually display what an anonymous user would see ... the admin menu is hidden, but it leaves behind a 65px white strip of empty white 'padding' at the top of the page where the admin menu was.

In order to provide per-user preferences, I'd steer away from using the SESSION variable; and instead store the preferences in each $user object, as described in http://www.braahm.be/node/7

jthorson’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for your contribution, jessepinho!

I updated your account to let you promote this to a full project and also create new projects as either a sandbox or a "full" project.

Here are some recommended readings to help with excellent maintainership:

You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and get involved!

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

Thanks to the dedicated reviewer(s) as well.

alexverb’s picture

I just wanted to mention I just applied for full project with my environmental administration menu. It puts the masquerade form into the admin menu and allows for previewing as any user while still printing the environmental administration menu so you can easily switch back.

I think masquerade is the way to go and this module is doing a lot of work trying to get the same result. Just my 2 cents...

jessepinho’s picture

Thanks jthorson! I've promoted the project and will address the issues you raised as soon as I am able.

jthorson’s picture

Another potential concern to mention ... Drupal 7 will, by default, disable page caching for anonymous users if as session is present ... so by using $_SESSION, you lose caching, which in turn can significantly cripple a busy site.

This probably isn't a huge issue for a 'development' module such as this one, but I wanted to make sure you were aware of the implication.

Status: Fixed » Closed (fixed)

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

Anonymous’s picture

Issue summary: View changes

Added review bonus.

apaderno’s picture

Title: Admin Toggle » [D7] Admin Toggle
Issue summary: View changes