Drupal node access rebuild progressive

A short introduction to a tiny project that I recently decided to move off my sandbox on drupal.org : node_access_rebuild_progressive.

If you‘ve used Drupal for a while you’re probably familiar with the “The content access permissions need to be rebuilt.” message that pop-ups when a new content access module is installed, or when certain updates have been performed.

While the process is generally quite fast on small sites, the time needed to generate grants grows quickly with the amount of content and complexity of access rules involved.

Drupal core’s method (have peek at the code for D7 or D8) is to first delete all grants and then rebuild them node by node. This means access to any node will be denied for all users until the node has been processed. In most cases, it means your site will be down until the whole process is finished!
On smaller sites, a few minutes of downtime might be acceptable, especially if you have no alternative. At larger scale, you do begin to look for alternatives.

A while back we were faced with a (D7) site using both Organic Groups and Private, with complex access rules and over 400,000 nodes. Rebuilding content access rules, even on a fairly powerful server, would take 6 hours.
At the time, I hunted around for a way to rebuild those access rules in the background, and discovered the https://www.drupal.org/project/queued_node_access_rebuild module. It looked promising, but we hit https://www.drupal.org/node/2500743 due to the large number of nodes to process. Sadly this meant we couldn’t use it.

For a number of other reasons (issue queue seemed stalled, I wasn’t convinced of the need to use a queue when the node table contained all we needed, no Drupal 8 port, …) but mostly because I was in a rush to have a working solution, I started from scratch and created this tiny module.
I left it in a sandbox on drupal.org and didn’t really plan on releasing it as a “full” project.

Recently, I needed to use it again, and it struck me that it was actually quite useful for any site, regardless of its size. Why would you want downtime, even a little, for any reason, if it can be avoided using a tiny module?

I’m not sure what the rationale behind Drupal core’s behaviour¹ is; I suppose it takes a conservative approach and makes sure a node can’t be accessed until the new “rules” for it apply.

This strikes me as not quite right: if the node was accessible until now, where is the harm in keeping it accessible during the access rebuild process? It seems to me that “keep the old rules in place until the new ones are computed” is as valid and sensible as “deny everything until the new rules apply”. And it’s far less detrimental to your visitors’ experience as well.

So, there we go, node_access_rebuild_progressive is now promoted to a “full” project on drupal.org, and I’m planning to install it on every site that uses a content access module.

[1] If you do know, please give me a shout. Extra karma if you can point me to an issue for this on d.o.