Currently, the TempStore implementation resides in the user module. I can see why the factory was placed there (it assumes that there is a global user as it tries to fall back to the global user id if no owner has been definide explicitly). However, in the long run, I think it makes sense to move it to Drupal\Core.

At some point we can probably even inject our refactored session into the factory and retrieve the user id from that, completely untying it from the user module.

Issue fork drupal-2008884

Command icon 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:

Comments

fubhy’s picture

Maybe related: While doing so we could add a TempStoreInterface interface. Currently there is none.

fubhy’s picture

fubhy’s picture

Assigned: Unassigned » fubhy
Status: Postponed » Active

That other issue got commited.

fubhy’s picture

Status: Active » Needs review
StatusFileSize
new34.6 KB

Not sure why I initially postponed this on the AccountInterface issue. It just expects a $owner string, not user object. Anyways... Here's the patch.

Status: Needs review » Needs work

The last submitted patch, 2008884-4.patch, failed testing.

berdir’s picture

Component: entity system » user system
Issue summary: View changes
damiankloip’s picture

Status: Needs work » Needs review
StatusFileSize
new24.47 KB

Starting again, it's been a while.

It's quite funny that it was already living in core.services.yml when the class was Drupal\user\tempStore :)

damiankloip’s picture

Assigned: fubhy » Unassigned
tim.plunkett’s picture

Not sure about moving it anymore, but after #2421263: Potential data loss: concurrent (i.e. by different users) node edits leak through preview we desperately need an interface

tim.plunkett’s picture

StatusFileSize
new6.38 KB

This encompasses all of the public methods on PrivateTempStore, but not all of them on SharedTempStore.

upchuk’s picture

tim.plunkett’s picture

Title: Move TempStore (and eventually TempStoreFactory) to Drupal\Core and remove the user module dependency » Provide an interface for TempStore implementations
StatusFileSize
new11.15 KB
new6.29 KB

I don't know if we still need to move this to Drupal\Core, but we absolutely need an interface.

What about setIfNotExists()? Shouldn't that be on the interface too?

upchuk’s picture

+++ b/core/modules/user/src/TempStoreInterface.php
@@ -0,0 +1,100 @@
+  public function setIfOwner($key, $value);

Aren't "ifOwner" types of getter/setters redundant for the PrivateTempStore implementation? They have their place on the shared, but on private there is only get/delete/set. It's always assumed to be for the owner. Maybe we can stick with get/set and have a boolean parameter that specifies whether to get only for the owner. The shared implementation will then have the choice while the private implementation won't.

Crell queued 12: 2008884-tempstore-12.patch for re-testing.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

alexpott’s picture

StatusFileSize
new9.91 KB

Here's a re-roll on top of #2935617: Move User module's temp stores to core - unlike #12 I didn't introduce a protected getOwner on SharedTempStore because it is not necessary to introduce the interface. I agree with the patch - all services should have interfaces and things should be typehinted to an interface as this makes swap-ability a reality and not a pipe-dream. One problem though is now that we've used concretes changing the typehints to interfaces is a API break and disruptive where the move to from user to core was not.

Looking at the interface, the PrivateTempStore gets a few new methods deleteIfOwner, setIfOwner and getIfOwner and also the Private and Shared tempstore's get the same interface. I'm not sure this is a good idea because it implies that they are swappable when they are not. I think we should have PrivateTempStoreInterface and a SharedTempStoreInterface (maybe they both extend from a TempStoreInterface). I will work on a patch to implement that next.

Status: Needs review » Needs work

The last submitted patch, 19: 2008884-19.patch, failed testing. View results

alexpott’s picture

Version: 8.4.x-dev » 8.5.x-dev
Status: Needs work » Needs review
StatusFileSize
new13.07 KB
new17.05 KB

Here's some work on splitting out the interface into PrivateTempStoreInterface and SharedTempStoreInterface.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

alexpott’s picture

One thought I have is should we bother with TempStoreInterface. I don't think that there is a use-case for treating temp stores generically. Private and Shared tempstores have different use cases and should not be swapped around. Therefore the only reason for TempStoreInterface to exist is to reduce code duplication but in reality it creates an extra level which implies interoperability which I don't think it real.

alexpott’s picture

StatusFileSize
new5.96 KB
new18.43 KB

Yeah after thinking about #23 some more I think sharing an interface between PrivateTempStore and SharedTempStore implies a swap-ability that's just not there.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

upchuk’s picture

StatusFileSize
new18.46 KB

Re-rolling #24.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

geek-merlin’s picture

geek-merlin’s picture

The patch looks straightforward to me. If we lay hands on this, i'd say let's add interfaces for the factories too.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new144 bytes

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

andyf made their first commit to this issue’s fork.

andyf’s picture

Status: Needs work » Needs review

Thanks everyone for the work on this.

If we lay hands on this, i'd say let's add interfaces for the factories too.

That's actually what I was looking for. Kinda minor, but on a site with Domain Access I'd like to make the Views UI domain-aware and was hoping to decorate the shared temp store factory, but I can't do that because there's no interface. (No great shakes, I can extend and override, but still...)

I've moved #26 to an MR and added factory interfaces.

  • I didn't add type declarations to the new interfaces because of the existing implementations. I don't think these classes are covered by the BC policy, but I didn't want to make life hard for anyone extending them nonetheless;
  • I didn't update existing type declarations that reference the concrete temp store implementations, again for abundance-of-caution BC reasons.
smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update

Issue summary needs to be updated please.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.