eca_cache Lifetime until expiry improvements

Created on 7 November 2024, 4 months ago

Problem/Motivation

I have two issues with the current implementation of the actions eca_cache_write and eca_raw_cache_write:

  1. The label says "Lifetime until expiry", which I would interpret as the number of seconds before this cache key will expire, but instead this will be the time of expiration itself (the unix timestamp). I think its easier/better to allow site builders entering the amount of seconds the cache they are setting will stay valid, unless we fix the field label & description and...
  2. ...we allow them to calculate the validity-ending timestamp in the ECA model itself, eg. with eca_tamper Math actions (adding a contrib dependency) to add the wanted validity seconds to the [current-date:raw] value in a new token, but writing a token is not allowed there.

I tried adding $expire = (int) $this->tokenService->getOrReplace($expire); in web/modules/contrib/eca/modules/cache/src/Plugin/Action/CacheWrite.php:L54 (or using the intval() function, but I'm getting TypeError: Unsupported operand types or
[warning] Object of class Drupal\eca\Plugin\DataType\DataTransferObject could not be converted to int CacheWrite.php:55 errors/warnings when running the action 🙁

Can anybody help with the MR? 🙏🏻

Feature request
Status

Active

Version

2.0

Component

Code

Created by

🇮🇹Italy kopeboy Milan

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @kopeboy
  • 🇩🇪Germany jurgenhaas Gottmadingen

    Thanks for reporting this. I think, we should keep the functionality and just fix the labels, as they are certainly incorrect right now. The reason for this, it would then be in line with what the cache interface of Drupal really does. And that's what ECA utilizes in the background. For details see documentation of \Drupal\Core\Cache\CacheBackendInterface::set.

    And yes, we should add token support for the expire field but also for the tags field.

    If you wanted to start with an issue fork and get your code changes into it, we can easily take that as a starting point and improve it together.

    But feature requests need to go into the 2.1.x branch.

  • Assigned to jurgenhaas
  • 🇩🇪Germany jurgenhaas Gottmadingen
Production build 0.71.5 2024