🇺🇸United States @maxstarkenburg

Added a link to the related change notice and indicated what version of Drupal this was "new" to (since I was wondering/confused why the module wasn't appearing on the 10.2.x site I'm looking at). Said change notice also helpfully has screenshots. Perhaps such changelog-like indications aren't supposed to be in these core module docs pages, though then I'd question the presence of the "new" descriptor too.

laura.gates → credited maxstarkenburg → .

laura.gates → credited maxstarkenburg → .

laura.gates → credited maxstarkenburg → .

No changes, just a clarification of my last revision message. I meant to write ".. where ckeditor5-stylesheets was [erroneously] using an underscore".

Fixing another place where ckeditor5-stylesheets was using a hyphen.

I was finding the same behavior, despite "Enable image uploads" being checked. Regular/non-responsive Image Styles render correctly. I tried rerolling your patch @bgronek to not reference the module's install path (see attached), after which the patch successfully applied, but rendering still wasn't resolved (there could be other variables affecting my lack of dice).

What are the recommended steps if one wants to avoid running composer update sans arguments?

Since that updates everything, it also includes directly-required contrib, and I don't want my update of core to be accompanied by the regressions I've found in the latest patch releases of stage_file_proxy and viewsreference, for example.

I know I can lock those two specific modules at specific versions, but I also don't want to have to wonder what other contrib's updates might have regressions, require time testing, etc. (whereas any regressions in core's dependencies will naturally have more eyeballs encountering them than contrib). Nor do I want to have to do manual git add -p composer.lock of course.

Seconding this request for a release, plus I added an MR because I was finding that a presumable typo in composer.json's version constraints (^8 || ^9 || 10, notice the lack of caret preceding the 10) wasn't allowing me to upgrade my site past drupal/core 10.0.0.

However, it wasn't enough to add the patch, as my composer.lock file already had the bad info (and wasn't getting updated with composer commands), so I had to manually edit the corresponding line in it too (after which composer finally let me upgrade core higher). I'd assume a new release would help avoid that problem for others as well. Thanks.

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

And now that I've figured out the right module to report it to, I see it's a duplicate, haha (of 🐛 Typo in CKEditor5 compatibility message Needs review ). Closing.

Doh, reported in wrong module! Seeing if I can't move from entity_embed to embed ...

maxstarkenburg → created an issue.

maxstarkenburg → created an issue.

maxstarkenburg → created an issue.

This patch helps improves some regressions I'm seeing between beta6 and beta7, though I'm also seeing beta7 to remove view header/footer text (configured to "Display even if view has no result"), so I think the scope of the issue might be larger.

maxstarkenburg → created an issue.

Thank you @gausarts! Wasn't expecting such a swift reply and action.

I didn't test verifying things with non-SVG or versions prior to v6, but was able to test and confirm that release 1.10 resolves my issue with class orders (as long as I retain fab or fa-brands as an additional icon class), so I was able to remove my hacky workaround.

Thanks again!

maxstarkenburg → created an issue.

I'm reproducing this error by visiting /admin/config/regional/language/detection on a D10.0.11 (php 8.1.17) site that doesn't use shield. Here's what I'm seeing instead:

The website encountered an unexpected error. Please try again later.

TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in in_array() (line 137 of core/modules/language/src/Form/NegotiationConfigureForm.php).

Drupal\language\Form\NegotiationConfigureForm->buildForm()
call_user_func_array() (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 283)
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: 580)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 163)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 74)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 692)
Drupal\Core\DrupalKernel->handle() (Line: 19)

However, I tried to reproduce on different site (9.5.11, php 8.1.24) and couldn't reproduce there (page seemed to load fine, and no dblog warnings). Haven't done a full dig into what other site differences might explain the error on the former vs. lack thereof on the latter.

I was getting this error when just trying to visit /admin/config/media/image-styles to create a new image style (don't know if other variables factored in). The patch in #2 didn't apply for me (the site's apparently on group 3.1), so I rerolled it. Thanks!

I've also run into this need, and would need it per widget and/or storage instance (e.g. some view displays that are ok to use when my paragraph allows only 1 viewsreference field (and can thus fit all its items), whereas another paragraph type with viewsreference cardinality of 2 to display them in columns might needs limits on the views displays that can "fit" in each column).

I'm seeing a variation of this phenomenon. I haven't seen it happen upon cache clear or cron run, but what I am seeing is this:

1. Block placement looks correct on prod
2. I make a DB dump of the prod database (after which block placement still looks correct on prod)
3. I import it into my local so I can run drush cex to capture other unrelated config differences that have been made directly on prod
4. I run a diff against config as committed, and see that the blocks in my blockgroup have supposedly been ...
   1. disabled
   2. moved to another region they definitely shouldn't be in (I'm guessing they're getting moved to the top-most theme region, given the other report moving things to a "Header" region, and in my case I've only seen them moved to my theme's first region, called "Alert").

Ok, MR created. I can't take much credit for the changes as they're essentially a copy of what media_bulk_upload was doing (looks like here to be quite specific).

maxstarkenburg → created an issue.

Uploading an alternative patch, using min-width: fit-content for several descendant selectors of .field--type-office-hours (instead of a hardcoded px amount for specific selects).

I also went back and forth a ton between always using display: flow-root for the office_hours table (as opposed to only at widths below 1025px). On the one hand, without overflow handling, the table still risks covering up metadata fields on the node edit page, depending on one's viewport width (though at least the two week-based widgets seem to be in collapsible <details>). On the other hand, when display: flow-root is used, (A) on some browsers and viewport widths, it might not be at all apparent the table has scrollable contents off to the right, and (B) if Chosen JS is used, the dropdowns nearer the bottom get cut off (well, they actually increase the scrollable height, but they're non-trivial to select from).

I tried to address problem A by seeing if I couldn't apply Lea Verou's scrolling shadows (well, the horizontal version), but between unreliable parent selectors and/or some non-transparent background colors, I couldn't get something working (including several attempts using higher z-index'ed pseudo-content).

I didn't open an MR yet because:

1. I'm unsure if the other match I found (in tests/fixtures/drupal7/system.php) ought to be edited as well.
2. I'm guessing other branches may need the same change, though this is my first time trying out GitLab instead of just making a patches, and it's rather late, so I'll figured that out later. 😅

maxstarkenburg → created an issue.

Following. I also found myself confused by this (and am making a video walk-through for a client, so honestly wasn't sure which button recommend (after testing, I'm going to recommend "Save and select", since "Save and insert" is ambiguous about whether it actually did anything (though it does indeed upload them too, just doesn't redirect anywhere))).

I was getting the same errors as in #2 (trying to set up media_bulk_upload 3.0.2 on core 9.5.9, having never used this module before).

The "Upload location" field was something I skipped over when configuring my bulk media config, because (a) it wasn't required, and (b) I didn't know what to put (or frankly why I should care, if it was only temporary), e.g. should it be sites/default/files, or #4's suggestion, or temporary://, or /tmp/ or ... ? (Not to mention ... will whatever I choose work both on my local and my host?) The project page's description, README, and field description text (and perhaps placeholder or default value) could stand to offer some guidance in that regard.

#5 was the first indication I saw that the media_bulk_upload_dropzonejs submodule existed. It didn't get enabled when I enabled media_bulk_upload or dropzonejs via drush. Was it supposed to have?

After I enabled media_bulk_upload_dropzonejs and populated the "Upload location", things then worked. But if enabling the submodule is required, that's another place where the project page's description and README could use some updates to help us understand how we're supposed to use this module.

But between those docs, this issue's summary, the lack of dropzonejs dependency in media_bulk_upload.info.yml, and #5, I'm confused about whether using DropZoneJS is required or just highly recommended? And if the latter, what configuration/setup allows the module to work without DropZoneJS and without also erroring ('cause I couldn't figure it out, though for my needs today, I'll just use it / enable the submodule, and move on).

@jlancaster, this doesn't address the general issue or explain how it might have gotten there in the first place, but curious if https://www.drupal.org/project/menu_item_extras → might at least help expose the field for you (since that module makes menu items fieldable, so providing "manage display" and similar forms for menus).

Trying to clarify the distinction between what was deprecated re: "raw" vs. what was not (as well remove the confusing ambiguity of reading "[raw] is still fine" after reading "[raw] should be avoided whenever possible"). From https://drupal.stackexchange.com/questions/299321/what-should-be-used-in... seems I'm not the only one who initially misinterpreted this section (at least with regard to what was deprecated).