Closed (fixed)
Project:
Views Bulk Operations (VBO)
Version:
8.x-3.6
Component:
Actions
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
3 Apr 2020 at 17:09 UTC
Updated:
27 Aug 2020 at 09:44 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
tresti88Comment #3
smustgrave commentedTested the patch in #2 and the install is able to run now.
Comment #4
neslee canil pinto@smustgrave, can you please attach a screenshot for your tests. Thanks.
Comment #5
smustgrave commented----------------------- ----------- --------------- -------------------------------------------------------------
Module Update ID Type Description
----------------------- ----------- --------------- -------------------------------------------------------------
views_bulk_operations 8034 hook_update_n Convert configuration of existing views to the new schema.
----------------------- ----------- --------------- -------------------------------------------------------------
// Do you wish to run the specified pending updates?: yes.
> [notice] Update started: views_bulk_operations_update_8034
> [notice] 2 view configs converted.
> [notice] Update completed: views_bulk_operations_update_8034
[success] Finished performing updates.
Comment #6
neslee canil pintoThanks @smustgrave, moving to RTBC
Comment #7
graber commentedThis patch doesn't make sense, with the old config structure (see /views_bulk_operations/tests/views_bulk_operations_test/config/install/views.view.views_bulk_operations_test.yml for an example), selected actions is an associative array of strings so accessing `$plugin_id['action_id']` when $plugin_id is a string will result in a type error.
I don't know about the status of the issue but definitely not RTBC, setting this back to active, I feel that updates were already performed somehow on your instances.
If anyone wants to check on this, please try to reproduce the following way:
1. Start from a clean instance, install VBO 3.4 or lower and add a view containing the VBO field with at least one configured action.
2. Update VBO to the latest dev
3. Run database updates.
Comment #8
smustgrave commented@Graber appears that was probably the case.
Followed the steps you mentioned and it updated without fail. Could it be possible that One developer did the updates locally, captured the changes and checked those in. Then on a dev environment when updb was ran it failed because the changes were already done.
The patch mentioned does resolve the issue for our team though.
Comment #9
tresti88@Graber makes sense. I did wonder why this wasn't raised before. I guess we need to check if
$plugin_idis explicitly a string instead? See attached a new patch.Just to give some background to my workflow and why i came across the error. We have Docker tooling which automatically builds our local environments from scratch, this includes pulling down a database from remote storage. This database reflects an early stage of what Drupal was in the project. When the environment builds, various commands run to import up-to date config and to run database updates etc these all bring the db inline with what the latest versions of modules expect. We also have this same process on open PRs to check and make sure builds pass before we deploy. I guess i forgot about updating my view and exporting it (which put it into the new format). To fix the issue we could update our remote db, however i believe skipping views where the
$plugin_idisn't a string (assuming that's good enough) allows others to not encounter this error?Comment #10
tresti88Comment #11
gaurav_drupalSame issue and I tried patch #9. It worked for me. Thanks.
Comment #12
singhrt commentedThanks @tresti88, saved my day #9 worked for me as well.
> [notice] Update started: views_bulk_operations_update_8034
> [notice] 4 view configs converted.
> [notice] Update completed: views_bulk_operations_update_8034
Comment #13
s-jack commented#9. It worked for me. Thanks.
Comment #14
Coops_Confirming #9 worked great, thanks!
Comment #15
borisson_I had the same issue, #9 also worked for us. This is a really small fix and while it usually is not a good idea to edit existing update hooks, in this case it seems to be the best possible solution.
+1
Comment #17
graber commentedProbably no one will experience this anymore but finally committing - this actually prevents errors when updating config that was already updated. Will do no harm and may help someone.
Thanks all!