Needs work
Project:
Maintenance Helper
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
17 Sep 2010 at 03:04 UTC
Updated:
17 May 2013 at 14:46 UTC
Jump to comment: Most recent file
Comments
Comment #1
gregglesSure, we could make it a dropdown as to how the message works instead of the checkbox that is there now.
Comment #2
zhangtaihao commentedI am strongly in support of this feature.
@greggles: Is there any update on this? If not, would you like me to have a go?
Comment #3
claar commentedFeel 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.
Comment #4
gregglesI would love to have help with the module. Please post a patch and I will review it.
Comment #5
zhangtaihao commentedI'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:
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.
Comment #6
zhangtaihao commentedOops, 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.
Comment #7
claar commentedIt'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:
I see three obvious maintenance message locations one might want, in order of likeliness:
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?
Comment #8
zhangtaihao commentedI 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:
The exact wording can be tweaked, but the principles remain. I think these options should leave the module adequately open for configuration.
Comment #9
zhangtaihao commentedOh, and as with the existing module, the lockout message is technically independent of the maintenance message.
EDIT: actually, now that I think about it:
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.
Comment #10
claar commentedWould 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:
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?
Comment #11
zhangtaihao commentedOkay, sorry for complicating this whole issue. My requirement is:
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:
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.
Comment #12
claar commentedAlright, 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!
Comment #13
zhangtaihao commentedI'll be on it once I'm freed up tomorrow.
Comment #14
zhangtaihao commentedI 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.
Comment #15
zhangtaihao commentedHere's the subsequent patch from the last one. I've also pushed again to my branch.
Comment #16
claar commentedYour 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.
Comment #17
zhangtaihao commentedI'm on it. Sorry about the line endings. The Eclipse line ending settings can be a little confusing.
Comment #18
zhangtaihao commentedTurned 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.
Comment #19
claar commentedAmazing 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.
warning: Invalid argument supplied for foreach() in /inet/www/drupal-dev/htdocs/includes/form.inc on line 1212.Code should be removed rather than commented out.
This default value should match the value set in maintenance_helper_install() (occurs several places in the patch)
Needs newline.
Comment #20
claar commentedComment #21
zhangtaihao commentedI'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.
Comment #22
claar commentedYou 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:
show-message-on should be optional (also, --show-message-everywhere should work without other options set -- it currently gives this same error)
show-message-to should be optional
A few things here
+ * Sets the maintenance message -- used by drushEnsure when using "variable_get()" that the default values match those set in maintenance_helper_install() -- I think this is all of them:
Thanks for the fast and great work, zhangtaihao!
Comment #23
claar commentedOh yeah, I forgot to mention this non-standard encoding in the patch of maintenance_helper.install:
Comment #24
zhangtaihao commentedI 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?
Comment #25
claar commentedA note on the project page sounds fine to me! Yes, all of the parameters should be optional.
Comment #26
zhangtaihao commentedSorry 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.
Comment #27
zhangtaihao commentedAlso, since we're changing the Drush command signature, I've decided to rework the parameter values so they're friendlier.
Comment #28
claar commentedLooking good!
This needs updated to use the new syntax. I hope to install this and test more this week. Thanks!
Comment #29
zhangtaihao commentedOops, I didn't use
git format-patch. I shall fix up the problem you mentioned in #28 and roll a working patch.Comment #30
zhangtaihao commentedOops, guess I could use
git diffand you could usegit apply.Anyway, here's the fixed patch.
Comment #31
claar commentedReview of #30 -- working very well except for some drush problems:
$pages might not be defined here
Comment #32
zhangtaihao commented1. 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. Themaintenance_helper_set_show_messagefunction 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-totonobody. 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.
Comment #33
claar commentedThanks for the fast responses and improvements! Latest review:
Drush is working perfectly now -- thanks for all the tweaks.
Comment #34
zhangtaihao commentedYes, 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.).
Comment #35
zhangtaihao commentedI think that's pretty much it. Let me know if there's anything else I can improve in this patch.
Comment #36
zhangtaihao commentedOops, missed a "nobody".
Comment #37
claar commentedNeeds D7 port.