🇺🇸United States @texas-bronius

With the "add cid" patch in #15 I see the erroneous cid in my case is entity_view:block:****_breadcrumbs:[languages:language_interface]=en:[theme]=*****:[user.permissions]=is-admin. I updated the menu_breadcrumbs to latest 2.0.x-dev, and the message appears to have gone away. If I get to narrow down which of the latest dev commits actually fixed it, I'll update this comment.

Also hoping to track this one down. The author of 🐛 VariationCache needs to be more defensive about cache context manipulation to avoid broken redirects Fixed says:

...if a longstanding bugfix ( 📌 Cacheability information from route access checker access results are ignored by dynamic_page_cache Needs review ) gets in we might all of a sudden see bug reports and perhaps even security issues...

So looks like it's come to fruition? Thanks for the tip above about finding the potentially offending module's name in the stack. In my case I guess it's either `url.path` or `route.menu_active_trails`. Will update if I figure something out :)

Dropping breadcrumbs for anyone else who comes across this. I had tried walking the debugger, tried patching (tho I never confirmed root cause first), and of course tried `{key}->deleteAll()` to no avail; Kept getting the message "There was a problem getting update information. Try again later."

Finally, I disabled the core module `update` and re-enabled it, et voila it works again! I don't know what i had done to get two of my three related sites into this state, but this, in combination with the patch in #51 unstuck the two stuck ones. (One remained "stuck" like this even after pm-uninstall/pm-enable, then I added the patch, repeated, et voila, to too is unstuck)

#14 and #8 helps to validate it.

One major difference between the two Drupal Site Status Dashboard modules is complexity and capability: DRD seems to be able to do a whole lot, while Status Dashboard looks focused on basics like "installed modules, available updates, core version." DRD is also potentially quite complex and was, honestly, a bit of a walk of faith to set up, whereas Status Dashboard was so so so simple out of the box.

I don't think Status Dashboard provides remote watchdog/dblog but DRD does. Also, DRD provides literally the `/admin/reports/status` page of info like php, mysql, and core versions, warnings, errors, and module-specific warnings, but Status Dashboard does not appear to.

texas-bronius → created an issue.

Looks like one big difference between these two is that DRD Dashboard pulls from client agent sites (see https://www.drupal.org/docs/contributed-modules/drupal-remote-dashboard/... → ) whereas Status Dashboard clients push up to Dashboard. I think security and network configuration complexity might be a differentiating consideration for some users who implement one of these modules: How many individual client firewalls may need to be adjusted?

texas-bronius → created an issue.

@ronimh - You've stumbled upon the most irksome of irksome things: `./sites/default/` itself needs write/execute permissions. Tip: You can `ls -ld ./sites/default` to see folder permissions (without worrying cluttering with files within)

(sorry @drump - I d.o login had me redirected to the wrong comment to reply to ¯\_(ツ)_/¯)

@drump - You've stumbled upon the most irksome of irksome things: `./sites/default/` itself needs write/execute permissions. Tip: You can `ls -ld ./sites/default` to see folder permissions (without worrying cluttering with files within)

texas-bronius → created an issue.

texas-bronius → created an issue.

Please consider the patch in #3 based on @jerrace #2 above. It applies locally and fixes the problem exhibited for me.

Note: I could not could not could not initially get either of these patches to load until I deleted `patches.lock.json` and tried again. Phew!

        "patches": {
            ...
            "drupal/entity_copy_reference": {
                "Edit Menu WSOD": "https://www.drupal.org/files/issues/2024-02-09/3347826-3-entity_copy_reference-fix-entity_alter.patch"
            }
        }

Thank you @jerrac. I am having some kind of issue with local patches, so I will try a file fetch. At the same time, I simplified your patch down to just this issue's original intent (as I understand, your c/p patch here addresses something else you were doing for your environment).

How I tested it:
* Visit /admin/structure/menu

With the patch: See menu edit.

Without the patch: WSOD and the following in

texas-bronius → created an issue.

texas-bronius → created an issue.

#13 is a great technique. But I had trouble with an Excel macro document (.xlsm). Following #13 revealed I needed one of:

application/vnd.ms-excel.addin.macroEnabled.12
application/vnd.ms-excel.sheet.binary.macroEnabled.12
application/vnd.ms-excel.sheet.macroEnabled.12
application/vnd.ms-excel.template.macroEnabled.12

but that was not enough. Once I also added

application/octet-stream

my test xlsm file finally uploaded successfully.

laura.gates → credited texas-bronius → .

I'm going to post this just in case it might help someone else.

Ah yes thank you! Whereas the linked official page suggests a copy/paste-able <code>core-recommended</code> only, in our case it was indeed necessary to include all three <code>composer require 'drupal/core-recommended:^10' 'drupal/core-composer-scaffold:^10' 'drupal/core-project-message:^10' --update-with-dependencies --no-update</code>.

Thanks for writing that here, @wxman :)

Echoing @bwoods in #18 the instructions given in https://www.drupal.org/project/upgrade_status → read:
composer require drupal/csv_serialization:^2.0 || ^3.0
whereas actually we need the quotes like:
composer require 'drupal/csv_serialization:^2.0 || ^3.0'
or composer.json will not be updated as you'd expect.
Further, if you're already on 2.1, you shouldn't specify just 2.0 but ^2.1 || ^3.0 I think. Maybe the best move is less specific, since we don't yet _know_ what the 3.x version will be at the time of finally pulling the trigger: ^2.1 || ^3. Is this message dictated by this module or something else?

The suggested patch (explained in Proposed Resolution) worked for me, too. This D9 site on php 7.4 is being run on php 8.1.22 (8.0.0 removed the legacy param order, per changelog on php.net; info thanks to this smart guy)

This is also problematic in the case of the Stripe element being hidden, too. We have "[x] Use my current card on-file" and "[ ] Use new payment" selectors that show/hide the Stripe element form when "use current" is selected based on a #states :visibility on the 'stripe' form element.

In our case, I was able to prevent the Stripe form submit by checking parent visibility:

 function onFormSubmit(e) {
   var $form = $(e.currentTarget);
+  if ($(element).parent().css('display') === 'none') {
+    return;
+  }
   ...

but I see that our stripe.js is highly modified, so I don't have a simple patch to contribute at this time. ymmv :)

Very nice work. I have been wanting for something like this, and I came across your module by trying to find how an ootb admin settings form can most elegantly read/write a config `sequence` of values in the first place.

Please try the attached patch. It indiscriminately adds `accessCheck(FALSE)` to three `entityQuery()`s.

To the module maintainer: Please advise whether it's safe here to put FALSE, whether TRUE (preferable) is more appropriate and will work, or whether it should be patched with TRUE and additional work is needed to provide said permissions for these three places.

Looks like this accessCheck() requirement was introduced "back in" Drupal 9.2 ( https://www.drupal.org/node/3201242 → ). I wonder why it's only coming up now during an RC.

texas-bronius → created an issue.

I think @vinodhinisureshbabu in #37 poses a nice solution:
```
field_plaintext_author:
- plugin: parse_lcm_author
source: body/0/value
- plugin: default_value
default_value: 0
- plugin: skip_on_value
value: 0
method: row
```
My plugin `parse_lcm_author` returns an array of values (or empty array `[]`), and `default_value` understands an empty array to require a default value. I used 0 but any scalar value will do. (skip row or process as is appropriate to your needs -- I'm building paragraphs in this migration, so it was good to get out without a mapping made)

```
/**
* Implements hook_theme_suggestions_HOOK().
*/
function layout_paragraphs_theme_suggestions_field(array $variables) {
$suggestions = [];
if ($variables['element']['#formatter'] === 'layout_paragraphs') {
...
```
This feels to be generally in the right direction, but I am not certain. Also feels a bit rigid and not as abstract as Drupal would have it.

texas-bronius → created an issue.

texas-bronius → created an issue.

Two cents here - - I experienced the same error uploading an image to use for Paragraphs Browser, and applying the patch https://git.drupalcode.org/project/paragraphs_browser/-/merge_requests/5... from #3 above does overcome that error, but I then see another error:
```
TypeError: mb_strlen(): Argument #1 ($string) must be of type string, array given in mb_strlen() (line 333 of /app/public_html/core/lib/Drupal/Core/Form/FormValidator.php)
#0 /app/public_html/core/lib/Drupal/Core/Form/FormValidator.php(333): mb_strlen(Array)
...
```

Related or not, I don't know, but when I forgo this nice image upload method and instead plop the img right into, say, a custom themes path, I can let the image file convey with code/config: win-win!

texas-bronius → created an issue.

Text `schema` was linked without a uri.

Set to  https://www.drupal.org/docs/drupal-apis/configuration-api/configuration-... → to resolve it.

UX: Makes it explicitly clear that this handbook page requires a _contributed module_

Attached is a reworked `Product.php`. I don't know if I did it right, but the changes overcome the PHP fatal error in this issue queue when I run `drush ms`, and migrations are all listed out as expected now.

Please see my question above about how best to use this submodule in a real project. Is it just copy/paste? What all should we copy/paste?

So.. I am rolling up my sleeves finally :) and presume that maybe this is due to php8.2 on my end, and maybe php8 is just none-too-happy with things like:
```
$file_data['all_sku'][] = $row['sku'];
```
before `$file_data['all_sku']` even exists. Ok, I'll plug through and see where I get.

Just what is the right way to use this looks-pretty-really-useful example migration? Not enabling it, the Product.php plugin is missing. Enabling it, a whole bunch of example migrations get enabled (even without `./script/cp_migrations magento`)

texas-bronius → created an issue.