Allow modules to influence the IPE tempstore ID

Awesome! I hope this gives Panelizer what it needs to reduce its TempStore issues and complexity.

My only review after a first pass is that we'll need API docs for this, so panels_ipe.api.php will need an update.

Some quick review:

1. +++ b/panels_ipe/panels_ipe.api.php
   @@ -26,3 +26,22 @@ function hook_panels_ipe_panels_display_presave(PanelsDisplayVariant $panels_dis
   +  if ($panels_display->getBuilder()->getPluginId() == 'panelizer') {
   +    $id = 'panelizer';
   +  }
   

   This example is totally contrived. Since we're dealing with the IPE, the builder plugin will always be 'ipe' :-)

   It isn't super important, because this is an example that won't actually run, but it'd be nice to something more realistic

2. +++ b/panels_ipe/src/TempStoreTrait.php
   @@ -0,0 +1,51 @@
   +trait TempStoreTrait {
   

   I'm not crazy about this being a trait. By using a trait, we're copying a method to multiple places, rather than calling the same method in multiple places. If something else (outside of IPE) wants to get the right tempstore id, then the API is using the trait on one of it's classes, which isn't ideal.

   I think there should probably be some service that has this method lives on which is called from everywhere than needs to get the tempstore id.

Anyone have feedback on dsnopek's feedback in #10?

I've given feedback in #2793841: Properly integrate with Panels IPE as well, which would need to be addressed to validate that this hook is necessary. Long story short, Panelizer shouldn't have to implement a hook to alter the TempStore ID if Panelizer is originally setting the TempStore ID. Altering data that you set doesn't make sense to me.

Reroll of #9 for the pending Beta6 release.

RTBC given it's already in Lightning.

The only issue that relies on this functionality, #2793841: Properly integrate with Panels IPE, has unaddressed feedback from myself and @dsopek from over six months ago.

My team ran into a problem where the entity context would get lost later in the request, and found that the only fix was to cache the modified temp store ID after the first change. This is a fairly simple caching change that shouldn't affect current users, but I'd like to get other eyes/testers on it. I've attached "panels-cache-tempstore-id.patch", which you should be able to apply directly over your existing patched Panels installation (if already using the last patch in your build).

I'm guessing my use of drupal_static() broke unit tests. I'll move this back to RTBC and hide the patches from #17, don't want to hold up the issue. I'll file a follow up when this is committed.

Hi, is this going to be merged?
Just tested with custom module, hook works. Tempstore ID can be altered.

+1 for @dsnopek comment about trait.

Created a new patch, there was a syntax error in the previous one.

And another one, a "use" statement for the new trait was missing.

This patch is no longer needed when using using the 8.x-4.x branches of Panels and Panelizer, and the Lightning distribution no longer patches those modules. How are current users using the patches from this issue? What issues does it solve in 8.x-4.x? We'll probably want to re-write the issue summary if the hook is still useful.

Marked as "Needs Review" to test the patch from #27.

The patch is still required for panelizer on multilingual sites - #2778565: Multilingual support for Panelizer. Otherwise, temporary changes made on one language of an entity are shown on all languages without overrides.

Here's a straight reroll of #27 against panels 8.x-4.4

I've attached a patch, which applies against panels 8.x- 4.6 (without test).

No response to #28
I'm closing this as not needed.