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.
ctools is not compatible with recent Drupal Core 8.5.x:
[ERROR] The service "ctools.serializable.tempstore.factory" has a dependency on
a non-existent parameter "user.tempstore.expire". Did you mean this:
"tempstore.expire"?
This is caused by Issue #2935617: Move User module's temp stores to core, see Change records https://www.drupal.org/node/2935639
Comment | File | Size | Author |
---|---|---|---|
#19 | tempstore-2936263-19.patch | 16.39 KB | Berdir |
#14 | tempstore-2936263-14.patch | 16.09 KB | stevekeiretsu |
#12 | tempstore-2936263-12.patch | 4.17 KB | stevekeiretsu |
#3 | 2936263-tempstore-3.patch | 534 bytes | jian he |
Comments
Comment #2
jian he CreditAttribution: jian he commentedComment #3
jian he CreditAttribution: jian he commentedComment #5
jian he CreditAttribution: jian he commentedWaiting #2936435: Better BC for deprecated container parameter user.tempstore.expire to solve this issue.
Comment #6
dillix CreditAttribution: dillix commented@jian he it was fixed today.
Comment #7
travisc CreditAttribution: travisc commentedSeems like this should probably followed up on since I ran into this today...
Comment #8
joelpittetDoes the patch fix the issue @travisc?
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedI too would like to know if the patch fixes the issue. I update a Drupal site today and now it is offline with the error:
The service "ctools.serializable.tempstore.factory" has a dependency on a non-existent parameter "user.tempstore.expire"
Comment #10
newme154 CreditAttribution: newme154 commented@tecreasey i'm getting the same issue. it just started for me yesterday. please let me know if you find out anything.
Comment #11
stevekeiretsu CreditAttribution: stevekeiretsu as a volunteer commentedI am running into this as well now (not the error encountered by the two previous commenters, but this issue in a broader sense)
The scope of changes is larger than the patch above.
WizardBase classes use \Drupal\user\SharedTempStoreFactory which is deprecated.
I tried swapping all instances in src/Wizard for Drupal\Core\TempStore\PrivateTempStoreFactory but then found the rabbit hole continues, into src/ParamConvertor/TempStoreConverter.php, which frankly I haven't looked at enough to understand yet.
As for why I was swapping to PrivateTempStoreFactory, when the original code uses SharedTempStoreFactory....
I am not sure whether it is related or not but I have a rather huge problem with my wizard's tempstore (which led me down this path in the first place), in that I am only getting one per-wizard-per-site, it is not per-user. If I progress through the wizard as user A, then open the wizard as an anonymous user in browser B, I see user A's choices pre-populated!
Indeed this seems unsurprising because looking behind the scenes in my key_value_expire table, the storage is keyed "user.shared_tempstore.foobar.wizard" - nothing in the key to distinguish an individual user.
I am not clear whether this is a logical error / bug in the Wizard code (it should in fact always have been using private rather than shared storage); a consequence of ctools calling currently Deprecated classes (it worked at the time but some aliasing during deprecation has had unexpected results etc); a design decision / Works As Intended, whereby implementations of WizardBase are expected to handle this for themselves (but I don't really understand how they could, when the fixed key 'wizard' e.g. ->getTemporaryValue('wizard') is baked in all over FormWizardBase); or a misunderstanding on my part of how this is all meant to work...
Sorry I am rambling. To try and cut to the point:
1. the patch replaces %user.tempstore.expire% in services.yml, but this file also needs various instances of @user.shared_tempstore replacing
1. along with which there is a definite need to replace all "use"s of \Drupal\user\*\*tempstore* with those from Core. per https://www.drupal.org/node/2935639. right?
2. there is also a potential need to replace some SharedTempStore with PrivateTempStore.
I am working on a project heavily dependent on complex wizard style workflows and so far have made fairly big progress extending FormWizardBase (e.g. rather than enforcing a flow through 1, 2, 3 steps in order, mine allows dynamic "choose your own adventure" paths whereby the next/previous can be altered depending on submissions at a given step.) I worry this will bring me to a crunching halt though as I can't extend my way around it as far as I can think, I am dependent on fixing upstream, which is a new realm for me (rolling patches and so on). Hoping there are folks here who can help me help ctools :)
Comment #12
stevekeiretsu CreditAttribution: stevekeiretsu as a volunteer and commentedAttached, my first attempt at a patch, incorporating the 'required' changes in my prior comment, (but ignoring any question of change from Shared to Private).
The best I will say for this is: with these changes made, my dev site does not WSOD. No testing or guarantees beyond that ;) I cannot even suggest it will fix the WSODs of #9 and #10 as I never encountered that issue in the first place.
Comment #13
stevekeiretsu CreditAttribution: stevekeiretsu as a volunteer and commentedok, firstly, my patch above missed a few instances.
secondly, before I re-make it, could anyone explain why in getParameters() method of FormWizardBase and EntityFormWizardBase, the service names are hard-coded, thus rendering the fact I already changed them in services.yml, redundant?
Comment #14
stevekeiretsu CreditAttribution: stevekeiretsu as a volunteer and commentedRemade patch hopefully this time catching every mention of this class/service, even the (naughtily?) hard-coded ones.
Comment #15
stevekeiretsu CreditAttribution: stevekeiretsu as a volunteer and commentedComment #17
joelpittetThis looks to needs a re-roll
Comment #18
Berdirworking on it.
Comment #19
BerdirJust a bunch of trivial conflicts on uses and one service definition.
Comment #20
joelpittetThank you @Berdir I've committed this to the dev branch for the next release (minor trailing space fixed on commit)
Comment #22
manuel.adanSome issues in page manager UI / panels after this. At #3031778-15: Change panels store I explain what I found. Not clear if it is something to fix here or in contrib modules that depends on ctools.
Comment #23
Berdirthat is very unfortunate but there's not much we can do about that except possibly announce it better on the release notes, but nobody reads those anyway I guess.
Everyone has to update to the new services eventually.
Comment #24
ARRC-Drupal-Chick CreditAttribution: ARRC-Drupal-Chick commentedHaving tried to update Chaos Tools from 8.x-3.0 to either of the newer releases, I've discovered that some 'fix' or other related to how temporary storage is used is causing Drupal to crash when I attempt to update to 3.1 or 3.2.
This is the message:
TypeError: Argument 1 passed to Drupal\ctools\ParamConverter\TempstoreConverter::__construct() must be an instance of Drupal\user\SharedTempStoreFactory, instance of Drupal\Core\TempStore\SharedTempStoreFactory given in {full_path_removed}\modules\ctools\src\ParamConverter\TempstoreConverter.php on line 102
No combination of cache clearing and using update.php works (something that sometimes fixes other update issues). Once the new version code is added (replacing the entire ctools directory), no other Drupal based page will open.
Additional research shows that the recent Chaos Tools are using deprecated user tempstore.
See: User module's user.private_tempstore and user.shared_tempstore services moved to core
I have a configuration that does not allow the use of Drush (and, yes, it is unusual but has been working in production for 3 years):
I have to use the fully manual process of deleting the current directory, creating a new one from the zip file and then running update.php.
Since the one other module dependent on Chaos Tools is one we can live without, we are dropping that module and Chaos Tools.