🇮🇹Italy @robertom

@hexabinaer does your formatter display the start and end date of the season? Because if it doesn't, setting fake dates should work around the problem

I am testing the module for a project and in my tests I set:

• Summer season: from 14/01/2025 to 18/01/2038
• Winter season: from 14/01/2025 to 18/01/2038

and with the table formatter I get

Currently there is no possibility, but it would be useful to have an option to not show the default office hours

In the screenshot, my formatter is configured to show only the opening dates... it's part of my tests, but basically it doesn't change that this method can potentially be used (if your formatter doesn't show the season date range)

In database start and end hours is created as INT(11)

  `field_opening_hours_starthours` int(11) DEFAULT NULL COMMENT 'From',
  `field_opening_hours_endhours` int(11) DEFAULT NULL COMMENT 'To',

The maximum timestamp that can be stored in an INT(11) is 2147483647 (Tue Jan 19 2038 03:14:07 GMT+0000)

if I enter "Jan 19 2038" as the season end date, in the database I see 2147468400, so the conversion does not take the timezone into account

2147468400 is:

• Mon Jan 18 2038 23:00:00 GMT+0000
• Tue Jan 19 2038 00:00:00 GMT+0100

but this could be another issue...

For infinite seasons, it would be enough to set the end date to January 18, 2038 (to avoid problems with the timezone), in this way the season will be practically always visible.

It would be useful to have a "make infinite" checkbox in the widget that automatically sets a start date in the past and an end date set to the timestamp 2147483647 when saved.

This is a sort of workaround, but I think it can work for the purpose

Attached proposed patch

robertom → created an issue.

Attached a patch without the use of ->all()['page'] for avoid warning like

Undefined array key "page"

Attached patch fixes issues

Symfony\Component\HttpFoundation\Exception\BadRequestException: Input value "page" contains a non-scalar value.

raised by the test bot

Sorry, wrong patch name...

Rerolled #179 for 8.x-1.x

Rerolled #179 for 8.x-1.x

Attached a proposed patch

robertom → created an issue.

Even with patch #21 I get some unwanted rollbacks when i run a migration group with the --group=... option.

The problem is due to the way the data is stored in the state variable. We need to add the migration id as the key of the array.

Attached a proposed patch and interdiff with #21

sorry, there is no point in checking repeatedly...

new patch attached

Hi, sorry for my bad english.

This issue is still valid.

I have many d7 to d9 migrations suffering from this because, for example, d7_taxonomy_term_entity_translation states that entity_id will be integer, but the data coming from the db returns it as a string.

The approach used in patch #4/#17 might be incorrect because, if the id is an md5, the conversion might assume it's a numeric value when it doesn't contain letters and the strict in_array check will fail.

Attached a "workaround" that enforce the type of $source_id_values as stated by $source->getIds()

Attached the proposed patch

robertom → created an issue.

Attached re-rolled patch that include changes from #55 for 4.0.2 and 4.x version

Patch 154 works well, but the part for altering metatags introduced in patch 147 is missing.

Attached the modified patch and the interdiff

Same problem also on RouterPathTranslatorSubscriber. Attached a modified patch and the interdiff

The patch in #3111456-63: Unable to resolve path on node in other language than default → seems to work fine, but RedirectPathTranslatorSubscriber does not correctly take into account the language of the selected redirect.

Attached a modified version of the patch and the interdiff

@gintass the commit for #3204475: Review access checks → isn't included in 2.0.0-beta1 version

you need to install the dev version or wait for the 2.0.0-beta2 version

Hi, thanks for this useful patch.

I need to get relative url of image style, so I've added a commit for implement chained token relationships for url.

now we can use a token like this:

[entity-type:your_image_field_name:image:style:your_image_style_name:url:relative]

I hope I wasn't wrong to directly add a commit on the issue fork

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

Attached the proposed patch

robertom → created an issue.

Reroll patch.

patch updated for branch 10.1.x-dev

it looks strange to check access before checking that link template exists

yeah, but it's the same order used in EntityListBuilder::getDefaultOperations