User's temp stores has been moved to core for 8.5.x

@jian he it was fixed today.

Seems like this should probably followed up on since I ran into this today...

Does the patch fix the issue @travisc?

@tecreasey i'm getting the same issue. it just started for me yesterday. please let me know if you find out anything.

I 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 :)

Attached, 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.

ok, 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?

Remade patch hopefully this time catching every mention of this class/service, even the (naughtily?) hard-coded ones.

This looks to needs a re-roll

working on it.

Just a bunch of trivial conflicts on uses and one service definition.

Thank you @Berdir I've committed this to the dev branch for the next release (minor trailing space fixed on commit)

Some 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.

that 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.

Having 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):

• Windows 10 (or Server 2012 R2)
• Apache 2.4.33 64bit
• PHP 7.2.5 64bit
• Drupal 8.6.10
• MS SQL Server 2012 and 2017

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.