Actually breaks W3C compliance. When not filled, it is adding an empty target attribute which is not valid.
target=""
@hongpong
I really like your suggestions.
The weight feature is definitely something we need to add. That could be problematic for some projects in case plugins are affecting the same data and the order matters.
I also like the idea of adding API versions in there, that would give the module more flexibility for the future and be able to support different plugins versions at the same time. Not sure if this will block this issue much longer though. When I needed to do my migration 4 years ago, that plugin system was definitely a big missing piece to be able to actually use that module.
The patch doesn't seem to work with Ckeditor5, it gave me so much trouble to find out that it was the patch messing up the upgrade to Ckeditor 5.
Didn't do the tests.
Just added the None option. Very useful feature.
Wa had the same issue, hook #3 seems to do the trick, thanks!
I would probably set the cache to only be set on the query parameter and not the whole URL. That way we have a unique cache when the parameter is not there.
$form['#cache']['contexts'][] = 'url.query_args:' . $input_name;
PS: I didn't test this code, just followed the documentation:
https://www.drupal.org/docs/drupal-apis/cache-api/cache-contexts →
Merge requests done, to change method into a static function to avoid the crash when the call is done using batch.
phjou → created an issue.
Merge request done, the change is very simple and make complete sense to check for a value to be set before manipulating it.
Thank you for noticing, I just fixed it on the project page and will push the README change.
Thanks for the patch, it has been commited.
I will also remove Drupal 8 & 9 at the same time.
Adding Drupal 11 and removing Drupal 8 & 9
Drupal 11 has been released, just merged the Drupal 11 compatibility to avoid blocking people to use this module on newer version of core.
This has been fixed as part of 📌 Automated Drupal 11 compatibility fixes for link_no_protocol Needs review
Fix has been deployed on the dev branch. The solution has been merged with 🐛 Module doesn't work for a url with 'www' prefix. Active
Please feel free to reopen if the issue is still happening on the dev branch. I'll create a release with teh fix in a while to let you some time to test the fix.
Ok I've been investigating this at the same time as 🐛 PHP error for url with trailing slash Active that is related since the same patrt of the code is responsible for crashing.
I've released a fix on the dev branch. Feel free to reopen the ticket if the issue is still happening.
The issue has actually has been fixed with the Drupal 11 support. Thank you.
It seems like a fait fix to me. I merged it.
Thanks, the patch has been merged.
Added Drupal 11, but also removed support for Drupal 8 & 9.
I confirm I have the same issue, I can delete the workflow state, and then the nodes that were using it have a broken revisions list page.
Patch attached
It would be best practice to keep the MediaInterface and just fix the use to be based on core:
Drupal\media\MediaInterface
Works well, thank you!
Did anybody found how to do that?
I did try and the block with the paragraph is not even showing up at all for me...
This module was supposed to stay quite simple like the Search Block from Core. So I am not sure if this module should include an advanced feature like this.
But you probably can use this module to achieve it:
https://www.drupal.org/project/views_exposed_filter_blocks →
Thank you! The schema has been merged.
@slowflyer Yes your latest commit did the trick, the warning is now gone. Thank you!
Merge request was failing for some reasons. I added the file to the branch directly.
Thank you everyone.
Doesn't need any dependency to work except for token. You could use it on a plain text field containing HTML.
It seems to work for me.
I am not sure that would work in all cases, if someone had other fields in the media and want to display them inside the modal, it might be more appropriate to be larger than the iframe sometimes.
Ok pull request done.
Patch #43 worked for me, it allowed to unblock the situation on both editing, and display on the frontend.
Ok I pushed a new change reverting the encoding to use a single replace instead. It seems some characters like & are already & but the apostrophe is not. So the previous change broke videos with other special characters.
If we were directly using $dom->saveHTML then the issue would not even occur but since it creates problems with the css placeholders we cannot get rid of the str_replace approach and use saveHTML.
So I went down the road to use another replace to handle that case. The code for the apostrophe is not even ' but ' which I find strange as well.
The str_replace approach might have unexpected issues that we are not aware of, but so far the branch worked very well in that version and I could get all videos that I tested in autoplay.
Ok changes pushed to the merge request branch.
The patch works for me, the video is playing automatically now. Thank you!
I do experience the same issue when using the rest api endpoint.
The patch was not working anymore on drupal 11, rewrote the patch and also fix a couple other comments since the patch was fixing that too.