0

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?

  • I modified the question after it was put on hold for being too broad. I changed the question to describe the problem I experienced, the effort I put in to understand what happened, and then asked if anyone else had seen this. Why is the question closed? – ann b May 18 '17 at 16:10
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.

  • Another reason to move the configuration to code. I'll look into this. Thank you. – ann b May 12 '17 at 21:02
0

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.

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