🇩🇰Denmark @kasperg

@drunken monkey: Sorry about not getting back to you sooner. The patch required Search API 1.33, our related project is still on 1.31.

In any case: I have tested the patch and it looks good to me.

I have:
- Created a view of an index with a field based on a datetime field
- Configured the view to show entities where the field has a value greater than now
- Configured the view to use the new tag and time based caching plugin with 5 minutes cache lifetime
- Rendered the view to fill the cache
- Created a new entity where the datetime field is 3 minutes in the future
- Rerendered the view to see that the new entity shows up. This should show that tag based caching still works.
- Waited 10 minutes to ensure that the cache lifetime should be exceeded
- Rerendered the view to see that the new entity no longer shows up. This should show that time based caching also works.

I have tried to create a merge request for the change with an attempt to reset the static cache on save. I thought that this would address kernel tests breaking or other scenarios where the same entity is saved multiple times in the same request. Alas that did not prove to be the case.

I based the merge request on the work in #2. It still applies, had the original feedback from Berdir and because I could not tell what the intention between this and the changes in #7 + #8 actually are.

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

> The MR doesn't correctly account included and excluded dates.

I tested the updated MR by creating a weekly event over a year and excluding 11 of the 12 months. This resulted in removal of the expected events while the others were left untouched.

Thanks for the update and your work. I will look into your changes.

However, hearing from more potential users would of course be great.

I would like to see this feature as well.

[...] this still needs tests. Shouldn’t be too hard, though, using the existing ViewsDisplayCachingTest. [...] please use patches instead of issue forks for development in this project [...]

I am unsure what the status of this is. The issue mentioned has been fixed and drupal.org now no longer recommends patches.

In any case here is a patch which contains the change from the original merge request with a new Views cache plugin support both time and cache tags and a first stab at extending ViewsDisplayCachingTest to include a test for this plugin.

I can change it to a merge request if needed.

In case someone is interested I have added support for configuring whether to disable the late runtime processor when running CLI commands in ✨ Make late runtime processor compatible with drush Fixed .

I have added a merge request with a first stab at implementing this.

kasperg → changed the visibility of the branch 3462078-disable-late-runtime to hidden.

kasperg → created an issue.

I have created a merge request which should address the issue.

I can recreate a situation where the error message above is shown on SimplyTest.me:

- Spawn a new site with Recurring Events
- Disable "Daily events" for "Enabled Recur Field Types" on /admin/structure/events/series/settings
- Create a new event series of type. Any type and data should do.
- See that an error message is shown "Warning: Array to string conversion in Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema::castValue() (line 2573 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php)"

kasperg → created an issue.

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

kasperg → created an issue.

Thanks for the quick feedback.

I have added a merge request with an implementation which uses ClassResolver. Since ClassResolver was introduced in Drupal 10.2 and I created the original merge request for a project which is still on 10.1 I opted for creating a separate merge request for this version.

If we go for this version we need to update the documentation as well as the version requirements for the module.

kasperg → changed the visibility of the branch 3426366-callable-worker-callbacks-10.2 to active.

kasperg → changed the visibility of the branch 3426366-callable-worker-callbacks-10.2 to hidden.

kasperg → created an issue.

kasperg → created an issue.

@endless_wanderer: Thanks for taking the time to take a look at this.

Currently I have the luxury of being able to reinstall our project frequently and the new fields are added here as expected. Given your findings I assume that something needs to be done to add this support to running systems. I expect this to involve an update hook of some kind.

If someone can point me in the right direction I am willing to take another look at this.

The problem seems to be a mixup of form entry names.

I have created a merge request to try to address this.

kasperg → created an issue.

It is worth noting that the Scheduler configuration option "Change creation time to match the scheduled publish time" (publish_touch) will not work with event series. It will throw a hard error during cron when an event is to be published.

The option requires a setCreatedTime() method being available on the scheduled entity. Event series do not provide one at the moment. As I see it there is currently no way to prevent this option from being offered on certain entity types.

I took a stab at implementing support for Scheduler for event series.

I implemented support directly within the main Recurring Events module like it is the case for the integration with Migrate, Views and Fullcalendar. Another approach would be to add a new submodule like group_recurring_events_series which integrates with the Group module. I ended up with this approach as the amount and complexity of the integration is quite limited.

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

In case anyone stumbles upon this I encountered an error when running the database update when going from 2.0.0-rc16 to 2.0.0.

>  [error]  Exception thrown while performing a schema update. SQLSTATE[01000]: Warning: 1265 Data truncated for column 'uid' at row 1: ALTER TABLE "eventseries_field_revision" CHANGE "uid" "uid" INT unsigned NOT NULL COMMENT 'The ID of the target entity.'; Array
> (
> )
>
>  [error]  Update failed: recurring_events_update_91002

It is not important to me at this point but it may be relevant for others upgrading.

kasperg → created an issue.

kasperg → created an issue.

I have provided a merge request based on a simple search/replace of return values.

This fixed the issue in my situation.

kasperg → created an issue.

kasperg → created an issue.

I have created an issue fork which provides a temporary workaround for avoiding the visible UI error.

Instead of checking for hash equality in the access check it is moved to the controller.

Since this is a workaround instead of a fix I have not created a merge request.

I am experiencing the same issue as originally reported.

The consequences of this situation are now hitting administrative users due to a change in Drupal 10.1 where JavaScript errors are now shown in the UI → .

kasperg → created an issue.

kasperg → created an issue.

Patch from #3 has been merged and included in release 2.0.0-beta3.

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

As mentioned by ras-ben this was resolved in release 2.0.0-beta2.

I made a separate attempt to see what would be possible if you are working with simple textareas instead of trying to hack into the textarea + summary.

I have pushed some code to implement this.

I do not know whether is it something that is ready for review as I would normally use that status but some feedback on both approach and solution would be welcome.

The textarea with summary field is not that easy to work with/extend and it shows in the result.

kasperg → created an issue.

I have tried to fix this by reworking our detection of content forms based on interfaces.

kasperg → created an issue.

I have updated the regular expression to support unicode characters.

With this change the following taxonomy terms are suggested in the above example: ø, vand, landområde, kontinent, holm. Here "Ø" is present and none of the words are misspelled.

kasperg → created an issue.

TR, you are right. Sorry about the confusion.

Drupal was not properly bootstrapped so PHP could not autoload the specified interface names. That is why the error occurred.

kasperg → created an issue.

This is a variation of issue #3343816 🐛 Specification includes disabled resources Needs review .

I think my suggested change there provides a simpler approach to address the problem by only filtering once. The patch in #2 includes a similar filter as well as filtering in two other locations in the module. The latter should not be necessary.

I have opened a merge request which filters away disabled REST resources.

As far as I can tell RestInspectionTrait::getResourceConfigs() is the sole place where the module loads REST resource configuration. Consequently it should be the only place where we need to do any filtering.

This should also fix issue #3277858 🐛 Disabled Content Rest API throws exception on REST Specification page Needs work .

kasperg → created an issue.

I'll reopen this issue to indicate that there is a potential fix for this.

This issue has been closed, potentially waiting for #2732429 to be resolved.

I took a stab at resolving the initial issue and have provided the related changes needed for the FAQ field module in a merge request here.

I ran into this issue as well with the FAQ field module. As mentioned there the current approach which is based on extending from the TextItemBase class would require a rebuild of the module.

An alternate approach would be to use an interface which fields could implement and provide a way to return formatted text content. I created a issue fork with an initial implementation of of such a EditorFieldItemInterface. Things are quite primitive but if other people like this approach it might provide a way forward.

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

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