4

We are planning a scheduled update of our site. There is no reason for people to not be able to see the site as anonymous users, or even browse their account if they want to log in.

How can I simply prevent people from adding new content while I do the updates instead of having the site completely down from having to use maintenance mode?

3

I would uncheck the "add [type] content" permissions checkboxes on the roles that have it, and re-check them after. However, depending on the updates, having people attempting to log in or use other features of your site may be problematic during updates.

3
  • True, I thought about that. But with a few hundred users plus manually documenting who had what permission, this got tedious quickly. I wonder if there is a module that could handle that? – blue928 Feb 4 '13 at 2:15
  • 3
    Check out the read only mode module drupal.org/project/readonlymode – Nigel Waters Feb 4 '13 at 2:17
  • 1
    You don't have to do it per user, just per role. If you have so many roles that this is cumbersome, you could use Features to export them before changing, then revert. – beth Feb 4 '13 at 2:18
1

I would not recommend this but if I would do it I would disable the login form and remove all sessions from the database. No users are logged in now so there can not be any changes been done to the database. During maintance I would how ever recommend to minimize the risk (on eg conflicts) so putting it in maitance mode still have my preference.

edit: just read the comment about read only mode module, didnt knew that module sounds interesting :)

1

You can also use the Rules module for this. If you don't have Rules enabled yet, you can pretty sure use it to implement lots of other features in your site. That will help to reduce the risk of your site suffering "modulitis" (= way too much contributed modules slowing down a site).

Have a look at this custom rule (in Rules export format):

{ "rules_disallow_updates_to_content" : {
    "LABEL" : "Disallow updates to content",
    "PLUGIN" : "reaction rule",
    "ACTIVE" : false,
    "OWNER" : "rules",
    "REQUIRES" : [ "rules" ],
    "ON" : { "init" : [] },
    "IF" : [
      { "OR" : [
          { "text_matches" : {
              "text" : [ "site:current-page:path" ],
              "match" : "node\/add\/",
              "operation" : "starts"
            }
          },
          { "text_matches" : {
              "text" : [ "site:current-page:path" ],
              "match" : "\/edit",
              "operation" : "ends"
            }
          },
          { "text_matches" : {
              "text" : [ "site:current-page:path" ],
              "match" : "\/delete",
              "operation" : "ends"
            }
          }
        ]
      },
      { "NOT user_has_role" : {
          "account" : [ "site:current-user" ],
          "roles" : { "value" : { "3" : "3" } }
        }
      }
    ],
    "DO" : [
      { "drupal_message" : {
          "message" : "\u003Cstrong\u003EMaintenance ongoing!\u003C\/strong\u003E, therefor a path like [site:current-page:path] is currently not allowed.",
          "type" : "error"
        }
      },
      { "redirect" : { "url" : "no_access" } }
    ]
  }
}

If you have the Rules UI enabled, you can import the above rule in your own site.

Some details about what this rule actually does:

  • The rule is triggered (= Rules Event) for anything a user/visitor does in the site (because of Rules Event Drupal is initializing being used).
  • The first 3 Rules Conditions check if the current path fits any of these patterns (remove or adapt these Rules Conditions to fit your needs, or add similar ones):
    • Starts with node/add/.
    • Ends with /edit.
    • Ends with /delete.
  • The last Rules Condition checks that the user does NOT have role "admin" (so that admin will not be blocked by this rule in case of emergencies), adapt the role id if needed, or simply remove this condition if this exception handling is not desired.
  • If all Rules Conditions are satisfied, then these Rules Actions will be performed:

    • display a message (of type warning) with content like so (with the token replaced by the actual path): Maintenance ongoing!, therefor a path like [site:current-page:path] is currently not allowed.. If you want, change the actual message content, which BTW can also include some HTML markup.

    • Perform a redirect to path no_access (adapt to fit your needs).

All it takes to use this rule is to enable the rule while maintenance is ongoing (and disable the rule when maintenance is finished).

Possible improvements

You have all the power of Rules available to further improve this rule, e.g.:

  • Send an eMail to an admin if special conditions are met (eg to eMail data about the actual user who was blocked by this rule).
  • Refine the message being shown (e.g. with an hyperlink to a page with more details about scheduled maintenance).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.