Comments

greggles’s picture

Sure, we could make it a dropdown as to how the message works instead of the checkbox that is there now.

zhangtaihao’s picture

I am strongly in support of this feature.

@greggles: Is there any update on this? If not, would you like me to have a go?

claar’s picture

Assigned: claar » Unassigned

Feel free to submit a patch, zhangtaihao. There's similar behavior in my old Admin Only Mode module (hosted at github at the moment) that you may be able to get implementation ideas from.

greggles’s picture

Assigned: Unassigned » claar

I would love to have help with the module. Please post a patch and I will review it.

zhangtaihao’s picture

Status: Active » Needs review
StatusFileSize
new3.09 KB

I've created a fork for a branch 914238 in my sandbox: http://drupal.org/sandbox/zhangtaihao/1180764.

Here's the patch. I've lifted most of the code from block.module since I thought it'd make sense to make the paths configurable. The principle is that you could restrict the message to login screens by selecting "Show on only the listed pages" and putting the paths:

user
user/login

From the cache perspective, you would inevitably have to either (1) set the same excluded paths or (2) not cache when there are messages. This should get around pages with stale messages. Alternatively, you could always flush the cache after you've changed the path settings.

zhangtaihao’s picture

Oops, I've completely neglected the Drush file.

@claar: I'll work on the Drush end of it if you agree the previous patch is the way to go.

claar’s picture

It's a neat implementation, but I'm having trouble understanding why we want this level of per-page configurability.

When "restrict logins" is set, this module:

  1. Logs out users not having the "login during restricted logins" permission, and
  2. Allows other users to login/remain logged in.

I see three obvious maintenance message locations one might want, in order of likeliness:

  1. Show message for still-authenticated users only, not for anonymous users (e.g., those just logged out)
  2. Show only on login screen
  3. Show everywhere for everyone

I propose that in all cases, the message should be shown when logging someone out and the login screen -- that's just a courtesy.

It seems to me like it's more interesting *who* sees the message, than *where* the message is shown.

Do your needs align with the above, zhangtaihao, or am I off base here?

zhangtaihao’s picture

I agree, though my implementation was literally as a minimal extension to the existing code.

This brings me onto some of the finer points I was considering earlier when I was working on it. Should the maintenance message only be shown to non-"login during restricted logins" users? Should the option to show these users the message be configurable (i.e. to choose to not show them the message)? This probably relates to #1180808: Add option for configuring lock-out message. Perhaps we could incorporate that issue into here and work on the maintenance/lockout message mechanism as a whole.

I believe it makes logical sense to use the "login during restricted logins" permission to classify users.

Here's an idea for the configurability:

  • Restrict logins (yes/no)
  • Lockout message (from #1180808: Add option for configuring lock-out message)
  • Authorized users (users with "login during restricted logins")
    • Maintenance message
    • Show maintenance message on specific pages (with the pages textarea)
  • Other users
    • Use authorized maintenance message (yes/no)
    • Maintenance message (disabled if the previous checkbox is checked)
    • Show maintenance message on specific pages (with the pages textarea)

The exact wording can be tweaked, but the principles remain. I think these options should leave the module adequately open for configuration.

zhangtaihao’s picture

Oh, and as with the existing module, the lockout message is technically independent of the maintenance message.

EDIT: actually, now that I think about it:

  • Restrict logins (yes/no)
  • Lockout message (from #1180808: Add option for configuring lock-out message)
  • Authorized users (users with "login during restricted logins")
    • Use lockout message (yes/no)
    • Custom maintenance message (disabled if the previous checkbox is checked)
    • Show maintenance message on specific pages (with the pages textarea)
  • Other users
    • Use lockout message (yes/no)
    • Custom maintenance message (disabled if the previous checkbox is checked)
    • Show maintenance message on specific pages (with the pages textarea)

Note that "Use lockout message" actually refers to using the lockout message as the maintenance message. Again, the wording will be fixed later.

This should leave an elegant default behavior with a high degree of flexibility.

claar’s picture

Would it work to just show the maintenance message right after the "Sorry, you do not have the permission to login at this time." message?

I suggest the config page could simply be:

  • [x] Restrict Logins
  • Maintenance Message (leave empty for none)
  • [x] Show Maintenance Message to users without "login during restricted logins" privilege

We would always show the non-empty maintenance message when logging someone out and on the user login page (This would satisfy all three cases from comment #7 above).

zhangtaihao, I guess I want to hear what you're trying to accomplish with this module. Features for the sake of features don't make sense to me (complicates both configuration and code), but if you're trying to do something specific that others will want to do too, then we should add such configurability. Do you have a set of sites where something like the above simple configuration would be insufficient?

zhangtaihao’s picture

Okay, sorry for complicating this whole issue. My requirement is:

  1. Showing the message at specific locations
  2. Showing the message only to unauthorized users
  3. Customizing the lockout message

On the various sites I manage, the maintenance message needs to be set in different places on a case-by-case basis. Now, assuming the functionality needs to match the above requirements:

  • [x] Restrict logins
  • Lockout message
  • ---------------------------
  • Maintenance message
  • [x] Show message for anonymous
  • [ ] Show message for users with "login during restricted logins" permission
  • Show maintenance message on specific pages

This would be complete to me. I'd rather have separate option to disable the maintenance message rather than empty it so that I have to retype it every time.

EDIT:
Oh, and some of my sites with many admins who should be able to login during maintenance I actually need the maintenance message to show for both anonymous and authorized users.

EDIT2:
Sorry, I've completely forgotten to include the paths widgets.

claar’s picture

Alright, if we change #11's "Show message for anonymous" to 'Show message for users without "login during restricted logins" permission' then +1 from me, assuming that the "Show maintenance message on specific pages" either defaults to /user or /user is included regardless of this setting.

Thanks for working through this, zhangtaihao, and especially for the patches!

zhangtaihao’s picture

Status: Needs review » Needs work

I'll be on it once I'm freed up tomorrow.

zhangtaihao’s picture

Title: Add option to show message only on auto-logout and login form » Configure maintenance and lockout message and visibility

I also think I might update the title of this issue to reflect the new stuff to be included, among which is #1180808: Add option for configuring lock-out message.

zhangtaihao’s picture

Status: Needs work » Needs review
StatusFileSize
new7.57 KB

Here's the subsequent patch from the last one. I've also pushed again to my branch.

claar’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev
Assigned: claar » Unassigned

Your code looks very good, zhangtaihao -- many good general code improvements in there.

I want to test it, but your patch doesn't apply to 6.x-2.x-dev, and your git repository is broken (can't be cloned or the tree viewed online). Can you re-roll against 6.2-2.x-dev?

Also, the new maintenance_helper.install file should use UNIX line-endings (\n) instead of DOS ones (\r\n).

Lastly, let's add Drush support for these new features as part of this same patch. I can work on that if you don't want to.

zhangtaihao’s picture

Assigned: Unassigned » zhangtaihao
Status: Needs review » Needs work

I'm on it. Sorry about the line endings. The Eclipse line ending settings can be a little confusing.

zhangtaihao’s picture

Status: Needs work » Needs review
StatusFileSize
new28.77 KB

Turned out the Notepad++ update reverted all my settings. I've fixed up the newlines.

Here it is, all my commits up until now into one combined patch. Took me a while to write up the help text for Drush. Feel free to fix up the text or let me know so I can fix it up.

claar’s picture

Amazing work, zhangtaihao.

I don't have time for a full review at the moment, but I want to write these few things down while I see them.

  1. At admin/settings/maintenance_helper I'm getting
    warning: Invalid argument supplied for foreach() in /inet/www/drupal-dev/htdocs/includes/form.inc on line 1212.
  2. @@ -73,12 +84,31 @@ function maintenance_helper_admin_settings() {
    +  /*
    

    Code should be removed rather than commented out.

  3. +    $pages = variable_get('maintenance_helper_message_pages', '');
    

    This default value should match the value set in maintenance_helper_install() (occurs several places in the patch)

  4. +php = "4.0.6"
    \ No newline at end of file
    

    Needs newline.

claar’s picture

Status: Needs review » Needs work
zhangtaihao’s picture

I've fixed 2-4. Regarding 1, my only guess is variable default values. Seeing the module is still in -dev, I'm reluctant to add an update hook to re-initialize variables. The workaround would be "Reinstall modules" in Devel to actually run maintenance_helper_install(). What's line 1212 in form.inc in your dev site?

Also, the patch I've attached contains all changes since 6.x-2.x-dev as one commit.

claar’s picture

You were right, uninstall/reinstall fixed this by setting the default values (which is what the foreach at line 1212 was looping through). I'm fine with not creating an update, but we aught to document in the README and/or CHANGELOG to uninstall/reinstall (or perhaps just save the settings page once?) to remove the error message if upgrading.

More review:

  1. $ drush mh-restrict-logins 1
    --show-message-on can only be set to 0 or 1.
    

    show-message-on should be optional (also, --show-message-everywhere should work without other options set -- it currently gives this same error)

  2. $ drush mh-restrict-logins 1 --show-message-on=1
    --show-message-to can only be set to 0, 1, or 2.
    

    show-message-to should be optional

  3. drush @engg-dev mh-restrict-logins 1 --show-message-on=1 --show-message-to=2
    Show message to users with the 'login during restricted logins' permission.
    Show message on every page except: .
    restricted logins enabled.
    

    A few things here

    1. --show-message-pages should be optional. Settings --show-message-on without setting --show-message-pages should result in the message showing on previously-configured pages. Without this, you lose your carefully crafted standard set of pages setup on the module setttings page.
    2. The drush help says --show-message-on=0 means "all pages except", and =1 means "only these pages", but the current actual behavior is the reverse.
    3. "restricted logins enabled." -- Restricted should be capitalized.
    4. Should we add a --show-message-nowhere flag to match the --show-message-everywhere one? I wanted to try having the maintenance message show up nowhere, and it took me a while to figure out how (answer: set --show-message-on to "only" and set --show-message-pages to "").
  4. Comment above "maintenance_helper_set_message_users()" says:
    + * Sets the maintenance message -- used by drush
  5. Ensure when using "variable_get()" that the default values match those set in maintenance_helper_install() -- I think this is all of them:

    In maintenance_helper_init():
        $visibility = variable_get('maintenance_helper_message_show', 0);
      $restrict_logins = variable_get('maintenance_helper_restrict_logins',FALSE);
    In maintenance_helper_admin_settings()
        '#default_value' => variable_get('maintenance_helper_message_users', 1),
        '#default_value' => variable_get('maintenance_helper_message_show', 0),
    

Thanks for the fast and great work, zhangtaihao!

claar’s picture

Oh yeah, I forgot to mention this non-standard encoding in the patch of maintenance_helper.install:

+<?php
zhangtaihao’s picture

I sort of assumed that all the Drush parameters were optional. In any case, they're designed to be optional. I'll get to fixing the help text. I'll also work on the rest of them as I move along.

Regarding the upgrade instructions, I'm not too sure whether it is a good idea to add it in README. For one, it's hard to reference "an older version". Second, I doubt many people who use the module will look into it unless something is wrong, they couldn't figure it out, and they couldn't find anything on the Web. CHANGELOG.txt should naturally be updated, but not quite with instructions to reinstall. Rather, I think it'd be more useful to put those instructions on the project page once the code is committed.

Alternatively, we could always implement the update hook to renew variable values.

What do you think?

claar’s picture

A note on the project page sounds fine to me! Yes, all of the parameters should be optional.

zhangtaihao’s picture

Status: Needs work » Needs review
StatusFileSize
new17.13 KB

Sorry it took a while. Other work priorities got in the way but now I'm free.

I think I've caught all the issues you noted. I also specifically went and searched through every variable from hook_install() to make sure the default values are identical.

If you spot anything else, let me know.

zhangtaihao’s picture

Also, since we're changing the Drush command signature, I've decided to rework the parameter values so they're friendlier.

claar’s picture

Looking good!

+      '--show-message-everywhere' => dt("Show message on all pages. Specifying this will override any option set in --show-message-on. This option has the effect of setting --show-message-on to 0 and --show-message-pages to empty.")

This needs updated to use the new syntax. I hope to install this and test more this week. Thanks!

zhangtaihao’s picture

Status: Needs review » Needs work

Oops, I didn't use git format-patch. I shall fix up the problem you mentioned in #28 and roll a working patch.

zhangtaihao’s picture

Status: Needs work » Needs review
StatusFileSize
new17.27 KB

Oops, guess I could use git diff and you could use git apply.

Anyway, here's the fixed patch.

claar’s picture

Review of #30 -- working very well except for some drush problems:

  1. The maintenance message defaults to being shown to nobody. The default should be everybody; otherwise no maintenance message shows anywhere when the module is first enabled, which is confusing.
  2. $drush @cecs-dev mh-restrict-logins 1 --show-message-to=all --show-message-everywhere
    Show message to all users.
    WD php: explode() expects parameter 2 to be string, array given in                       [error]
    /home/claar/mh/6.x-2.x/maintenance_helper.drush.inc on line 112.
    WD php: array_filter() expects parameter 1 to be array, null given in                    [error]
    /home/claar/mh/6.x-2.x/maintenance_helper.drush.inc on line 112.
    
  3. $drush @cecs-dev mh-restrict-logins 1 --show-message-to=all --show-message-on=only --show-message-pages=
    Show message to all users.
    WD php: implode(): Invalid arguments passed in                                           [error]
    /home/claar/mh/6.x-2.x/maintenance_helper.drush.inc on line 117.
    Show message on only: .
    Restricted logins enabled.
    
  4.     if (isset($show_message_pages)) {
          $pages = array_filter(explode(':', $show_message_pages));
        }
        $pages = maintenance_helper_set_show_message($show_message_on, $pages);
    

    $pages might not be defined here

  5. --show-message-on=only doesn't seem to work
zhangtaihao’s picture

1. Assuming you meant this for not only Drush functionality, I've simply changed the default value.
2. Changed two lines.
3. Symptom of the same problem in 2.
4. I supposed I could add a $pages = NULL; before that. The maintenance_helper_set_show_message function call is supposed to work without the second argument.
5. I think this problem simply trails off the usage of --show-message-pages= in 3. At least it's working on my end.

Oh and yes I forgot to mention that to hide the message, set --show-message-to to nobody. This way, the carefully crafted standard set of pages can be retained.

Thank you very much for your effort in reviewing my code. I have no choice but to contribute in my spare time when my brain operates at about 30% efficiency.

claar’s picture

Status: Needs review » Needs work

Thanks for the fast responses and improvements! Latest review:

  1. My point #5 in Comment #30 was me being an idiot -- I needed to CTRL-refresh my browser to make the form update
  2. Maintenance message shouldn't be shown if restrict logins is disabled. Showing a maintenance message without restricting logins would be a new feature -- create an issue for that if desired.
  3. Let's choose opposing words for show-message-to. Either use "all" and "none", "everyone" and "noone", or "everybody" and "nobody". Your choice.

Drush is working perfectly now -- thanks for all the tweaks.

zhangtaihao’s picture

Yes, I was heavily debating 2 and 3 for weeks. I now agree with your conclusions.

For 3, I think "all" and "none" work better (fewer characters to type, makes better sense, etc.).

zhangtaihao’s picture

Status: Needs work » Needs review
StatusFileSize
new17.32 KB

I think that's pretty much it. Let me know if there's anything else I can improve in this patch.

zhangtaihao’s picture

Oops, missed a "nobody".

claar’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev
Assigned: zhangtaihao » Unassigned
Status: Needs review » Needs work

Needs D7 port.