Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
ArgumentCountError: Too few arguments to function Drupal\twig_field_value\Twig\Extension\FieldValueExtension::__construct(), 4 passed in /web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 261 and exactly 5 expected in Drupal\twig_field_value\Twig\Extension\FieldValueExtension->__construct() (line 78 of modules/contrib/twig_field_value/src/Twig/Extension/FieldValueExtension.php).
I guess we need this in the .install file:
/**
* Rebuild the container cache.
*/
function MYMODULE_update_NNNNNNN() {
\Drupal::service('kernel')->rebuildContainer();
}
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork twig_field_value-3471185
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
anybodyComment #4
anybodyComment #5
anybody@grevil: Please test and review.
Comment #6
grevil commentedUsually a simple "drush cr" after the update would be enough here, but we can simply clear the cache as well! LGTM.
Comment #8
grevil commentedComment #9
djg_tram commentedSame error with updating to 2.0.4, simple cache clear doesn't help.
Comment #10
anybody@djg_tram did you run updb and see the update message also?
Comment #11
djg_tram commentedI 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, then clear cache (the second probably not required but to be sure).
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 intensively yet. It would be a major PITA on a real production site.
Comment #12
anybody@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...
Comment #13
djg_tram commentedIt 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 crworks butdrush updbdoes not becauseproc_openis disabled and while they offer up a few items ofphp.inito 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. :-)Comment #14
anybodyThanks 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)?
Comment #15
djg_tram commentedNo, 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. :-)
Comment #16
anybody@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.
Comment #18
taran2l@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.
Comment #19
anybodyThanks @taran2l,
could you please implement the suggested change to let me know, how it should be done in your opinion? This is open source, so thank you for your help and advice!
Comment #20
taran2lit's here #3478474: Add a BC layer for service argument change
Comment #21
anybodyThanks @taran2l!