All Blocks in One Theme Automatically Disabled [closed]

Question

On a Drupal 7 site that I help maintain, the blocks in one of the themes were all disabled automatically. I manually added all of the blocks back of course, but can't promise this won't happen again. To try to find out what happened, I queried the block table and discovered that the tracking columns are not provided (e.g. created, changed, uid). So then I went on to see if MySQL could tell me the last time that these rows were modified, but there is no such native function.

Has anyone seen this problem?

Answer 1

I haven't run into this specific problem, but I would advise getting as much of this as you can into Features - that way you can easily revert it all back, should this problem recur, and you wouldn't have to do it manually.

Answer 2

I have seen this happen many times during migrations in D7. Most commonly, when a region is not defined in a new or alternate theme... then the block gets disabled. There are also contrib (and definitely custom) modules that can have the same impact. Last but not least, install profile use - and subsequent misuse - can readily cause this behavior. Especially when there is a theme in the profile. In most cases I've seen, the issue is a result of many hands over time maintaining code in different (and sometimes conflicting) ways.

On the second question, D8 has significant changes and vastly improved blocks. In fact, new in Drupal 8 are the Block Plugin API, which is a stand-alone reusable API and the Block Entity API which is used for block placement and visibility control.

If you're curious what revision fields are present in D8 (and this might have changed in more recent versions) 2 of the relevant tables are:

mysql> describe block_content;
+-------------+------------------+------+-----+---------+----------------+
| Field       | Type             | Null | Key | Default | Extra          |
+-------------+------------------+------+-----+---------+----------------+
| id          | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| revision_id | int(10) unsigned | YES  | UNI | NULL    |                |
| type        | varchar(32)      | NO   | MUL | NULL    |                |
| uuid        | varchar(128)     | NO   | UNI | NULL    |                |
| langcode    | varchar(12)      | NO   |     | NULL    |                |
+-------------+------------------+------+-----+---------+----------------+
5 rows in set (0.00 sec)

and:

mysql> describe block_content_revision;
+--------------+------------------+------+-----+---------+----------------+
| Field        | Type             | Null | Key | Default | Extra          |
+--------------+------------------+------+-----+---------+----------------+
| id           | int(10) unsigned | NO   | MUL | NULL    |                |
| revision_id  | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| langcode     | varchar(12)      | NO   |     | NULL    |                |
| revision_log | longtext         | YES  |     | NULL    |                |
+--------------+------------------+------+-----+---------+----------------+
4 rows in set (0.00 sec)

You will note that even though entities are now being used and therefore revision goodness is present... the fields you were looking for (created, changed) are not available in D8 for these tables.