Token support for site maintenance mode message

Why does this patch change @site to !site? Also, the usage of t() is a bit suspect, it should include all those vars and that space in one t() call.

You're right, the approach looks good and you're just reusing existing strings which makes sense. Haven't tested the patch though.

Updated patch. Hope I didn't screw anything up.

The UI needs to explain non-obvious concepts like 'uri brief.' Lists of items should have 'and' before the last item when we are writing English.

Patch no longer applies, bumping to D7.

Rolled again for D7, but with @ instead of ! and I combined the vars into the form description t() with "and" instead of breaking them out as a list.

The patch works as advertised for me.

Not sure if this is a show-stopper or not, but I suspect it is. There is the following edge-case problem:
With the use of "@" in the token, you run up against accidental matches with email addresses. For example, if the site was called "Sitewise: A wise place", the "@site" in "Please contact dale@sitewise.com" would get matched and replaced, becoming "Please contact daleSitewise: A wise placewise.com".

Using the strtr function for string replacement does not allow escaping the "@" sign to prevent this.

I wonder if using "!" would be better, or perhaps the same format as the token module ([site], [uri], etc)?

If you want to stick with the "@" symbol I suggest a regex to check for whitespace/linebreak after the tokens. This isn't entirely ideal, since someone may want to use something like: Administrators can still log in at the <a href="@uri/user/login">site login page</a>

I agree with drumm in #6 but doq is correct, he's just following the example in admin/settings/user. Is this a case where admin/settings/user needs improving, or a case where this patch should follow the admin/settings/user example?

This version switches to the bracketed token module style, adds a sentence explaining uri_brief, and fixes code style on concats.

...and I left out a @ to [] change fixed here.

Beauty, works as advertised.

Regarding the current help text:

Message to show visitors when the site is in off-line mode. Available variables are [site], [uri], [uri_brief], [mailto], and [date]. uri_brief is uri without the preceeding "http://".

This is purely my opinion, so maybe don't reroll the patch without further feedback. I think you either explain all of the variables or none of the variables. Except for date, I don't think its safe to assume the user will understand any of the variables, so it seems strange to single out just one for explaining.

My vote would be for a terse version following the admin/settings/user example:

Message to show visitors when the site is in off-line mode. Available variables are [site], [uri], [uri_brief], [mailto], and [date].

If there is a strong desire to document the variables, this isn't the only page requiring it. And my vote would be creating a help page or emulating token module's method for displaying token explanations.

Changes to the terse description suggested in #13.

I asked bot to retest the last patch.

time() replaced

Switches back to ! for tokens and updates for the new maintenance mode variable (the cause of previous apply failure).

Make up your minds people. Whether it's ! or @ doesn't matter WRT string sanitation because strtr doesn't put @ through any cleaning.

@site is used in the first instance because it is processed by t(). @ was selected to sanitize the string. It's never seen by the end-user. t() is only possible there because it is a default value in case the maintenance variable somehow wasn't set when they put it into maintenance mode.

IOW, using @ doesn't bring any extra safety, which is why I added check_plain() separately.

I only used ! because you claimed "Rest of the web-site is using !token". It could be prefixed with **$^greenboogers for all I care.

#25 is missing the @site replacement for $site_offline_message.

I disagree with #28, but I don't do any translations for anything, so I'm not sure what impact lists have on the ordering of words in language - how that would work in islamic languages for example. I would imagine #27 is more flexible in that instance.

I say keep #27 and make an issue for #30.

doq, please see comment #10 (http://drupal.org/node/97650#comment-1710556). Using @ in this situation has a high probability of conflicts with regular text.

For what it's worth, the tokens used in the site email templates for welcome, account activation, password reset and other messages use !

Bumping to D8. This should use the new Token API in core.

Conversion of site maintenance settings to CMI made @site variable work for 8.x (https://drupal.org/node/1496458#comment-6284826).
Shouldn't we use @site style replacement variables for a seamless 7.x->8.x upgrade? I would like to hear what others think before setting the ball rolling again.
Tokens would be cool, but token path should go first in 8.x and @site would be a 7.x backport. Also, I'm not sure if tokens will be available in maintenance mode. I did a quick test in 7.x and they worked.

Better title.

We switch to using tokens by default, and provide support for running replacement of @site but without exposing it as an option to use.

I did a quick test of comment #10. Some people may wish to display an email address on their maintenance mode screen and if the email address is example@sitewide.com it gets translated as suspected.

Reroll.
-Changed @site to [site:name] in default site maintenance message yml, having to single quote the string.
-Called token_replace after t(). Splitted lines in favor of readability.
-Added "This field supports tokens." to message description. The string is already present when #1308564: Basic token support in fields' help texts is commited. Will also be present in 7.x installs having the contrib 'token' module, if backported.

Updated tests to use the same default value for site maintenance message.

This looks great.

Can't we update the maintenance_mode message very early in the update.php process? I'm not really happy with retaining the BC token @site for forever.

#41: drupal--97650--token-support-for-site-maintenance-mode-message-41.patch queued for re-testing.

Reroll

Added system_update_8043 to address sun's comment in #42

Thanks!

However, I still think we should remove the @site t() replacement handling entirely. Additionally, the entire usage of t() became bogus here in the first place, since a translation of the maintenance mode message needs to be handled by translatable config now.

Adjusted that in attached patch.

AFAICS, the maintenance mode seems to be broken during an upgrade path form D7 to D8 anyway already - the new code tries to read the configuration from config, but the configuration does not exist yet, so it's fairly clear that a site being upgraded to D8 will not show a maintenance mode page at all currently.

That's a preexisting issue though and not changed by this issue/patch. Therefore, I merely added a @todo to the existing update function.

#47: maintenance.token_.47.patch queued for re-testing.

Tested and works OK.

To commiters:
This feature seems worth backporting to 7.x, but with the following considerations:
*No change to current default value, since it would break tranlations.
*No backporting for the update hook, same as above.
*Obviously, no CMI involved
*Others?

Please advise.

I'm not sure about this. What if you have your site in maintenance mode because you're updating something that the token API relies on. This is adding a fairly high-level dependency to that page which could end up breaking no?

The most obvious point I've found where things could break is at the module_invoke_all for getting tokens in token_generate(). In fact, it makes me wonder how tokens should be replaced in general while in maintenance mode. Should token_generate be restricted to module_invoking only system module tokens while in maintenance?
Is there anything else that could break?

I agree with #51 and #52, but I don't know how to restrict module invoking in the way suggested in #52.

Unless we can guarantee that tokens will work during maintenance mode, it might be worth going back to the approach in #27?

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Since there's been no follow up in 3+ months going to close out. If someone still wants this feel free to re-open the ticket!