Live feed

Entity browser and our project tests break completely with this, something here isn't correct.

Looking at the response, it has no cacheability metadata at all. $response->addCacheableDependency(CacheableMetadata::createFromRenderArray($preview)); isn't working, $preview not yet rendered at this point, the cacheability metadata is in $preview['view'] and not picked up by createFromRenderArray().

IMHO, this shouldn't rely on the rendering to set cacheability metadata on there IMHO. The controller implements and uses specific query parameters, such as view_name and view_display_id. It should IMHO always explicitly add those specific query parameters or just url.query_args to the response, otherwise there might be edge cases that might be missing them, for example a weird display that outputs something unexpected?

CSP without unsafe-inline will not allow the onload attribute, but you can use an event listener in an inline script with a nonce or hash instead.

I tested this out and it fixes the issue. Pushed to 5.4.x and 6.1.x. Thanks @joseph.garwood!

The bot says the patch does not apply but I don't see any conflict on the MR.
I rebased to see if it works better.

Automatically closed - issue fixed for 2 weeks with no activity.

I rebased to make the bot happy.

There is to this in App.js

https://git.drupalcode.org/project/jsonapi_query_builder/-/blob/1.0.x/js...

I don't know why jsonapi is hardcoded here. Especially when a URL object could be used to pop the path from the absolute URL passed in. It's also duplicated in https://git.drupalcode.org/project/jsonapi_query_builder/-/blob/1.0.x/js...

📌 Add JSON:API performance tests Active is now in, which means we have hard proof of how much even a static cache would benefit and can adjust those performance tests accordingly.

I had the same issue with the Bootstrap theme. For whatever reason, it was not finding the menu_columns component. The solution for me was to clear the cache using drush

mglaman → created an issue.

damien_vancouver → created an issue.

It looks like FormState's submit handlers should be an array when set, but I think it's possible that they're not set, like if a form doesn't define submit handlers for some reason. Maybe that's the case on your site. That said, I don't think we need the patch written this way. We can just check if getSubmitHandlers is an array first. I'll update that.

wjackson → opened merge request !2

wjackson → closed merge request !1

patbsh → opened merge request !31

mglaman → opened merge request !1

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

wjackson → opened merge request !1

mglaman → created an issue.

Automatically closed - issue fixed for 2 weeks with no activity.

For now - no.

wjackson → created an issue.

penyaskito → created an issue.

Changing title and component because it's about the UI, not about the capabilities of SDC themselves

@ressa,

I've removed the javascript aspect from this machine name type field as its just not really working right particularly with the dynamic parts of this form. This just always exposes the name field for all of them and eliminates the empty suffix that was causing unwanted space. Try the patch please and add a review.

Thanks!

I would really like to see Class added as an option here:

According to Mozilla, global attributes like class are allowed in iframe tags.

apmsooner → opened merge request !106

Automatically closed - issue fixed for 2 weeks with no activity.

Checking on any timeline updates here... currently unable to use the module/form on D11, looks like there's a fix ready to go?

Do we need more testing?

+1 RTBC for MR 58

Using PHP 8.1 on Drupal 10.4.4.

Hi, I can't reproduce this. Can you uninstall the version you have and install version 2.0.x

drush pmu simple_toasts (or uninstall it on the extend page)
composer require 'drupal/simple_toasts:2.0.x-dev@dev'
drush en simple_toasts (or enable it on the extend page)

Try that and see how it goes.

Sadly, had to uninstall this module to complete our D11 upgrade.

@lauriii has clarified his POV: there are plenty of (visual) page builders out there, that are design system-aware, that do not support this functionality. He thinks it's very important, but not a stable (1.0) blocker.

If somebody in the community wants to pick this up, we'd more than welcome it, but the XB team won't be working on this before 1.0.

I wonder if you have an invalid service definition in your site somewhere. I can't reproduce this in 10.3.x or 10.4.x on a clean install (Drupal standard profile). Do you have any custom modules installed? Or is everything well supported contrib modules?

catch → closed merge request !11168

Oh I completely missed that the cache warming was requesting the front page still (and not a JSON:API page) which still means asset aggregates get requested which could still result in cache collector fun - BUT because we log in the user before that, those caches will be warmed before we hit the front page anyway, or worst case by the front page request, so we should indeed not need two.

Committed cd5bc86 and pushed to 11.x. Thanks!

I know now that it's definitely not considered a stable (1.0 blocker).

@pdureau When you said "form element", did you mean field type + field widget?

@loopy1492 - it's very different, but 5.x is much better and it doesn't make sense to maintain such different versions. Please help me create documentation or more of an upgrade path rather than continuing with the 8.x version.

Looks like this was already completed in hook_update_8206(). Closing this ticket, but please reopen if there are still pending tasks. Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.

Thank you, @diaodiallo!

whoops, forgot this needs tests

This has been completed by @lawxen in the 3.0.x branch, closing ticket and we can open new tickets for any issues in D11.

Automatically closed - issue fixed for 2 weeks with no activity.

based on @larowlan approval

If I disable the Date Range and Smart Date fields the export works.

Also if leave these fields active and disable "Export each property selected into a separate column" the export works.

loopy1492 → created an issue.

I just made this update and pushed out a new release 3.0.6. Thanks for pointing this out!

Sure, I don't see why not. I'm not planning on working on that, but if you want to contribute something we can get that added in.

Automatically closed - issue fixed for 2 weeks with no activity.

xax, great, can someone please add this deprecated validation fix into a merge request! This prevents D10.4 and D11.1.x installs from using this module

amerie → created an issue.

https://www.drupal.org/project/drupal → is now updated and drupalorg module no longer uses the project_release_supported_versions.recommended column.

@amitaibu alternative I discussed with @ramil g, we can force the og:default in the field UI, and maybe strip out the option to select views or other ER entity reference selection handlers that are inherited? Then we create a separate OG specific handler for og_non_member_post.

For illustration purposes this is what I am talking about regarding this bug.

Before save:
→

After save:
→

D7
→

joelpittet → credited ramil g → .

I opened https://git.drupalcode.org/project/drupal/-/merge_requests/11633 to prove where a fix _could_ go but I have no idea how to solve it. Moving to the asset library system, as I think it belongs there. The problem is how theme libraries are treated special and break the idea of being a dependency

mandclu → created an issue.

Nice to see so much great people here (David, Jean, Mike, Wim).

It would be nice to add a Icon API Form Element into Drupal Core. We didn't do it last December, in order to iterate in contrib space first. But it may be relevant now.

subscribe

mglaman → opened merge request !11633

🐛 SDC CSS definition render order Active predates the changes in 10.4/11.1 but the fix might end up being similar.

yes this needs to be fixed asap , please edit the composer.json, remove D8 and D9 and ensure 10 and 11 are proscribed in composer.json for library_manager

I followed the steps outlined in the "Steps to Reproduce" section, installing the minimal profile for Drupal 11. After making the necessary modifications, I successfully received the confirmation message: "The role settings have been updated." This verifies that the changes were applied correctly and the expected functionality is working as intended.

nexusnovaz → created an issue.

Yeah, i'm running into all sorts of problems.

I had to switch back to the basic credit card pane, and even that is be a bit buggy.

This has lead to 🐛 Declare dependency on jquery_ui in composer.json Active .

claudiu.cristea → opened merge request !181

nexusnovaz → created an issue.