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.When running DB update, updating from 8.x-1.0-alpha6 to 8.x-1.0-alpha7 I get the following:
Error: Call to a member function getConfiguration() on null in Drupal\Core\Config\Entity\ConfigEntityBase->preSave() (line 320 of /var/www/dev/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php) #0 /var/www/dev/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(434): Drupal\Core\Config\Entity\ConfigEntityBase->preSave(Object(Drupal\Core\Config\Entity\ConfigEntityStorage)) #1 /var/www/dev/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(389): Drupal\Core\Entity\EntityStorageBase->doPreSave(Object(Drupal\workbench_access\Entity\AccessScheme)) #2 /var/www/dev/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(259): Drupal\Core\Entity\EntityStorageBase->save(Object(Drupal\workbench_access\Entity\AccessScheme)) #3 /var/www/dev/web/core/lib/Drupal/Core/Entity/Entity.php(377): Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object(Drupal\workbench_access\Entity\AccessScheme)) #4 /var/www/dev/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php(637): Drupal\Core\Entity\Entity->save() #5 /var/www/dev/web/modules/contrib/workbench_access/workbench_access.post_update.php(51): Drupal\Core\Config\Entity\ConfigEntityBase->save() #6 /var/www/dev/web/core/includes/update.inc(241): workbench_access_post_update_convert_to_scheme(Array) #7 /var/www/dev/web/core/includes/batch.inc(294): update_invoke_post_update('workbench_acces...', Array) #8 /var/www/dev/web/core/includes/batch.inc(137): _batch_process() #9 /var/www/dev/web/core/includes/batch.inc(93): _batch_do() #10 /var/www/dev/web/core/modules/system/src/Controller/DbUpdateController.php(186): _batch_page(Object(Symfony\Component\HttpFoundation\Request)) #11 [internal function]: Drupal\system\Controller\DbUpdateController->handle('start', Object(Symfony\Component\HttpFoundation\Request)) #12 /var/www/dev/web/core/lib/Drupal/Core/Update/UpdateKernel.php(110): call_user_func_array(Array, Array) #13 /var/www/dev/web/core/lib/Drupal/Core/Update/UpdateKernel.php(73): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request)) #14 /var/www/dev/web/update.php(28): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #15 {main}.
Notice: Undefined offset: 1 in Drupal\system\Controller\DbUpdateController->results() (line 413 of core/modules/system/src/Controller/DbUpdateController.php).
Drupal\system\Controller\DbUpdateController->results(Object) (Line: 179)
Drupal\system\Controller\DbUpdateController->handle('results', Object)
call_user_func_array(Array, Array) (Line: 110)
Drupal\Core\Update\UpdateKernel->handleRaw(Object) (Line: 73)
Drupal\Core\Update\UpdateKernel->handle(Object) (Line: 28)
Warning message Notice: Undefined offset: 1 in Drupal\system\Controller\DbUpdateController->results() (line 413 of /var/www/dev/web/core/modules/system/src/Controller/DbUpdateController.php) #0 /var/www/dev/web/core/includes/bootstrap.inc(566): _drupal_error_handler_real(8, 'Undefined offse...', '/var/www/dev/we...', 413, Array) #1 /var/www/dev/web/core/modules/system/src/Controller/DbUpdateController.php(413): _drupal_error_handler(8, 'Undefined offse...', '/var/www/dev/we...', 413, Array) #2 /var/www/dev/web/core/modules/system/src/Controller/DbUpdateController.php(179): Drupal\system\Controller\DbUpdateController->results(Object(Symfony\Component\HttpFoundation\Request)) #3 [internal function]: Drupal\system\Controller\DbUpdateController->handle('results', Object(Symfony\Component\HttpFoundation\Request)) #4 /var/www/dev/web/core/lib/Drupal/Core/Update/UpdateKernel.php(110): call_user_func_array(Array, Array) #5 /var/www/dev/web/core/lib/Drupal/Core/Update/UpdateKernel.php(73): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request)) #6 /var/www/dev/web/update.php(28): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #7 {main}.| Comment | File | Size | Author |
|---|---|---|---|
| #25 | 2944777-wa-update-hook-25.patch | 1.18 KB | agentrickard |
| #24 | 2944777-wa-update-hook-24.patch | 1.17 KB | agentrickard |
| #23 | 2944777-wa-update-hook.patch | 703 bytes | agentrickard |
Comments
Comment #2
agentrickardThis is not a useful report. Pasting log messages without context (or readable formatting) is not helpful.
* How did you run the update?
* Where did the error occur?
* Were you able to run the update?
* If so, does the error still occur?
* Does everything work?
We have working tests for the upgrade path and have never seen this error.
Comment #3
jgbinpa CreditAttribution: jgbinpa commentedI am seeing the same thing when I try to update this module (8.x-1.0-alpha6 to 8.x-1.0-alpha7) through the Drupal admin menus. The first part of updating the files seems to have no problems. This error message happens when trying to do the database updates. If I go back and look at the available updates in Home>Administration>Reports>Available updates, it lists Workbench Access as the latest version (8.x-1.0-alpha7).
We had disabled Workbench Moderation for most content, so don't believe we use Workbench Access either. I can still edit and view content with no problem. Hope this helps. If there is anything else you would like me to try let me know.
Comment #4
jgbinpa CreditAttribution: jgbinpa commentedThis is the error that I see before going to the log to see the PHP errors listed above.
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /update.php/start?id=5201&op=do_nojs&op=do
StatusText: OK
ResponseText:
The update process was aborted prematurely while running update # in workbench_access_post_update_convert_to_scheme.module. All errors have been logged. You may need to check the watchdog database table manually.
Comment #5
agentrickard@jgbinpa This is very helpful.
What version of Drupal are you running?
Comment #6
jgbinpa CreditAttribution: jgbinpa commentedThe latest 8.4.4
Comment #7
agentrickardI was hoping you were going to say 8.3, honestly.
I'll try to dig in to replicate, but wasn't able to on 8.5 yesterday.
Were you able to update via drush?
Comment #8
mmjvb CreditAttribution: mmjvb as a volunteer commentedSuggest to increase PHP max_execution_time or to disable it.
Comment #9
agentrickard@mmjvb I don;'t think that's related to this error.
Comment #10
agentrickard@jgbinpa
I was just able to run the update on 8.4.4 via the update.php UI with no issues and nothing logged in the Watchdog.
I am testing on PHP 7.1.2 with 512 MB of memory.
Comment #11
mmjvb CreditAttribution: mmjvb as a volunteer commentedIt is a common issue on the forum. An Ajax call timing out. It is also very ease to check, just set it to zero and restart webserver.
Don't know what would say "aborted prematurely", but definitely sounds like max_execution_time. Basic troubleshooting 101 !
Comment #12
agentrickardExcept that in this case we have a different, known error with a stack trace,
Comment #13
larowlanHi @jgbinpa - what access scheme are you using?
This would indicate that you're not using either menu or taxonomy, as the plugin collection is unable to get the configured scheme's configuration.
I know that entity_hierarchy module provides and access scheme that is yet to be updated to the new API.
Is it possible you're using this or a custom implementation?
Comment #14
larowlanI think this will be an issue for entity hierarchy too, if we save the scheme with no configured hierarchy plugin, this error will occur.
It was our (jibran and myself) intention to have a post update hook for entity_hierarchy that ran after this one and fixed the default scheme, but that won't be possible in this scenario, because of the error seen here.
So I think that means we need a) another update test and b) a way for contrib modules to intervene and update.
But let's wait for @jgbinpa to confirm first.
Comment #15
agentrickardThat all makes sense. I was testing with the Taxonomy plugin.
Comment #16
jgbinpa CreditAttribution: jgbinpa commented@larwolan, the website was built by a third party and I don't know their intentions of installing Workbench Access module. Essentially we have disabled moderation for most (if not all) of our content types as there are very few people creating/updating content. Our content is either published or unpublished. There is nothing configured on the WorkBench Access configuration page (i.e. Taxonomy or Menu are not checked under Active Access Scheme). We should actually just uninstall this module and disable Workbench Moderation. But maybe we'll need it for the future.
@mmjvb, we are running on Pantheon, so I don't have any access to underlying platform (or at least that I know of).
@agentrickard, I have not tried to update using Drush. I haven't used Drush much, so will look into how to run that in the Pantheon environment (possibly through Terminus/Kalabox?) and give that a try. I believe I did try to run the update.php command with no success.
I'll copy my site into a sandbox area and try things out there.
Comment #17
mmjvb CreditAttribution: mmjvb as a volunteer commentedDon't know about pantheon but the url admin/reports/status/php should give you the information. Default value in php normally is 30, very unlikely to be enough. Suspect you to be alright on pantheon, though. Obviously, when not in control, place a service request with those that are.
Comment #18
larowlanHi @jgbinpa if you have no scheme configured, then it sounds like you're not using the module.
You should uninstall any modules you're not using.
@agentrickard do you think we need to handle this case in the upgrade path? It seems like an edge case.
Comment #19
jgbinpa CreditAttribution: jgbinpa commented@mmjvb - max_execution_time is set to 120
@larowlan - I agree about removing the module, just need to find the time to verify and execute.
Comment #20
agentrickardWell, the upgrade path shouldn't break if no schemes are present, so perhaps we do need to handle it.
Comment #21
agentrickardComment #22
agentrickardClosed the wrong issue.
Comment #23
agentrickardHere's a patch that should help. It introduces hook_workbench_access_scheme_update_alter() to let other modules add their settings array for saving.
If not set, an Exception should be logged.
Comment #24
agentrickardNew patch that should work on d.o. testing.
Comment #25
agentrickardLet's try using proper syntax this time.
Comment #26
larowlanLooks good to me
Comment #27
agentrickardDoes this actually work with the Entity Reference plugin?
Comment #28
larowlanI will need to work on #2944891: Update access sub-module to allow for changes in WBA to confirm - are you happy to hold off until then?
Comment #29
agentrickardYes. The only thing I'm really concerned about is if the alter hook will fire properly inside the update context.
People can use this patch in the meantime if they receive this error.
Comment #30
agentrickardThis doesn't work correctly since it prevents all other updates from firing, which could be a problem later.
Comment #31
agentrickardI've tested out the new upgrade path here -- https://github.com/agentrickard/workbench_access/pull/110 -- and due to an error in alpha8, think we need to push ahead with beta1.
I'm going to start prepping the change records and documentation, hopefully for a release later this week.
Comment #32
agentrickardThis has been committed.
In the beta release notes, I'll add a disclaimer about contributed module upgrade paths.