🇺🇸United States @caspervoogt

I ran into this too, and could only solve it by reinstalling vapn v3 and then re-running cron.

I don't know why cron thinks it needs Drupal\vapn\VapnFieldDefinition when vapn is uninstalled.

The auto-generated patch was not applying to 1.3 but applied fine on 1.x-dev for me. Changes tagged version to 1.x-dev.

I want to reiterate what @Toby Wild and @dubs said. I ran into the same problem after importing a feed type with config sync, on Feeds 3.0 in my case. Simply re-saving the feed type resolved it for me.

I re-rolled the patch from #64 against the current 5.x-dev, and was able to apply this, and am now getting view data in the structure the OP was asking for (and which I was also looking for).

I think it would be great to enable multi-value rows. Getting composite field webform submission data into views in a usable + useful format pretty much requires multi-value rows.

I tried #64 ( https://www.drupal.org/files/issues/2023-08-09/views_separate_row_per_we... → ) and https://git.drupalcode.org/project/webform_views/-/merge_requests/11.diff and could get neither to apply.

I got errors like "git diff header lacks filename information when removing 4 leading pathname components (line 5)" and "Plugin/views/field/WebformSubmissionCompositeField.php: No such file or directory". I got such "No such file or directory" for all files these patches try patching. I checked my webform_views folder and it does most certainly contain all those target files in the expected locations.

Patch #56 does not apply if you keep your modules in modules/contrib. The patch hardcodes a 'modules/video_embed_media' path.

I'm seeing this on D10.3.

I noticed that if I enable translation on URL aliases, they do work. I can create a French alias for an English URL, for example.

So it seems maybe the only issue (at least in my case) is that /admin/config/regional/content-language incorrectly shows "URL alias (Translation is not supported)." ... when it apparently *is* supported.

Thanks for this very useful module. I had been wishing to have the old D7 translation merging tools added to D9+ for some time now.

I tested the patch from #2 and it worked for me. I think this should be the default behavior. From my perspective, this patch brings back the old D7 way of linking orphan translations.

I ran into this on 10.2.x and 10.3.x. I tried the "Entity ID" workaround by OP as well as jrochate's suggestion in #13, and neither worked for me.

What did work for me was to re-create my view display within my existing view. For whatever reason, my existing display would start exhibiting this issue as soon as I activated aggregation on it. The new display displays fine with aggregation.

This is still an issue, for me at least, on at least four sites I manage. I attached a screenshot of the issue. That shows how the front page is the first link in the XML sitemap, and uses a correct link, but the sitemap also includes a node/[nid] link to the home page, and it shouldn't.

FYI, I was using the 3461912-9.patch patch from https://www.drupal.org/project/social_share/issues/3461912 🐛 Fatal error on upgrade of typed_data dependencies RTBC along with 3378493-3.patch from this thread.. and I could not get 3378493-3.patch to apply, because 3461912-9.patch patches the same things.

Patch from #18 works for me.. RTBC IMHO

I was running into issues with linked media images not rendering as linked images. Disabling the 'Convert line breaks into HTML' filter fixed that for me. It was not enough for me to move it to the end of the list of filters. I also tested putting it first. Only disabling that filter solved it for me.

The patch worked (thanks!), but similar to azovsky, I ran into "The file public://css/menu_icons_1714514736.css was not deleted because it does not exist." when clearing Drupal caches. I had a look at the patch and module files but am unsure why this would happen, or how to address it.

What @Wim_Leers said.

Editor_advanced_link is stripping out my empty links, including anchor tags. Core does too (by default), but it can be worked around like I describe below. I manage a Drupal 10.2.2 + CKEditor5 site that has pages containing tons of anchor tags e.g:

<a href="abc123"></a>

Those get removed when saving the node with editor_advanced_link is active.
With editor_advanced_link uninstalled, this also happens, but I can fix it by:

A) Enabling the CKEditor5 Source plugin
B) Adjusting that plugin's "Manually editable HTML tags" settings to include "".

After that I can add/edit/save textless '' anchor tags without issue.

I tested the above with Linkit uninstalled, so it is not in the mix here.

With editor_advanced_link installed, my 'Source editing' CKEditor5 plugin settings for get overridden by editor_advanced_link and show "The following attribute(s) can optionally be supported by enabled plugins and should not be added to the Source Editing "Manually editable HTML tags" field: Advanced links ()."

This happens even when I have not yet selected any of the attributes this module provides (aria-label, title, class, id, target, rel). As soon as I install this module, anchor tags / links with no text stop getting saved. I also tried enabling the 'Limit allowed HTML tags and correct faulty HTML' filter, which did not help.

This may be a nothingburger. I just copied the site that was having this issue over to another server. Both are LEMP stack, PHP8.1, MariaDB 10.4, Drupal 10.2.4. The one I just copied over has no issue with the namespacing ("class: Drupal\spamspan\TwigExtension\SpamspanExtension" is just fine for it). No idea why these two acted differently. Marking "Closed (cannot reproduce)" for now.

Looks like a namespace / camelcase issue. Patch attached

Patch attached.

caspervoogt → created an issue.

I tested 3311063-56.patch on 10.2.4 - working for me.

I have struggled with the Git commands above. The printfriendly-3396354 branch's printfriendly.info.yml has this:

core_version_requirement: ^8 || ^9

The 3.x branch has this:
core_version_requirement: ^8 || ^9 || ^10

Yet when I git pull the 3.x branch I don't get that updated code. A release would be really great.

Patch #6 from https://www.drupal.org/project/context/issues/3171741 → fixed this for me on 5.0.0-rc1

@acbramley thanks. I think my issues are probably environment/server-related

I ran into this and in my case simply deleting the flexslider module folder and running "composer install" at my project root solved it. Happens to me sometimes on some servers.

I noticed this fix was not included in 10.2.4 (according to the release notes) but is marked "Closed (fixed)". I'm curious when it will be included in a release, because I am still running into this issue even after updating to 10.2.4.

#2 patch worked for me

caspervoogt → created an issue.

@vlyalko you're welcome! Took quite some detective work to figure out

I have run into this too, and in my case it was due to my Composer not being able to run Composer plugins within Docker, due to this Docker error "Composer plugins have been disabled for safety in this non-interactive session. Set COMPOSER_ALLOW_SUPERUSER=1 if you want to allow plugins to run as root/super user". So at least in some cases it could be Composer plugin related. This is new since Docker 2.4.2 (discussed here). Adding "COMPOSER_ALLOW_SUPERUSER=1" to my Dockerfile solved the issue for me.

I'm on D10 and MariaDB, and there's no batched export as far as I can tell. I wonder why this restriction exists

I just tried updating Drupal core from 10.1.7 to 10.2.2 and ran into dependency issues with composer. There was a conflict between cweagans/php-webdam-client 1.0.3 requiring guzzlehttp/psr7 2.5.0 while Drupal 10.2+ apparently requires guzzlehttp/psr7 2.6.0. I had a look at php-webdam-client's composer.json's require code block:

"require": {
    "php": ">=5.6.0",
    "guzzlehttp/guzzle": ">=4.1.4 <8.0",
    "guzzlehttp/psr7": "~2.5.0"
  },

So I forked https://github.com/b-sharpe/php-webdam-client.git and tried:

"require": {
    "php": ">=5.6.0",
    "guzzlehttp/guzzle": ">=4.1.4 <8.0",
    "guzzlehttp/psr7": "~2.6.0"
  },

.. (and some variations of that guzzlehttp/psr7 line), but kept running into compose dependency conflicts, so I tried just removing the 'require' code block entirely to make this library's composer.json more permissive, and that worked fine for me on 10.2.2;

• I figure a minimum PHP version of 5.6 is a moot point / not needed in this code block since core requires that anyway
• wrt guzzlehttp/guzzle and guzzlehttp/psr7 I removed those requirements too. This way we could identify if there are indeed conflicts with certain core versions, and then re-add composer requirements only as needed

If you're trying to update to D10.2, you can use my fork at https://github.com/cweagans/php-webdam-client.git instead of https://github.com/b-sharpe/php-webdam-client.git in comment #16, and make sure you require version 1.0.4 (my new version tag) not 1.0.3.

I updated to 10.2.1 but that did not fix my issue. When I have BigPipe installed, my comment form consistently does not show - every time. No JS errors. Just this HTML gets rendered:

<span data-big-pipe-placeholder-id="callback=comment.lazy_builders%3ArenderForm&amp;args%5B0%5D=node&amp;args%5B1%5D=19040&amp;args%5B2%5D=field_comment&amp;args%5B3%5D=blog_comment&amp;token=GIszGpkYD5yzHH572vPlvi8RJYjjHj4MmaakxGwnAKE">
</span>

I realize this is precious little to go on, but felt it's important to point out even if I am a lone voice in the wilderness here (it may help someone else). I'm fine with just uninstalling BigPipe as a stopgap solution; that's how I solved it for myself, but it's a shame to have to do that.

I'm not sure if this is a comment module or big_pipe module issue and didn't want to pollute https://www.drupal.org/project/drupal/issues/3390178 🐛 big_pipe sometimes fails to load blocks Active with this issue (since it's marked fixed), so I thought I'd post here first. I changed the status from 'Duplicate' to 'Needs work' for now since I don't think this is a duplicate.

no JS errors on my end but it was consistently not rendering the comment form block. Looks like the issue has been resolved on 10.2.x-dev ( https://www.drupal.org/project/drupal/issues/3390178 🐛 big_pipe sometimes fails to load blocks Active ) though.. I will check with the next release

Changed Drupal version to 10.2.0 since I encountered this on that version just now.

I ran into this myself just now on 10.2.0 FWIW. It was a D9 site that had the core big_pipe and comment modules installed, with commenting enabled. Updated to 10.2.0 and the comment form disappeared. Uninstalling big_pipe fixed it.

This is actually fine. I forgot that it is set to true by default so I was making much ado about nothing.

thanks @longwave

@taraskorpach you're right. I was grasping at straws debugging an accessCheck issue.. turned out to be a contrib module issue

I was able to apply the patch from #26 (via composer.json). Performance seems OK but I hope a few others can test that as well.

caspervoogt → created an issue. See original summary → .

caspervoogt → created an issue.

ignore 34113526-accesscheck-not-set-service.patch and use 34113526-accesscheck-not-set-notificationservice.patch instead pls

I missed one: src/Service/DmbNotificationService.php also has an empty access check.

I just noticed that src/EntityListBuilder/WebformEntityListBuilderSortLabelTrait.php also has an empty accessCheck. I may make a patch for that one shortly.

caspervoogt → created an issue.

caspervoogt → created an issue.

Thanks @heathergaye, fast404 caused it in my case, and updating from v2 to v3 solved it.

@dgilbert; if you use the fork, you will want to remove media_acquiadam module from your composer.json and just install the module like this:

• Go to your /modules or /modules/contrib folder (if using a contrib subfolder)
• Run 'git clone https://git.drupalcode.org/project/media_acquiadam.git'
• Run 'cd media_acquiadam'
• Run 'git remote add media_acquiadam-3362505 git@git.drupal.org:issue/media_acquiadam-3362505.git'
• Run 'git fetch media_acquiadam-3362505'
• Run "git checkout -b '3362505-upgrade-acquia-dam-1x-to' --track media_acquiadam-3362505/'3362505-upgrade-acquia-dam-1x-to"
• Use the patch from #16 and add this to composer.json's repositories section:
  

  "cweagans/php-webdam-client": {
              "type": "vcs",
              "url": "https://github.com/b-sharpe/php-webdam-client.git"
          }

That last step is crucial because otherwise the php-webdam-client's guzzle library will be stuck on a version that's incompatible with D10's guzzle library version, as discussed above.

I followed the steps above myself and successfully got my D9 site update to D10 this way.

#62 worked fine for me

I tested 8.x-1.x-dev (which now has the patch committed) and it worked for me. Hoping to see a release version soon.

thanks @fermicode and @cadag, my mistake moving fast and breaking things! I had to get my site updated to D10 quickly and obviously flubbed something on my patch.

For some reason, I have found that at least in one case for me, it helped to add .field-field-media-oembed-video as one of the FitVids video containers on /admin/config/media/fitvids, even though I did have a valid container already defined. That works for me, no need for a patch or extra CSS.

#45 worked for me. I could not get #50 to apply.

So here's a patch which did work for me. Again, I'm on D10 so YMMV.

This is a very simple patch; it would be great to get this committed because I was unable to use this to patch this module during a D10 upgrade. I resorted to including this module in code without using Composer. Aside from that, I also encountered this error when running this module with D10:

PHP Fatal error: Declaration of Drupal\rest_absolute_urls\Normalizer\StringDataNormalizer::normalize($object, $format = null, array $context = []) must be compatible with Drupal\serialization\Normalizer\PrimitiveDataNormalizer::normalize($object, $format = null, array $context = []): ArrayObject|array|string|int|float|bool|null in /web/modules/contrib/rest_absolute_urls/src/Normalizer/StringDataNormalizer.php on line 40

I tried this patch on D10 and got:
PHP Fatal error: Could not check compatibility between Drupal\rest_absolute_urls\Normalizer\StringDataNormalizer::normalize($object, $format = null, array $context = []): Drupal\rest_absolute_urls\Normalizer\ArrayObject|array|string|int|float|bool|null and Drupal\serialization\Normalizer\PrimitiveDataNormalizer::normalize($object, $format = null, array $context = []): ArrayObject|array|string|int|float|bool|null, because class Drupal\rest_absolute_urls\Normalizer\ArrayObject is not available in /web/modules/contrib/rest_absolute_urls/src/Normalizer/StringDataNormalizer.php on line 40

Not sure it matters that I'm on D10

In my case what solved it was that my custom theme's info.yml contained a core/once dependency, while my themes's libraries.yml already contained that dependency. I removed the dependencies code block from my info.yml and that fixed it.

I just ran into this on 10.1.6. Installed the module, configured it to select my content bundle, for 'Available subscription modes' I picked both options, for 'Default state for the notification selection box' I picked "All comments", and I have 'Subscribe users to their entity follow-up notification emails by default' checked. Unchecking those makes no difference.

#7 worked for me

Thanks, all good on my end. I switched to 3.x without issue.

caspervoogt → created an issue.

@dgilbert it isn't super obvious, but click the "Show commands" link next to the 'Issue fork media_acquiadam-3362505' bit near the top of this page. Run those commands inside this module's folder (not at root). After that apply this path via the root composer.json. I am using 1.x-dev FWIW, but this should work for 1.48 too I imagine.

#11 worked for me and comes back green in Upgrade Status. I have not yet updated to 10 but RTBC from me

I tested #4 and it worked, at least on my D9 install; I have not updated to 10 yet but Upgrade Status does report redirect_metrics is D10-ready now.

Thanks for everyone's work on this. I tested the media_acquiadam-3362505 fork and the patch from #16 and Upgrade Status now reports zero rector issues and it reports it as D10-compatible. I have not yet updated to 10 so can't comment on that yet. I would want to see the D10 updates released before I proceed with my D10 update. I may update to 10 soon, and will report back then.

@dpagini "If Acquia will not review this approach and move it forward, I'm wondering what folks see as the option here to use this module on Drupal 10?": The https://www.drupal.org/project/webdam → module is the only other option I have found that would work with Acquia DAM Classic and D10, but it would be a painful switch because it has no migration support from 'media_acquiadam' to the 'webdam' module. I believe it would require manually updating all media entity ref fields to the new media type and selecting the relevant media again, either manually or with some custom script.

You're right, Berdir. Issue on my end I think; I had to completely remove BEF and jquery_ui_slider from code and re-run 'composer install' to ensure it replaced all the files, now it works. That is normally not something I need to do when working locally, so it threw me off.

BEF requires jquery_ui_slider 1.1 which is not D10-compatible. When I try to require the D10-compatible v 2.0.0 of jquery_ui_slider it causeds Composer conflicts. I think BEF's composer.json should require jquery_ui_slider 2.0.0 instead of 1.1, or remove the requirement entirely, because it is preventing updating to D10.

Related issue at https://www.drupal.org/project/better_exposed_filters/issues/3317774#com... 🐛 Dependencies affecting upgrade to v6.0 Needs review

I am trying to update to Drupal 10 and can't, because Better Exposed Filters requires jquery_ui_slider 1.1, and that is not D10-ready. jquery_ui_slider 2.0.0 is D10- and D9-ready though. I think BEF's composer.json should require jquery_ui_slider 2.0.0 instead of 1.1.

The patch from #6 worked for me

I had just queued two tests on #12 right before you posted here, Chris. I see they passed.

Thanks everyone for the work on this important change to this module. I tested the patch from #24 and it worked for me, on PHP 8.1 / Drupal 9.5.8 / simple_sitemap 4.1.4. Looks good to me. This was marked 'needs work' but it doesn't look like it needs work. I changed it to 'Needs review' but if I am wrong please feel free to set it back to 'needs work'. RTBC in my book.

#12 worked a treat for me.

I also confirm that fixed it.

caspervoogt → created an issue.

caspervoogt → created an issue.

https://github.com/ckeditor/ckeditor5/issues/13983 has only 7 votes; maybe if some more Drupal folks can log into Github and upvote it, the CKEditor maintainers will give it higher priority.

@martins.bruvelis I just tested that plain diff and get the same error; 'There are no taxonomy terms matching "testingignore" when I tried adding a new term called "testingignore" using the Autocomplete widget. My widget is configured to allow new terms.