2.0.3 update should containers

@grevil: Please test and review.

Usually a simple "drush cr" after the update would be enough here, but we can simply clear the cache as well! LGTM.

Same error with updating to 2.0.4, simple cache clear doesn't help.

@djg_tram did you run updb and see the update message also?

I had to:

1. manually remove the Renderer argument from the constructor.
2. Clear cache so that the site will return from WSOD.
3. Re-insert the argument.
4. Run UPDB manually.
5. Then it works.

Not fun. The upgrade process should be tested a bit more, I'm afraid. :-) This was on a production site that isn't used yet intensively. It would be a major PITA on a real production site.

@djg_tram it is tested, so I'm wondering how that happens. Typically only (4.) should be required.

I guess you're doing updates manually (+ update.php)?, not using composer and drush?

Just to better understand the circumstances...

It depends on the particular site and situation. If I'm already inside a site with smaller traffic volume and requirements (not one that postulates fully separated test and production environments, just the smaller garden variety ones), logged in and just see that a couple of modules need to be upgraded, it's usually much simpler to let it happen there with the UI and then run the update as well. I also use the new Navigation module with my own additions that make both db update and cache clear readily available. In these cases, I only fire up the console access with Drush if necessary (core upgrade needed or WSOD).

With more complex schemes I might go the Composer and Drush route immediately. I don't particulary like the Composer approach for modules, so I tend to avoid it with my own modules but that's more like a question of preferences. At any rate, even if many modules do recommend Composer, I still think that as long as Drupal actually has the old way, that should also work.

Especially as, unfortunately, it's still not always easy to set up an environment that provides full Drush/Composer functionality, I just happened on a site where drush cr works but drush updb does not because proc_open is disabled and while they offer up a few items of php.ini to customize, this isn't among those. And equally unfortunately, just telling the client to move to a better provider is not always the most feasible solution. :-)

Thanks for the details @djg_tram. Just one last question: After updating the module, were you able to access /update.php and run the update(s)?

No, there was a WSOD that blocked everything. I could only solve it by temporarily modifying the source code (as described above). As I do module development actively myself (both some contrib and many for in-house solutions), it was possible but not all admins are created equal. :-)

@djg_tram I tried reproducing this in several projects and environments and can't reproduce or confirm it anywhere. I think your criticism is unjustified. We also have no other reports of that issue.

So I'm finally closing this, of course I'm still sorry for the trouble you had.

Automatically closed - issue fixed for 2 weeks with no activity.

@anybody hi

Unfortunately, this is not how this thing should be fixed, as update runs after cache rebuild (usually), so I can't get to that.

Core always adds a BC layer when arguments change, this should be done here as well.

Thanks @taran2l,

could you please implement the suggested change to let me know, how it should be done. This is open source, so thank you for your help and advice!

it's here 🐛 Add a BC layer for service argument change Active

Thanks @taran2l!