Problems with db update: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'module' cannot be null

I have the same problem. It occurs inside user_role_grant_permissions() at line 3151 (user.module, version 7.38). user_permission_get_modules() does not contain the permission to module mapping for the use media wysiwyg permission which has been added to the module.

Even rebuilding the permission via /admin/reports/status/rebuild before running the updates does not help.

I tried to replicate this without luck. Using drush and update.php always works for me. But if I have to guess the cause of this issue is probably related to alpha4 of media_wysiwyg didn't include a hook_permission and now beta1 does. For some reason when you run the update, drupal doesn't realize media_wysiwyg is implementing the new permission and then user_role_grant_permissions fails.

This patch flush the hook_permission cache to force drupal to search new modules implementing hook_permission. Let me know if this fix this issue.

The patch doesn't work for me, I'm afraid. Still get the error trying to run update 7201.

Same here, the patch didn't work for me. I also tried clearing all caches before performing the update, but I still get the error.

I can confirm that I am updating from version 2.0-alpha4 to beta1. (And I can't use drush on this server, so using update.php.)

Hmmm... I commented out the permission-adding line in the media_wysiwyg_update_7201 function, just to get the database update to complete. Then, when I went to manually add the missing permission via the Drupal UI, I discovered that the media_wysiwyg module was not enabled. So I enabled the module and added the permission manually.

I don't know why a module's update_N function is being called for a disabled module, but perhaps others with this problem might also find that the media_wysiwyg module is disabled, and that enabling it allows the update to run?

Yes! Thank you fonant, I can confirm that enabling the media_wysiwyg module allowed the upgrade to perform successfully. I disabled it right after.

Note: in my case, maybe the module had already been enabled and disabled at a previous time (I can't remember for sure, and I didn't think to check before enabling it today). What I mean is that maybe the module was already "installed" (i.e. present under the "uninstall" tab) even though it was disabled, which would explain why this upgrade function was activated. If that was the case, then it's possible that properly uninstalling the module before upgrading is another way to avoid this problem. (As I say, not entirely sure. Just writing that here in case someone else has the same problem.)

Mmmm from my memory and looking at https://api.drupal.org/api/drupal/includes!install.inc/function/drupal_g... will hook_update_N() run for even disabled modules.

Aha! In which case the hook_update_N() function cannot assume that the module is enabled, and should proceed with care.

Drupal 8 doesn't have the concept of "disabled but installed" modules, which will simplify things. In D8 modules are either installed, and managing database updates, or uninstalled with no module-specific data in the database.

Patch #3 did not work for me either.

fonant, so from the sounds of your post, you commented out the following code of media_wysiwyg.install:

foreach ($roles as $rid => $role) {
  user_role_grant_permissions($rid, array('use media wysiwyg'));
}

I did this and the update script worked but what exactly does this code add to the database and how do I do this manually (in phpmyadmin)?

Thanks.

So, all the issues here are related to the fact the media_wysiwyg is disabled?

E Johnson: that line grants each role with RID $rid the "use media wysiwyg" permission. It does this for all roles that currently have the "use media browser" permission. To do the same thing manually, go to the permissions table, and find the roles that have "use media browser" permission, and give them the "use media wysiwyg" permission too.

The line of code fails if the media_wysiwyg module is not enabled, but is installed. In that situation the update function is run, but the "use media wysiwyg" role is not defined so it cannot be assigned to those roles. Enabling the module first allows the update to run without error.

I can confirm #8, enabling the module before updating works.

Maybe this can be solved by letting the module enable itself in the update hook if it isn't and then disabling again it if wasn't enabled before.

Patch also working properly here, upgrade from Commons 2.21 to 2.30. media_wysiwyg had to be enabled for it to work, but I think the patch is good enough to commit, as it brings an improvement and will be able to unblock many upgrades.

Another confirmation that having the Media WYSIWYG module disabled caused this problem, and enabling the module before re-running the update resolves it. I did have to enable the module by modifying the system table in the database directly, because I was unable to change the status of any Media modules on the modules page once I'd attempted the update and gotten this error. Hooray for local dev environments; now I know to enable it before I run the update on production!

Recent versions of media have resolved most of peoples concerns and is compatible with entity translation, multilingual and various advanced configurations. Due to the high volume of inactive and most often irrelevant issues we are Closing this as (outdated). If for whatever reason this issue is important to you AND you still have issues after checking the media recipe documentation, then let us know and we will review your concerns.

Otherwise, see the recipe documentation for how to configure media and for troubleshooting tips OR refer to the media_dev distribution if you want to see a working media setup.

As mentioned, feel free to make some noise in this issue if you still feel it is important to you or someone else.

Thanks,

Media team