🇸🇪Sweden @erik.erskine

First attempt...

erik.erskine → created an issue.

Do you mean something like this?

abstract class GlobalVariable {
  protected $value;

  abstract function prepareValue();

  function getValue() {
    if (empty($this->value)) {
      $this->prepareValue();
    }
    return $this->value;
  }

}

class MyVariable extends GlobalVariable {

  function prepareValue() {
    $this->value = new StringVariableValue('foo');
    $this->value->addCacheableDependency($bar);
  }

}

I suggest adding a protected method, prepareValue(), to the base plugin class, which will return an initiated cacheable string object instance.

Hi @voleger. I don't quite understand this suggestion. What would be the difference between prepareValue() and getValue()?

erik.erskine → changed the visibility of the branch 3447272-add-cache-metadata to active.

erik.erskine → changed the visibility of the branch 3447272-add-cache-metadata to hidden.

erik.erskine → changed the visibility of the branch 3447272-add-cache-metadata to hidden.

erik.erskine → changed the visibility of the branch 3447272-add-cache-metadata to hidden.

Needs review.

erik.erskine → created an issue.

The approach in #10 is probably the right way: let the field formatter deal with the NULL end date and leave the low level formatter service alone.

I'd prefer this because there some debate on what a null end value actually means. It could mean a single value, but it could also mean an unbounded range (from 1/1/2024 onwards). That kind of metadata would need to be obtained from a setting somewhere, either a field setting or a future setting for this formatter. Either way, the low level formatter wouldn't know.

Worth looking at in the context of #3445445 and work done to support single-value datetime and timestamp fields. Handling optional end dates is a relatively minor extension of that.

erik.erskine → changed the visibility of the branch support-non-range-fields-3445445 to active.

erik.erskine → changed the visibility of the branch support-non-range-fields-3445445 to hidden.

erik.erskine → created an issue.

Tentatively marking this as outdated, because there was never an upgrade path from version 1 (dev release only) to version 2.

If anyone comes across this on a format created with version 2.x please reopen this issue.

It has never been possible to automatically "upgrade" a format from v1 to v2. In v1 there were separate patterns dates vs date+times, whereas in v2 these are combined. Any attempt to merge these needs manual intervention. At this point it becomes just as easy to recreate them from scratch.

This is one of the reasons there was never a stable 1.x release - only ever a dev release.

Interesting suggestion. This is going to need test coverage before anything else.

One thing to bear in mind: introducing the notion of "current year" to the display makes this time-sensitive. That has implications for cacheability. For example, if we reduce "12th - 14th February 2024" to "12th - 14th February", the output is now only valid till the end of 2024.

2.1.0 is now compatible with Drupal 11.

Leaving this issue open for now in case the bot suggests anything else.

Both of these features are now part of 2.1.0.

I think this would be best served by a completely new formatter and therefore outside the scope of this module.

Maybe https://www.drupal.org/project/datetime_extras → would be a good candidate?

This error happens when the formatter is passed a non-existent config entity ID, as described in #8.

I looked at how the core date formatter handles this situation. If the format doesn't exist or is invalid, a fallback date format is used. This `fallback` format is included as part of the module's default configuration and locked.

So it would make sense for this module to behave the same way. Added to 2.1.0.

Fixed in 2.1.0

Thanks :)

Fixed in 2.1.0.

Thanks for your contribution. This feature has now been added to the latest release, though with a slightly different patch. If you are using this patch you will need to remove it and then reconfigure the compact date format entities.

Patch that does what https://www.drupal.org/node/3000490 → suggests.

erik.erskine → created an issue.

Here's a rudimentary check that bails out if $routeMatch->getRouteName() is null.

erik.erskine → created an issue.

We have a use case to put a node into an archived state, allow subsequent drafts to be made, and compare those revisions with the archived revision.

The current behaviour - in `EntityOperations.php` - will always update the default revision if the previous revision was unpublished, regardless of what the moderation state's "default revision" property is set to:

$update_default_revision = $entity->isNew()
  || $current_state->isDefaultRevisionState()
  || !$this->moderationInfo->isDefaultRevisionPublished($entity);

The third condition here is very broad. It covers the "only ever been draft" use case, but not the "archived, then draft" use case.

Here is a proposed change that will update default revision in the following circumstances:

• the entity is new (same as now)
• the moderation state dictates the revision should become the default (same as now)
• the previous revision was the default AND the state does not change

Patch/MR done to get things started.

erik.erskine → made their first commit to this issue’s fork.

erik.erskine → created an issue.