🇬🇧United Kingdom @d.fisher

In the meantime I've started work on something here if anyone is interested:
https://www.drupal.org/project/mdsitemap →

I've updated a few bits so more tests pass. Just phpstan left which has quite a few items to address.

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

Any thoughts on this?

d.fisher → created an issue.

I've targeted ^10 || ^11 but the tests are now failing on an unrelated issue!

We have been busy working on a new Drupal website and lots of articles will follow on. I'm not sure why the feed suddenly works as all our attention has been on the new website but we'll make sure the new site is set up correctly and then revisit this issue then.

Done.

Agreed. I think it would make sense to provide a new major release supporting >=10.3.

The maintainer for this module has been unresponsive for some time and the module is currently in limbo. I would like to be considered as a maintainer so I can ensure this module stays up to date and has a regular release schedule! Thank you for your consideration.

Marking RTBC however I'm unsure of whether the tests failing are caused by upstead 11.x issues or something in the merge request.

Confirming this issue present in other places when modals are fired. In my case on the backend (no front end editing) and firing the paragraphs entity embed modal. MR!12748 resolves the issue.

d.fisher → created an issue.

I've just read through this and the related issue and believe this should now be closed.

Issue opened. Let's see what happens:
https://www.drupal.org/project/file_browser/issues/3535186 📌 Offering to co-maintain File Browser Active

d.fisher → created an issue.

I'm going to apply for maintainership just to get this one out of the door.

Tested and still looking good for me.

This resolved the issue for me. I'm going to mark RTBC as this has resolved the issue for at least two of us!

Agree with RTBC. Just encountered this issue and the merge request fixed it for me.

d.fisher → created an issue.

I can confirm I am also seeing this issue fixed in Drupal 11.2.2. What do we do now? Close as fixed?

Had some discussions about this issue with others and the consensus is that this has the potential to drastically bloat what is quite a simple module and if pursued should almost certainly be implemented as an optional sub module that people can switch on if they desire the functionality. As an intermediate step could we perhaps add a field to the media entity 'link' that allows the upload of a custom thumbnail? The issue with this approach is that I don't want to overcomplicate any custom implementations that people are layering on after installation of the module.

Thank you everyone for all your efforts. Great to finally get this one merged, released, and marked as fixed!!

All good. Thanks for this. I never use that summary field. Will keep that in mind for the future!!

@danrod that looks great to me. Where do you add the short description? Is it on the main project edit page in the summary of the description field? Or somewhere else?

Looking good. Tests pass. Pipelines pass. This is awesome. Great work! @danrod are you happy for me to commit this?

Interesting. I will test without the patch.

Looking good. There is a phpcs error still though.

85 | WARNING | Unused variable $media. (DrupalPractice.CodeAnalysis.VariableAnalysis.UnusedVariable)
135 | WARNING | Unused variable $media. (DrupalPractice.CodeAnalysis.VariableAnalysis.UnusedVariable)

@uv516 is that with the patch or without?

d.fisher → created an issue.

Can confirm #138 applies cleanly to Drupal 11.2.

Hi any news on that stable release?

Hi. Is this getting a stable release?

Amazing!!

I think they both need work still so I'd go with just tagging what has already been merged.

Ah. I've just refreshed myself. Videoask is a premium service and as a result gets set up as a subdomain of your own domain. If you were drupal.org for example and you wanted to use videoask as the custom subdomain your videos would live at videoask.drupal.org/s0m3rand0m1d

That regex is currently matching and HTTPS url that:
1. Starts with https://
2. Has at least one character after the domain
3. Ends with a path segment composed of letters, digits, or hyphens

This could indeed match pretty much any URL and isn't fit for purpose. Perhaps this particular plugin would need a page in the UI where you can enter the custom domain which hosts your videoask videos so that this can then be used to match?

Yeah this merge request needs rebasing and that regex looking at. Not sure why I did it like that in the end? I'll take another look.

Agreed. I think tagging a new alpha with D11 support is desperately needed. The whole idea of an alpha release is something stable enough to test but not recommended for production sites. This will at least allow more people to test the module on Drupal 11 and report any issues.

Haha I must have accidentally changed it after all!!

@avpaderno I get a 403 when I visit: https://www.drupal.org/admin/people/advanced?name_op=%3D&name=dishabhadr... →

Sorry search "drupal.org project ownership" in the project autocomplete box!!

No need for a new issue. Where the "Add new comment" section is you can edit the issue metadata where the project is currently Media Entity Link (3212769) but you can change that to be Project Ownership and it will move this issue from this module to the issue queue for project ownership and it will then be picked up by the team there to assign maintainers. The project field is an autocomplete so just start typing "Project Ownership" and it should show up. I would do it for you but when I've done that in the past the issue has been kicked straight back because the OP has to move the issue to the Project Ownership issue queue.

@danrod are you still interested in co-maintaining this module?

This issue is ready to be moved to the project ownership issue queue now. This should be done by the OP. Please use the Project autocomplete and change it from Media Entity Link to Drupal.org project ownership and avpaderno should be able to add you as a maintainer!

I've added a MR for this. Here's the patch.
https://git.drupalcode.org/project/config_pages/-/merge_requests/45.patch

After digging in to the code I can see that 'administer config_pages types' permission does add some security around clients accidentally clicking the button, but it might be nicer to have this broken out into its own permission. Let me know what you think either way!

darren.fisher → created an issue.

Can this be merged and released? Tested locally on Drupal 11. It's a quick and simple change that would make this module Drupal 11 compatible?

Thank you!!!

Thank you!!!

In terms of moving this issue on it might be helpful to create a branch from this issue and have Drupal log which config file contains the offending NULL instance so that it's easier to pinpoint where the error is occurring?

Alternatively you could find offending item (in my case the taxonomy term view) and edit it in the UI and then save it to see if the system can resolve the config on its own and then export that item and reimport. This is what fixed it for me!

I resolved this by looking at: web/core/lib/Drupal/Core/EventSubscriber/ConfigImportSubscriber.php

After line 289: $data = $config_importer->getStorageComparer()->getSourceStorage()->read($name);

Put a var_dump: var_dump($data);

This allowed me to search for instances of NULL and I found one in views.view.taxonomy_term.yml where I had:

dependencies:
  -  config: null

Removing the - config: null line fixed my import issues.

THIS IS NOT A ONE FIX FITS ALL SITUATION!

You need to find exactly where in your config there is an instance of NULL that shouldn't be there and get rid of it!!

Good luck. Hope this helps!

Oh nice!!

I like this idea. The issue with relying on meta tags is that a lot of sites won't use them. I wonder if we could leverage Puppeteer to grab a screenshot of the webpage and save it as a file, but I believe this requires having node.js.

Here's the documentation for when I come back to this:
https://pptr.dev/guides/screenshots

This isn't going to be straightforward but it's a really good idea that I'd definitely like to look into.

This feature request has been captured in a duplicate ticket: https://www.drupal.org/project/media_entity_link/issues/3244504 ✨ Ideas for module: capture screenshot, store page info Active .

Closing as a duplicate.

As vladimiraus seems absent and danrod has opened another issue I will move this to closed (outdated).

2.0.4 released with support for PHP 8.1 and 8.2 reinstated.

Never mind. I think I was just using the wrong variable in the gitlab-ci template.

Just tried this and the runner was hanging. Looked here:
https://www.drupal.org/docs/getting-started/system-requirements/php-requ... →

Drupal 11 only supports PHP >= 8.3.

Perhaps we should have two releases - one for Drupal 11+ and one for Drupal 9/10? Ideally we'd avoid having two points of maintenance for this module though as I'm currently the only active maintainer!

Whoops!! Sorry. I'll get on this!

I have referenced this issue here:
https://www.drupal.org/project/projectownership/issues/3514042#comment-1... 💬 Offering to co-maintain Media Entity Link Active

Cross referencing these two issues:
https://www.drupal.org/project/media_entity_link/issues/3504411 💬 Offering to co-maintain Media Entity Link Active
https://www.drupal.org/project/media_entity_link/issues/3520583 💬 Offering to co-maintain Media Entity Link as well Active

where danrod: https://www.drupal.org/u/danrod → has also offered to be a co-maintainer

As I am not the project owner I am unable to add further maintainers to the project.

Hi. I know you're busy working on this. Is there any update on getting Drupal 11 support into a stable release?

Any update on a stable release for this? I opened this issue: https://www.drupal.org/project/country_path/issues/3508079 📌 Drupal 11 release RTBC which got closed with a message saying a release was planned for the end of March? Thanks.

Fixed on 2.0.3.

Have managed to reproduce this. The field storage is left orphaned. However would that not be the desired behavior if the field has been used on another media type? I created a new media type called "another_link" and then uninstalled the module. My new media type "another_link" was removed when the module was uninstalled which I'd argue is perhaps not desirable.

My question is what do we expect to happen when the module is uninstalled?

1. Any media type using the field.storage.media.field_media_entity_link should be deleted along with the field storage?
2. A check should be performed to see if any other media types are using the field storage and if so do not delete the field storage or any media types that are using it except for the one provided by the media_entity_link module?

I'm going to set this as maintainer needs more info until we can reach a consensus on what the correct behavior should be!

I've tested this on a clean install and it looks good!

Fixed on the dev branch. Please feel free to test and report back and I'll tag a release!

Not getting anywhere with this one. Tests are not my strong point so setting to Needs Work! Anyone who has a deeper knowledge, feel free to duck in!

@danrod this is fine with me. I think the more maintainers the better so this module doesn't become stale again. I'm only assigned the developer role though which means I can't add maintainers I believe so you might need to create another issue like this one so that @avpaderno can assign you as a developer also, or perhaps we can avoid the waiting times and get you added now? Either way I'm of the opinion that more maintainers is better for the longevity of this module!

Done!!

All done!

Pleased to say this is finally fixed and released!

Thank you.

Hopefully happening soon over here:
https://www.drupal.org/project/projectownership/issues/3514042 💬 Offering to co-maintain Media Entity Link Active

Leaving open (fixed) as per bot's recommendation.

Thank you bot! Merged.

Yes!