🇳🇿New Zealand @Gold

gold → created an issue.

Hey all,

Just back from DrupalSouth and checking up on issues. Just wondering if there is anything I can to do help push this one over the line?

Cheers,
Gold

Hey all,

Any chance of getting this merged in and a release?

Cheers.

Nice. Functionally, this is doing the job. :)

I ran it through phpcs and it only raised one minor issue. I don't see that as being enough of a reason to prevent this from being marked RTBC though.

Thanks @cmlara for the effort on this.

Hey all,

Just wondering on the status of this ticket. It looks like there's been no movement on MR57 since early Feb. Should this be in a Needs Review state? That is something I can contribute to. :)

This is looking perfect for my needs also. However, we're upgrading to D11. Any chance of this being merged in and released?

Not a problem. Thanks for being so responsive on the issue too. :) That's a really good turn around on the release time too. :)

Just adding the Needs review. While "it worked for me" I didn't do proper review on it.

@stevenpatz, I have an issue open on the WBE Issue queue that gets the 2.x branch working on D11. If you could test that and provide feedback, that would be appreciated.

https://www.drupal.org/project/workbench_email/issues/3507315 ✨ Upgrade the 2.x branch for Drupal 11 Active

Local testing on a clean DDEV instance showed mail capture in Mailpit. This is looking functional. :)

I just hit this on a clean install while working on another WB module. The current patch at MR!15 worked for me. I don't know the consequences of the patch, but it let me enable the module without the error.

Drupal 11.1.2
Drush 13.3.3.0
Workbench Moderation 8.x-1.8

Hmm... And having posted the Issue it reads like I expect @larowlan to be the one doing the work. This was not intended. :)

I'm going to make a start on it myself.

gold → created an issue.

I'm in the same position as @stevenpatz in that moving from WBM to CM is proving difficult and WBE is the blocker to the upgrade to 11.x.

If working on an 11.x version of WBE 2.x is an option I'd be keen to contribute to that too.

hook_search_api_solr_query_alter() has been deprecated. Linking to the current page in this section that explains how to replace the hook with a PreQueryEvent.

Hey all,

Thanks to those that put in the effort here.

Any chance of a merge and release for this MR?

This gets an RTBC+1 from me too.

This is more "Support for mastodon.social". Not all of us on Mastodon use that singular site. :)

Does Social Link Field allow for user entered urlPrefix? I'm suspecting not.

@__i.am.prashant__ I suspect your issue wasn't solved after the patch because that values are used when adding the field. If you drill down to the form display for your content/block type and click the gear for the field options you will see 2 checkboxen. These relate to the settings in the patch.

If you tick the first one things should work as expected.

Also, the patch at #3 is extremely simple. This gets an RTBC from me just from looking at it.

gold → created an issue.

Rerolled patch at #35 applies and still works as expected.

Cheers @andysipple.

I'm suspecting this is no longer an issue. I've just installed (not updated) the module on a site running PHP 8.3 and things installed fine. The upstream updates look to have resolved things.

@retrodans, my early testing of the patch at #7 left me thinking it was okay as well. A deeper dive showed the issues I outlined in comment #10. Can you confirm that you do or don't see the issues from that comment?

Even if this issue is used to track a potential list of other issues we want to see resolved before the RC that would be helpful.

If such a list is considered, could one of the maintainers post that list so others know what to focus on?

Gold → created an issue.

This is what worked for me.  It's close to what @tyeth provided but that didn't quite work. I suspect Twig has moved on a bit.

{% if content.field_cancel_destination.0['#url'].external %}
  {% set cancel_destination = content.field_cancel_destination.0['#url'].uri %}
{% else %}
  {% set cancel_destination = path(content.field_cancel_destination.0['#url'].routeName, content.field_cancel_destination.0['#url'].routeParameters) %}
{% endif %}

Scratch that. While this is technically correct and will allow the module to be installed via composer it won't let the module be enabled.

@Bhanu951, @Roshni_Kodiganti, could you both update your patches to include Drupal 10 in the announcement_modal.info.yml file too.

core_version_requirement: ^8 || ^9 || ^10

Both of these get a +1 from me. I would suggest the patch at #2 though. Drupal Core 8.x has been EOL'd for quite a while now. If it is advertised as supporting it it means the devs will need to accept issues on that version.

Additional: Clicking "Open in new window/tab" works when the link is first created. If you just edit and save the modal without touching anything it looks like the is applied then as well.

I've tested this in multiple environments now too. Pulling it back to Need Work.

What I'm seeing on the second edit is that the target is applied to all of the surrounding paragraph.

e.g.

<p>
    <a target="_blank">Lorem ipsum dolor sit amet, consectetur </a><a href="https://media-staging-2.yvw.com.au/inline-files/dummy_19.pdf" target="_blank" title="Title field" id="an-id" rel="noopener" data-entity-uuid="e1ab4332-7d39-466e-988f-72d977484cdd" data-entity-type="file">sagittis</a><a target="_blank">, nulla eget metus odio.</a>
</p>

I've just looked over the patch. I'm wondering if this may be related to the selected text range? In the instance where the button is clicked from the popup in the existing link there is no selected range.

I also note the following:

• Double clicking the link in the editor and clicking the button in the toolbar opens the modal with the file populated but none of the other attributes.
• If "Open in new window/tab" is unticked and rel is empty rel is added anyway with a value of undefined.
• CSS doesn't appear to save reliably.
• Multiple links is flaky. Having 2 links without "Open in new window/tab" and then editing the second one to "Open in new window/tab" crashes out the JS. Behaviour after that was unstable.

What version of Editor File upload is being used here? And are any patches to that in place?

I have Editor File upload at 2.0.0-rc1 with no extra patches. The patch here applied to EAL 2.2.4 fine.

Were there any other steps that needed to be taken? e.g. Did the Filter processing order need to be reordered?

I want to ensure that it is not me before I pulling back the RTBC.

Hey all,

My issue with this has been around using this module with the paired editor_file module.

It is looking like this issue is very similar and may have a working patch. It isn't working for me, but others are claiming it works for them.

https://www.drupal.org/project/editor_advanced_link/issues/3416599 ✨ Edit_Advanced_Link+Editor_file: conflicting field attributes RTBC

Can people head that way and test the patch there?

@krish1505, nuts. I was just looking at the changelog and wondering if one of the CKE updates may have resolved this. Cheers for being on top of that.

Further discovery:

I'm kinda old school and things like webpack are a hurdle for me. With the assistance of a co-worker though I got this to a point where I could debug things. Just in case others are in my position...

I checked out the module from git and edited webpack.config.js. In const bc = {} I added devtools: 'inline-source-map' and commented out the whole optimization: {} section. From the module dir, running npm i preped things and npm run watch would rebuild the JS that's actually used as the source files are edited.

I’ve now got it to the point where the JS is clear and breakpoints are working. I’ve added a breakpoint to the start of literally every function in the JS in this module. Loading the page shows breakpoints are working. I also have XDebug running and submitting the form does trigger a callback to Drupal and I can see it track though _editor_advanced_link_attributes_validate() in editor_advanced_link.module. What I’m not seeing is any JS being triggered in the module upon return to CKEditor.

This doesn’t feel right. It would seem to me that something in the EAL JS should be pulling details from the response and populating the link that is added in the body of CKEditor.

Anyway, this is where I got to. I'll continue to poke at this when I can, but if anyone knows CKEditor 5 plugins and knows how that trigger should happen please contribute to the discussion. I'm happy to do the work, I just need pointers.

I'm still seeing this on 2.2.4.

Also, I'm seeing this on any file, not just images.

I'll add my +1 to this issue. I have just stripped out all but the bare minimum to get this to appear on the bar and after ensuring that it is configured to allow all the fields it offers none make it into the HTML. Not in the Source in the editor or on the rendered page.

My scenario has this happening on the addition to the Editor File upload → field. Adding values does not survive submission of the modal. The HTML has these extra fields striped so when editing the field again they're still empty.

I stood up a SimplyTest.me instance using the Standard profile with just editor_advanced_link and the standard Link field in CKEditor had the new fields and they worked as expected.

I added Editor File upload module, enabled it, added that button to the bar, and tested. The error described was present there also.

This is feeling slightly different to the scenario of the inital report, but it feels close enough that they're likely the same issue.

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

Gold → created an issue.

@grapple, I did look at that snippet and tracked back to where the config for that value was being set. It started getting a bit convoluted though and I had a bit of time pressure.

This value seems to be being set in 1 place when the form is first submitted in CspSettingsForm.php:631.

I tried flipping the order that $policyTypeKey was processing at L626 but that didn't make any difference either.

I think the issue is tying the $form['policies']['#default_tab'] to the value in that config var.

An alternative could be to add #weight to the $form[$policyTypeKey] array.

I'll push an update for that in a moment. Let me know what you think.

Gold → created an issue.

Gold → created an issue.

I just hit this on an upgrade from 10.1 to 10.2 and the patch of MR46 resolved this for me.

I would consider this RTBC but agree with @Eli-T on the unknown consequences for those still on 10.1 so won't update the Status.

Okay, reverted. Though it still doesn't make 100% sense, since the report is called "Broken Links".

Absolutely agree with this. It's not a task that this ticket is for though. :) And you're right, with it being a standard view the end user can modify it to their specific needs.

I'm feeling like this is RTBC but as one of the people that did the code part of this I don't think it's my place to do that.

#15 It does filter. However, the filter in the dropdown for "Failed" is no longer needed. And the filter for "Success (2xx)" should be removed, as it will never return results.

I don't think this is the case. If the ignored response codes was intentionally set to be empty all response codes would be returned and the existing selectors would be useful. I would revert commit bfc4fdad. If we forced the contents of this to include "success" values this would be a reasonable edit.

#16 re: adminSummary()

Good catch. Cheers. :)

#19 Question, should the report also exclude links that have status checking disabled?

I'm not sure where/what this is. Either way though, that's out of scope for this issue and should be added as a new issue so we can get this one over the line.

I've got a working MR. At least it's working locally for me.

Gold → changed the visibility of the branch 3065056-dont-treat-these to hidden.

I've got a branch that's not ready for an MR yet.

https://git.drupalcode.org/issue/linkchecker-3065056/-/commit/237e7dd35a...

This is on 2.0.x and looks to be working, right up until it doesn't.

The query() method is being called. I can see my WHERE clause being added to the query object. If I use the exposed filters to add a filter on only one Status Code I can see that being added as well and it is going into the same place in the object my stuff is going. The only difference is that my filter is not being used.

I've tried a couple of approaches.

I used $this->query->addWhere($this->options['group'], "{$this->tableAlias}.{$this->realField}", $ignored_response_codes, 'NOT IN') and even walked over $ignored_response_codes adding each as a "!=". I also tried addWhereExpression($this->options['group'], "{$this->tableAlias}.{$this->realField} NOT IN (" + implode(',', $ignored_response_codes).

While all are going into the query object, none of these worked.

All we appear to need to do is get this query() to work and we've got it.

If people want to patch their local version you can add .patch to the commit link above. Once patched you can edit your local Broken Links Report to add the filter.

Input requested. I'm hoping that there's something about Views Filters that I'm just missing, but the things that I've been referencing all suggest this should be working.

I've never written a Views filter but am currently giving it a go.

The intention is to just add the filter to the View and have it add and code not in ("this list") to the query. The filter config form will just have a link to the module config form. Then add this filter and export the view again.

Is there any reason to just not record the results if the response code is in the list?

Thanks for this @adam-vessey.

The PR is not merged at the point of this post, so for others that land here, I resolved this by adding twistor/flysystem-stream-wrapper via composer and applying the patch on PR-28 via cweagans/composer-patches.

If this is not yet merged in please comment on the PR if it worked for you.

I've deployed this to a test environment that the client has access to and it's working well there as well.

@Mohd Sahzad, you're a rockstar.

it was a nice surprise to start work this morning and find this here. Cheers for that. :)

This did the trick for me and gets my RTBC+1.

Hmm... Not sure if this should be reopened or not.

I'm experiencing this exact issue, down to the line number.

My state of play:
PHP 8.2.11
I'm upgrading an existing site to Drupal 10.0.15 (for reasons) from Drupal 9.5.10.
I'm going from Webform 6.2.0-beta6 to Webform 6.2.0-rc2
I have the following additional webform modules installed:
* Webform Image Select
* Webform UI

I've seen similar errors in my searching on this too. I'm at the end of my day. I'll try and prep a patch for this tomorrow though. If it is a low impact thing hopefully it will be considered.

I'm in the process of updating a site to Drupal 10 and it was applying this patch. However, when applying it to 1.2.0 via cweagans/composer-patches it no longer applies. I'm at the end of my day so won't be working on this right now, but I have a client paying me to do this work. I'll see about getting a refactored patch tomorrow and also see if I can work in the form_id check.

@Adam Clarey, I've just used cwegans/composer-patches and gitlabs handy "make this MR a patch" option to patch the current RC. The error above that we are seeing has now gone away for me.

I don't know if this is ready, but it's a lot further along that it was so I consider this to be RTBC. I would like more people to test the patch though. For reference, this is the patch I'm applying.

https://git.drupalcode.org/project/flysystem/-/merge_requests/26.patch

A note for others. As I understand it any new commits on that MR will appear in the patch so this should not be considered a snapshot in time.

I've just hit the same issue as @Adam Clarey at #23. This is needed for client work too so I may take a run at it at well.

@Shani Maurya, could this be a replication of https://www.drupal.org/project/gutenberg/issues/3372307 🐛 Javascript Errors in Drupal 10.1 Fixed ?

A quick test would be to turn on JS aggregation and see if things start working. If so, you could try applying the patch in that issue. It is a bandaid that prevents the Gutenberg JS from being aggregated and will likely be removed when https://www.drupal.org/project/drupal/issues/2990907 🐛 JsOptimizer preg_replace gives null as return Needs work is resolved.

If this looks to be the case, could you close this as a outdated?

Cheers,
Gold

The patch at #10 is looking good. I'm running with it in 2 environments at the moment and both apply fine.

+1 for RTBC.

Cheers for this @Ranjit1032002,

I have the patch in MR!48 running in 2 environments and the issue is looking to be resolved with that.

+1 for RTBC

Adding the patch in MR!1 via cweagans/composer-patches does seem to do the job.

gold@saturn:~/path/to/site $ ddev composer require 'drupal/look:^2.0'
./composer.json has been updated
Running composer update drupal/look
Gathering patches for root package.
Removing package drupal/look so that it can be re-installed and re-patched.
  - Removing drupal/look (2.0.0)
Deleting web/modules/contrib/look - deleted
Loading composer repositories with package information
Updating dependencies
Nothing to modify in lock file
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Syncing drupal/look (2.0.0) into cache
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Installing drupal/look (2.0.0): Cloning 2.0.0 from cache
  - Applying patches for drupal/look
    https://git.drupalcode.org/project/look/-/commit/653f272da67463af3c2113e28dd922502d8c4332.diff (Issue #3384743: Unresolved dependency Modifiers)

Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Package symfony/debug is abandoned, you should avoid using it. Use symfony/error-handler instead.
Package webmozart/path-util is abandoned, you should avoid using it. Use symfony/filesystem instead.
Generating autoload files
49 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Info from https://repo.packagist.org: #StandWithUkraine
No security vulnerability advisories found
gold@saturn:~/path/to/site $ ddev drush updb
 [success] No pending updates.

Actually, looking at other modules I don't think the version is needed.

Gold → created an issue.

Is this still an issue? I have a View at the moment where this is an issue with the JSON output, but the CSV works fine.

@Alexandre360, create a view using fields and add a label with spaces to one of them. I'm currently having that label render fine.

I'm seeing this on Paragraphs 1.15.

The site is a build with no custom code touching this area. The error is resolved with the rerolled patch at #17 is working for me. @akhilavnair, the only tweak I'd suggest is code standards on the comment.

Given there are many reports of this being resolved by fixing it in Paragraphs I'm unsure why this isn't just being resolved here.

It works. Using the patch at #17 with cwegans/composer-patches for now.

Hmm... Odd. "It works for me." :)

@carsonw, I should be able to test this again this week. I'll let you know how it goes and if it applies fine I'll ditch my one.

Cheers for testing.

@jurgenhaas, any change of a release of this please? It's merged, but the project page is not yet showing ^D10

The patch at #3 is no longer applying when used with cewegans/composer-patches and a standard composer require 'drupal/simple_pass_reset:^1.1'.

I'm going to leave the patch at #3 as current though as that does still apply to the dev branch.

If people are needing this for a production environment and don't use dev branches in prod, the attached will work for you.

As @richardhobbs states, the patch from @Project Update Bot doesn't apply. Their updated patch does the job though. The RTBC state is still valid IMHO.

Looking good, just one small tweak from what I'm seeing.

Commented on the fork.

https://git.drupalcode.org/issue/jsonapi_page_limit-3360180/-/commit/2d3...

Randomly tested this and found the delete option was not available from the Edit form. But messing with a delete vocab URL still lets it happen. I've updated the Steps to reproduce.

Hmm... When I last worked with Drupal the Gitlab integration wasn't quite there. :) I'm feeling like it's still not quite there. Or, I may just need to spend more time working with it to get the hang of things.

Either way, MR!16 has a working patch on the 2.0.x branch. For those testing, this is the repo to clone.

https://git.drupalcode.org/issue/taxonomy_manager-3331822/-/tree/3331822...

The solution from @klevyke did the trick for me as well.

I've cut an issue branch and pushed a patch to it.

If others want to check that branch that'd be appreciated. For those of us using cweagans/composer-patches you can add the following to your composer file.

    "extra": {
        "enable-patching": true,
        "patches": {
            "drupal/taxonomy_manager": {
                "Issue 3331822: Taxonomy tree is not showing": "https://git.drupalcode.org/issue/taxonomy_manager-3331822/-/commit/e6d88a9ff59efd8b45e7155109b329ac8efa7273.patch"
            }
        }
    }

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

Nuts. So... This has not only been reported 🐛 Fatal error on D10: Entity queries must explicitly set access Fixed , it's been fixed. It is present in 2.0.5.

Can we get 2.0.5 release to the project page please? When installing via composer we are still pulling down 2.0.4 that doesn't have this fix in it.

Cheers.

Gold → created an issue.

Nuts. Could someone with access delete the gold-8.x-1.x-patch-09724 branch? That was created on the 1.x branch rather than the 2.0 branch.

I've been away from drupalland for a bit and the new way of doing this is not terribly intuitive. :/

Anyway... cweagans/composer-patches doesn't work with patches that alter composer dependencies. You can get around that by adding the package directly at a commit hash like this;

    "repositories": [
        {
          "type": "package",
          "package": {
            "name": "drupal/modifiers_pack",
            "type": "drupal-module",
            "version": "2.0.0",
            "source": {
              "type": "git",
              "url": "https://git.drupalcode.org/issue/modifiers_pack-3331144.git",
              "reference": "b3c1f471426435b097e04a107c053e57378fe35b"
            }
          }
        },
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }
    ]

Just ensure that the package goes before the reference to the Drupal repo.

At this point all this is doing is updating the dependency. I've not had time to test how it is working.

@clbeam, are you able to help out there?

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