Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I recently updated a client site from 1.x to 2.x and found that saving a node where the blockreference field was left empty causes a fatal error. When it executes the insert query in field_sql_storage.module, it crashes because it tries to set field_related_resources_moddelta to NULL which is not allowed.
I have been tracing through the code trying to figure out why it's even trying to save the field when it's empty and am having no luck. It's using the default core select options widget so there doesn't seem to be any extra validation going on. I also found that if I initially save the new node with a value, then edit it and remove it, it saves the node fine and does not attempt to save the field.
I am going to continue digging and hopefully provide a patch but any insight would be helpful.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | blockreference-schema_mismatch-3111511-10.patch | 2.86 KB | james.williams |
Comments
Comment #2
MichelleDigging a little more, I realized it's trying to save the field because the node has this:
I haven't figured out where that "bid" is coming from, yet, though.
Comment #3
MichelleI've made some headway in this and the problem is that the upgrade from 1.x to 2.x has issues. I'm not really sure what can be done at this point as most people that are going to upgrade probably have already. Maybe just a warning on the project page? At any rate, here are the issues I hit:
1) After upgrading, all the field config in table field_config_instance still has the default set to "bid". This causes it to have an "invisible" and broken default. You can't see it in the UI but it adds the BID as a default if you try to save a node without setting a value on the field. This is what was causing the fatal error.
The solution is to go in and save every field again, either fixing the default value or blanking it out. But that brought up the next problem.
2) Something went wrong in changing the table field from field_FOO_bid to field_FOO_moddelta. Most of the fields I saved were fine but one ended up with this error:
Attempt to update field Filter block failed: SQLSTATE[42000]: Syntax error or access violation: 1072 Key column 'field_filter_block_bid' doesn't exist in table.
I don't know why it was trying to get the old name for just that one field and I've spent too much time on this to dig into it further. But somehow it was. And the worst part is that, when it didn't find the field it was looking for, it deleted both the field tables! The field was still there in the UI but the field tables were gone. This took down every page that had the field on it. I managed to delete the field and restore the pages to working but that shouldn't have happened.
So my advice is to be very, very careful if you are upgrading from 1.x to 2.x and consider whether you need to do it at all. I thought I had tested it well but these things were sneaky and didn't show up until it was already on production.
Comment #4
james.williams CreditAttribution: james.williams at ComputerMinds commentedHere's a patch to fix the broken default values. I also wonder if this is what #2959970: Default value ran into as well, although that was marked as being for 6.x-1.x (which I doubt is actually the case).
As for the second point, I wonder if that happened after attempting to run the upgrade more than once, or perhaps is something to do with a deleted field? I can't see anywhere that would make blockreference drop the field tables, so perhaps they had already been deleted, but not yet purged (which cron would do)?
It's probably worth dealing with each of these things separately, as I imagine lots of people will run into the first. But I don't think the second will be as common, so doesn't need to block progress on fixing the default values.
Comment #5
james.williams CreditAttribution: james.williams at ComputerMinds commentedWoah, we just discovered a field table that was dropped too. For us, it was because we use features to manage the field, and the export still contained the 'bid' index. If the table has no content in it, then features drops the table and tries to recreate it from that export -- which fails due to the incorrect index.
So, yet again, we need another update hook to fix the damage done by the field schema change :-( Patch on the way...
Comment #6
james.williams CreditAttribution: james.williams at ComputerMinds commentedComment #7
james.williams CreditAttribution: james.williams at ComputerMinds commentedThe latest patch there will ensure new upgrades don't get into the broken state of a table being dropped. However, I've just realised it doesn't help people currently in that state. Further patch to follow... sorry!
Comment #8
james.williams CreditAttribution: james.williams at ComputerMinds commentedHere we go again... this one actually re-creates the field tables if needed.
Comment #9
Michelle@James: Thanks for doing this. I had already managed to get my client's site out of the mess by the time I posted this but your patch may help someone else that finds themself in the same boat. I was lucky that the field that was messed up could just be deleted as it wasn't used. Others may not be so lucky so good to see your work here.
Comment #10
james.williams CreditAttribution: james.williams at ComputerMinds commentedThanks Michelle. Frustratingly, I've just spotted another issue with that latest patch (fields that had their tables dropped wouldn't actually get updated, so could just get dropped if they get updated again in future), so here's an update. I really hope this is now all that's needed!
FYI, the table only goes missing when there is no content in it, so thankfully the issue shouldn't cause anyone any actual data loss.
Comment #11
Michelle"FYI, the table only goes missing when there is no content in it" <-- Ah, that explains why the only field that badly broke was the one that wasn't used. Here I thought I had just been lucky. :)
Comment #12
pifagorComment #14
pifagorComment #15
james.williams CreditAttribution: james.williams at ComputerMinds commentedThanks @pifagor!