Hi. Also still interested in becoming a co maintainer of this project if you've had no reply from the other maintainers. Thank you!
Hi. Sorry. I'm away this week but yes very much interested in still becoming a co maintainer on this project! Thank you.
MR10862 applying cleanly to Core 10.5.2 and 11.2.3!
Changing status to major as we're currently unable to edit content on some sites due to this issue.
I can get: https://git.drupalcode.org/project/entity_usage/-/merge_requests/143.diff to apply using composer patches with Drupal 11.2.3 and entity_usage 2.0.0-beta-24. What version are you using @bhogue?
Okay. An update! Remove all patches and merge requests related to this issue in your project. It is my belief that as of core 11.2.3 this issue has been fixed elsewhere. With no patches or merge requests applied I no longer see the empty langcode wrapper on my site? Can anyone else confirm if this is true? If so this issue can be marked as fixed even though it wasn't our work here that resolved the issue. I hope this is the case as I really don't like the solution we are applying to resolve the initial issue.
Think this patch should work on 11.2.3.
Patch doesn't apply. There seems to be a few changes between the system.module file in 11.x and 11.2.3.
Here's a patch that applies to 11.2.3.
And now tests are passing. This whole issue had got into a pickle but I think it's good to go now!
I think this needs a fresh branch and merge request. I'll take a look
The failing tests on my merge request fall outside the scope of what I've changed so I presume they also fail on the dev branch? I can try and fix them here but feels out of scope for this issue. Advice from a maintainer?
I've not heard anything regarding this offer so escalating to Drupal.org project ownership for next steps.
Hey Rajas. Changes look good on first glance. I've opened a merge request:
https://git.drupalcode.org/issue/file_browser-3451080/-/merge_requests/1/
Daniel and I will review and merge if we can (we should have permission to do so). Then we aim to fix the tests which seem to have broken again and hopefully by that time I will have become a maintainer and we can roll this out to a stable release.
d.fisher → created an issue.
d.fisher → created an issue.
d.fisher → created an issue.
I like the idea that the URLs could be provided as a token for inclusion directly in the llms.txt. That makes a lot of sense. I'd initially linked to the xml sitemap from our llms.txt but there were two reasons I thought a markdown sitemap would be a good idea. 1. Less expensive to parse. 2. Can link directly to the .md versions of the pages (again less expensive to parse). In our llms.txt we've manually linked to key service and solution pages with much more context but wanted to provide a dynamic complete list of URLs should any LLMs wish to crawl, index, or train from any of our content.
The module I've created was a quick first pass and I'd be very open to developing it further in collaboration with yourself and others. I agree it feels separate from the markdownify module but does feel as though it would fit well in the LLM Support recipe. In terms of security coverage, I can opt projects into security advisory coverage, but just have to wait for 2 weeks. I literally wrote and published the module yesterday.
I'd be more than happy to make yourself and any others involved in the LLM Support recipe or Markdownify maintainers of the mdsitemap module in order to shape it to work for all of our use cases.
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?
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?
- Any media type using the field.storage.media.field_media_entity_link should be deleted along with the field storage?
- 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!