Install fails if block_class is included with install profile

Hi mbutsko,

Thanks very much for reporting this issue and providing a few more details.

What would you recommend to fix this issue?

Personally, I think we should perhaps consider removing the two updates 7100 and 7101 from the 7.x-2.x branch, since anyway the database structure doesn't match anymore.

Would anybody see any potential issue with that?

Thanks very much to all in advance for your feedbacks, testing and reporting.
Cheers!

This is also causing issues with clearing your cache and viewing your modules through the admin interface.

As for a fix, instead of deleting the 7100 and 7101 updates, you can just check to make sure the table exists before you start doing things with them.

Hi guys,

Thanks a lot for your follow-up and sorry for this late reply, but I was hoping we could get some more feedback.

@perz13:

you can just check to make sure the table exists before you start doing things with them.

Sure, that would sound like a good idea, but I'm still not completely clear about why the 7100 and 7101 updates would run, as reported by @mbutsko.

Indeed, the API function hook_update_N page mentions:

• mymodule_update_7100(): This is the first update to get the database ready to run mymodule 7.x-1.*.
• mymodule_update_7200(): This is the first update to get the database ready to run mymodule 7.x-2.*. Users can directly update from 6.x-2.* to 7.x-2.* and they get all 70xx and 72xx updates, but not 71xx updates, because those reside in the 7.x-1.x branch only.

Since the version enabled by @mbutsko is 7.x-2.x, shouldn't the 7.x-1.x updates be ignored? (in particular, 7100, 7101).
In which case, I would assume update 7103 should be changed to 7200, which would allow updating from 7.x-1.x to 7.x-2.x.

In short, from what I understood in the API document, 7100, 7101 shouldn't be run as updates for the 7.x-2.x branch and the 7103 should be changed to 7200 (as the first update to get the DB ready to run 7.x-2.x).
 

We could certainly add a test in updates 7100, 7101 to check if the table exists, but if possible, I would like to understand a little bit more how these updates work and run.

I would greatly appreciate to have your feedback, help and guidance on this issue. In particular, whether my interpretation could be wrong or perhaps not precise for certain situations.

Thanks very much to all in advance for your answers, help, reviews, testing, feedback and comments on this issue.
Cheers!

Getting back to this issue, after almost a month and unfortunately, I would have expected perhaps a little bit more feedback.

I still haven't figured out the answers to the questions from #3, but after second thoughts, the API function hook_update_N page is pretty clear about removing update functions or renumbering:

A good rule of thumb is to remove updates older than two major releases of Drupal. See hook_update_last_removed() to notify Drupal about the removals. For further information about releases and release numbers see: Maintaining a drupal.org project with Git

and renumbering:

Never renumber update functions.

Which would seem to restrict the options that we would have to fix this issue (since these update functions shouldn't be removed or renumbered), to checking in update functions whether the block_class table would exist.

Since it appears to be a simple and appropriate solution to fix this issue, I went ahead and committed the changes against the 7.x-2.x branch at ea4e81b.

I allowed myself to mark this issue as fixed for now, but feel free to re-open it, or post a new ticket, at any time if you have any further objections with this issue or the changes made at ea4e81b (we would surely be happy to hear your feedback).

Please let me know if you would have any further comments, feedback, questions, issues, objections, suggestions or concerns on the commit or this ticket in general, I would be glad to provide more information or explain in more details.

Thanks in advance to everyone for your testing, reviews, feedback and comments on this issue.
Cheers!