🇩🇪Germany @Anybody

This is an alternative approach if working with contextual filters on field values: https://www.drupal.org/project/drupal/issues/3209940 ✨ Allow contextual filters to optionally include results with NULL values for the specified field (as well as matches) Needs work

Great work all! I just created a MR from #19 and can confirm this works great and solves the issue for me.

Beside implementing tests, I'd really vote to improve the checkbox label a bit for users, because NULL is a bit too technical, I think. We should do that before the usability review, I think.

What do you think about:

• Skip this filter for empty (NULL) values
• Include results with empty (NULL) results for this contextual filter

What's more clear? Any other suggestions?

The field description could go more into (technical) ddetail, maybe?

Just ran into the same requirement and I agree it would be really useful! If the given field value is empty, it's often a requirement to ignore the contextual filter for the field. Maybe the label of the checkbox could be changed into that direction?

anybody → created an issue.

Super nice @grevil thank you! Works fine and as expected now. Please open a follow-up to reduce the confusion you described.

Next step (UX-wise) should be ✨ Inherit parent metatags as placeholder in override forms Active

I'm not currently using this anywhere, but if we get a community-tested solution RTBC'd by enough people, I'm willing to merge a fix!

@Grevil: Like just tested together I can not confirm this. Having an empty value leads to inheritance (as expected)!

Thanks, I'll check that!

Thanks! Postponed on ✨ Add: "View any unpublished [entity_type]" permission Needs work

We just ran into the same issue, this permission is definitely still missing. Anyway I agree with #17 - thanks for the patch @mkalkbrenner!!

So I'll set this RTBC for the maintainer to decide if this should be postponed or integrated already.

Perfect, thanks for the check @grevil!

@danchadwick This also works for other cases in Drupal, not just for Webform! @thomas.frobieter's example is a webform example, but adding the use-ajax class for links in Drupal also works to open the link in a modal!

See https://www.drupal.org/docs/develop/drupal-apis/ajax-api/ajax-dialog-box... →

It's just not well known, I think. And the required libraries have to be loaded on the page!

Sorry, I ddn't realize that order_report has a relation on the original order!

So this is fine, as you simply need to add a (required) relation in views from the order report to the order. That relationship can then be used to filter the view by status and everything is fine and works well!

Thank you!

anybody → created an issue.

Ok here's a new one and some tests are failing, so let's proceed again...

Failing tests look unrelated, let's open a separate issue for that.

Thank you very much @grevil! Nice finding and fix!

I'm a bit more in favour of MR!28 I have to say, looks cleaner to me. But let's see what @jacksacksick says!

Looks like a regression?

I can confirm we were not able to reproduce this, despite having ~20-30 entries in the logs showing this error. Interesting... Let's see if the log entry can tell us more in the future.

Still I think the trick from #2 is hard to find, so would be better to improve this in the module or document the workaround?

@maintainers: Could you maybe explain a bit how the module handles numeric values and if (or why not) raw values are used?
Currently this seems unusable for non-default number formattings used in the view output, as described in the example.

We'd like to help, but it would be great to have a better starting point on how and where this should be fixed and which impediments you see. Thank you!

Thank you so much for your hint @jrochate! That saved my. I created 🐛 Doesn't play nice with number formatting - should use raw values Active for further improvements, when using international number formattings (not EN)

anybody → created an issue.

FYI: I won't have the time to implement something here in the next month, but I'm happy to review a final MR that has been approved by the community.

Drupal 9 is EOL, I think we could require Drupal 10 as minimum, maybe even 10.3!

Thanks @divyansh.gupta! Great work. I think now a maintainer should decide, if all important information is given and if it's all fine!

Let's set this RTBC! :)

@thomas.frobieter can you adjust the test here in a MR? Maybe otherwise @Grevil can help? Nice chance to take a look at the tests and how simple they work.

Nice @niklp!

https://git.drupalcode.org/project/iconify_field/-/commit/0ccf3125574b0c... looks like a change worth trying! Could you prepare the MR accordingly?

@grevil this is the wrong area (the zip code input you're looking for is below the cart on /cart!)
And I can't see you selected a country in the screenshot.

Moving this to Drupal.org project ownership (2209259) as of #34 for clarification. Thanks all! :)

Confirming RTBC! 🚀

Ok, drop it!

@eleonel could you please tag a new stable release for this critical issue? Thanks!

Patch #14 does not apply anymore with latest quick_node_clone. So should we maybe close this and switch over to ✨ Support cloning of paragraphs by integrating with popular contributed clone/replicate modules Active ?

Patch from 🐛 Cloning Entities with Layout Paragraphs breaks structure and moves subparagraphs into Disabled Items RTBC does not apply anymore. So should this be a good moment maybe to finish this one? :)

@larowlan: #13 sound like this might be added to all submit buttons in Drupal 11 - which are affected by this bug by design.
What do you and the others think?

Hi and thank you very much for your helpful feedback @mdusza - may I ask, if you know and ckeditor5 project that might fit better or already provides this functionality?

Older Drupal versions had this functionality and it was really helpful for us.

I added the point from #36 / #37 to 🐛 Update YoastSEO JS to recent version Needs work FYI

As written in 🐛 The page freezes while the Real-Time SEO module runs script Needs work this should also include removing jQuery dependencies (using vanilla JS instead) and ensuring there's nothing blocking in JS like it was in the past.

@kul.pratap I thought the same, but there is: https://git.drupalcode.org/issue/office_hours-3497658/-/blob/3497658-fie...

We should first find out why it fixes the issue - Our installation was fresh so it's not an upgrade path thing I think... @johnv should decide about a hotfix, please.

Sorry I created the issue fork because I thought I found the reason, but didn't :(

Seems this caused a regression: 🐛 FieldException: Attempted to create, modify or delete an instance of field with name field_office_hours on entity type node when the field storage does not exist Active

Hi @johnv thank you! In our case that's definitely not the point. The database is the same as in Drupal 10 (MariaDB). And all other modules are working fine. So there must be a different reason in code here, I think.

I guess they choose SQLlite for demo installations as it comes with PHP and doesn't need additional configuration. But should be unrelated for sure.

Thanks @divyansh.gupta - really nice and helpful additions. I left two comments, maybe a maintainer could also have a look for final review afterwards. Thank you! Really nice!

anybody → created an issue.

Thanks @thomas.frobieter for taking over!! @danchadwick should you have any further questions, feel free to reach out! :)

@kul.pratap any ideas? Otherwise let's leave this open to anyone who has one.

@cilefen thanks for your quick reaction. That's really strange.

We use a couple of contrib modules, but none that affects this form.
Debugging this in ValidKeysConstraintValidator shows that the value that's being checked is:

[
  temporary => string (6) "../tmp"
]

This is the related settings.php entry, which looks fine to me:

// Temp directory path:
$settings["file_temp_path"] = "../tmp";

In the settings UI the value looks like this:

Temporary directory
../tmp
A local file system path where temporary files will be stored. This directory should not be accessible over the web. This must be changed in settings.php.

This is the backtrace:

Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateConstraints() (Line: 154)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode() (Line: 164)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode() (Line: 106)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validate() (Line: 93)
Drupal\Core\TypedData\Validation\RecursiveValidator->validate() (Line: 132)
Drupal\Core\TypedData\TypedData->validate() (Line: 209)
Drupal\Core\Form\ConfigFormBase->validateForm()
call_user_func_array() (Line: 82)
Drupal\Core\Form\FormValidator->executeValidateHandlers() (Line: 274)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 118)
Drupal\Core\Form\FormValidator->validateForm() (Line: 585)
Drupal\Core\Form\FormBuilder->processForm() (Line: 321)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 50)
Drupal\ban\BanMiddleware->handle() (Line: 96)
Drupal\crowdsec\Middleware->handle() (Line: 263)
Drupal\shield\ShieldMiddleware->bypass() (Line: 162)
Drupal\shield\ShieldMiddleware->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 49)
Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Honestly, I have no idea so far...

@catch: Sorry, not yet, but when possible I'll provide further information here, of course! Thank you!

Thank you very very much @jan kellermann! Great work once again!

We're also using radix + subtheme, perhaps that's related? (or not...)

Thanks @doxigo - I totally agree and I think it should primarily be a learning for the future to use the semantic release rules to let people know about the risk of updates / upgrades (once stable). Thank you so much once again, you're doing a great job and we're really thankful!

I think this issue could be kept open for 2w for information or so and then be set fixed?

Thanks for the reply @jan kellermann - I mostly opened this issue as note to myself to check this more in depth (asap - but very busy still).

So anyone feel free to propose changes here or wait for me :)

@danchadwick yes for sure, I or @thomas.frobieter will report back here, just a lot of work...

Same issue on all Drupal 11 projects, while Drupal 10 projects work fine. So I guess it's a Drupal 11 issue?

anybody → created an issue.

The patch in #3 fixes the issue for Drupal 11 - I'm just not sure, how backwards-compatible it is.

anybody → created an issue.

Hi and thank you so much @kingdutch for taking the time for this project! We've been waiting years for this to be fixed and never used the project because of the broken state of this issue.

Reading the comments and the MR, I think we should open a follow-up to also fix the JS-side of this issue.
The root cause here is blocking JavaScript and I think we might also want to remove jQuery?

The new option gives us the opportunity to disable the auto-refresh and makes the module usable again, but to have the functionality fixed, the JS needs to be corrected.

Do you agree? Should we open a follow-up for replacing jQuery by Vanilla JS and remove this blocking implementation combined?

@danchadwick thanks!
I think Drupal (and modules /themes) stick to semantic versioning https://semver.org typically:

The three types of versions are:

• Major versions contain breaking changes.
• Minor versions add new features or deprecate existing features without breaking changes.
• Patch versions fix defects or optimize existing features without breaking changes.

Version numbers are presented Major.Minor.Patch, for example, 3.2.1.

I'd vote to do it like that, once a stable version has been released, because I think stability is more important than new features or even bugfixes. Release notes are important, but still risky.

But that's just my 2 cents and experience. (Not meant to criticise anyone! You're doing great things here!) :)

Hi @danchadwick thanks - i forwarded that to @thomas.frobieter - we'll check that tomorrow.
Thank you so much for your impressive work on radix!

Once radix has a stable release, such breaking changes will be made in major releases, I guess?

Maybe this is a good novice job, if a novice reads into the README or the code and adds the #description using the Form API for this settings form?

anybody → created an issue. See original summary → .

@avpaderno what can we do? Move this over to the Drupal.org project maintainership issues?

@Grevil could you review and fix this maybe?

I can confirm the settings page is entirely broken with Drupal 11!

anybody → created an issue.

Broken with D11

Here's a similar situation and fix: 🐛 The "file_validate_extensions" Plugin Has Been Deprecated in 10.2.x Active

anybody → created an issue.

anybody → created an issue.

joachim namyslo → credited anybody → .

joachim namyslo → credited anybody → .

joachim namyslo → credited anybody → .

anybody → created an issue.

joachim namyslo → credited anybody → .

@misterdidi thank you!

Regarding

Static call instead of dependency injection in EntityController.php : In getEntity() method, \Drupal::request() was called. Since this method is called from a route subscriber, the request can be passed as an input parameter to prevent the static call.

did you check that the change on getEntity() parameters is backwards compatible? If yes, this LGTM!

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

@cb could you maybe ping a maintainer?