D8 port

I've done a D8 port, I'll post in a second....

See the attached patch for a D8 version. This creates two action plugins for setting and deleting a session variable and a conditions API plugin for checking if a session key/value is set.

I'm doing a lot with the Conditions API at the moment, so I'm happy to become a maintainer of the 8.x branch if you want?

Instead of using session, should we be using the user private temp store instead? https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21TempStore...

1. +++ b/src/Plugin/Condition/SessionHasKeyValue.php
   @@ -0,0 +1,48 @@
   + * @todo: Add access callback information from Drupal 7.
   

   Is this planned for a follow-up issue? Or will that come into this patch before it lands?

2. +++ b/src/Plugin/Condition/SessionHasKeyValue.php
   @@ -0,0 +1,48 @@
   +   * Evaluate session has key/value set.
   +   *
   +   * @param $data_key
   +   * @param $data_value
   +   *
   +   * @return bool
   +   */
   +  protected function doEvaluate($data_key, $data_value) {
   

   Should this be inheritdoc? Where this is doEvaluate referenced from?

3. +++ b/src/Plugin/RulesAction/RemoveDataFromSessionAction.php
   @@ -0,0 +1,32 @@
   + * Provides a test action that sets a node title.
   

   This seems to be an incorrect comment. Copy/paste?

Here is an updated patch. In my opinion, we should keep session and not private temp store, as the private temp store is used to store heavy objects (here we just handle really small objects)

Regarding your other comments (thanks for the review btw):
#1: this was coming from a copy/paste in the rules module. I removed it
#2: yes it should be inheritdoc, as this is coming from RulesConditionBase
#3: it was indeed an incorrect comment (bad copy/paste I guess), I updated the comment

Additionnally, I have changed a little bit the event, you can now test whether a key exists or whether a session[key] has a specific value (2 different events)
I am also using the D8 way of accessing the session variable (and not $_SESSION)

Can you please review? It would be great if you can start a D8 version of this module anyway, and have this in dev or alpha. Happy to become maintainer to handle this, or you can name rjjakes as he volunteered 2 years ago - if you don't have time to do it.

Here's a few changes. Mainly addition of tests.

Hi Heddn,

Good call using $this->requestStack->getCurrentRequest(); It's better than the \Drupal::request() I wrote

Looking at the fact that all classes have the same constructors / create, it may make more sense to have an abstract parent class. But then, I don't expect to get too many new features so may not be worth it.

I saw that you created a dev version but I believe the naming convention is incorrect:
2.0.x-dev -> 8.x-2.x-dev

Should you go and create a 8.x beta or even release? Users will probably download that more than if there is 'only' a dev version

re #8: https://www.drupal.org/node/3108648 => we have real semantic versioning now.

We could add a Trait for the constructors, etc. But that has some issues on older versions of PHP. We couldn't easily have a base class, because the class inheritance between actions and conditions is entirely different. Or, rather, we could have 2 base classes that repeat each other. I went with just repeating ourselves. This module sees so little activity, and we aren't talking about all that much code... why not.

Looks like I forgot to mark this fixed.

hi
please is there any RC version with compatibility for D9 in plan?