Needs work
Project:
Drupal core
Version:
main
Component:
user system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
31 May 2013 at 10:20 UTC
Updated:
30 May 2025 at 16:02 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
fubhy commentedMaybe related: While doing so we could add a TempStoreInterface interface. Currently there is none.
Comment #2
fubhy commentedWaiting for #1825332: Introduce an AccountInterface to represent the current user
Comment #3
fubhy commentedThat other issue got commited.
Comment #4
fubhy commentedNot sure why I initially postponed this on the AccountInterface issue. It just expects a $owner string, not user object. Anyways... Here's the patch.
Comment #6
berdirComment #7
damiankloip commentedStarting 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 :)
Comment #8
damiankloip commentedComment #9
tim.plunkettNot 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
Comment #10
tim.plunkettThis encompasses all of the public methods on PrivateTempStore, but not all of them on SharedTempStore.
Comment #11
upchuk commentedAdded a new related issue.
Comment #12
tim.plunkettI 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?
Comment #13
upchuk commentedAren'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.
Comment #19
alexpottHere'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.
Comment #21
alexpottHere's some work on splitting out the interface into PrivateTempStoreInterface and SharedTempStoreInterface.
Comment #23
alexpottOne 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.
Comment #24
alexpottYeah after thinking about #23 some more I think sharing an interface between PrivateTempStore and SharedTempStore implies a swap-ability that's just not there.
Comment #26
upchuk commentedRe-rolling #24.
Comment #28
geek-merlinComment #29
geek-merlinThe patch looks straightforward to me. If we lay hands on this, i'd say let's add interfaces for the factories too.
Comment #37
needs-review-queue-bot commentedThe 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.
Comment #41
andyf commentedThanks everyone for the work on this.
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.
Comment #42
smustgrave commentedIssue summary needs to be updated please.