Patch #33 also works on the v2 branch
The issue fork is based on patch #27
Patch #33 and #27 have a different approach and the difference can be seen on comment #32
To sum up: with patch #33 the hreflang information can be filled in the "global" section of metatag and will be valid for the whole site, without having to fill in the information for the main sections of the various entities
Rebased issue fork on top of 8.x-1.x
@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