Problem/Motivation
Given we already have an ecosystem of providers and the infrastructure to transform user input into tangible embeds, I think a simple integration to allow these embeds to be put amongst content within a WYSIWYG would be useful. This is definitely optional submodule territory.
It should be considered as a compliment to existing solutions such as insert_video, wysiwyg_mediaembed and video_filter (which provide similar functionality) for users who already require video_embed_field installed, have created video_embed_field plugins and who would rather not install multiple overlapping modules.
Proposed resolution
Create an optional sub-module to embed videos.
Remaining tasks
Patch.
User interface changes
Additional module and user interface for WYSIWYG integration.
API changes
None to base module.
Data model changes
None to base module.
Comment | File | Size | Author |
---|---|---|---|
#46 | 2686171-wysiwyg-integration-46.patch | 40.72 KB | Sam152 |
#46 | interdiff.txt | 799 bytes | Sam152 |
#44 | 2686171-wysiwyg-integration-44.patch | 40.66 KB | Sam152 |
#44 | interdiff.txt | 1.03 KB | Sam152 |
#34 | 2686171-wysiwyg-integration-34.patch | 38.45 KB | Sam152 |
Comments
Comment #2
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedProgress thus far.
Comment #3
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedComment #9
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedProgress.
Comment #15
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedFully functioning prototype. Needs a good security and functionality review + tests.
Comment #16
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedResponsive implementation.
Comment #17
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedLeft to do:
Comment #18
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedAlso automatically add the filter when the button is added.
Comment #19
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedFixes some JS bugs with drag and drop.
Comment #20
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedWorking Kernel test for the filter.
Comment #26
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedTest fixes.
Comment #30
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedTests added and security reviewed. Need a green build + review.
Comment #34
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedNo php7 features.
Comment #35
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedOpened a follow up for the @todo, #2687077: Consider making 'downloadThumbnail' a public method on ProviderBase to account for WYSIWYG usage. .
Comment #36
benjy CreditAttribution: benjy at PreviousNext commentedMainly small small stuff and a few questions, looks pretty good.
We fire the same event both before and after save?
I actually wonder why the event wouldn't be triggered from the modalSave method, in case it was ever saved in another way outside of addCommand.
Missing Contains \ at the start.
Why getUserInput instead of getValue()? From the docs:
Missing docs.
Pretty nifty that cores apis allow this really.
Should link to the follow-up.
Presuming this goes straight to the plugin to retrieve it, does this have the same level of permissions wrapped around it as normal usage?
Formatter manager doesn't have its own interface to type-hint against?
there is an extra s in wysiwyg
Missing newline.
Double newline.
extra s here as well.
There are no extra permissions to use your module?
Comment #37
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commented1. Yep, I think this is right from what I've seen. It's like taking a snapshot of the content, for the undo/redo feature.
2. Good point, but the addCommand provides more context (the editor), so unlikely this could happen accidentally. It's only called because we pass it to Drupal.ckeditor.openDialog, not because it's a property on the plugin which is meaningful.
3. Fixed.
4. I had a look into this. Nothing is returned from getValues, I suspect this is to do with modal API. The other core plugins are consistent with this. I'd like to harden this if possible. Do you know if user input is safe to pass to #default_value? I'd suspect so.
5. Done.
6. Not sure if it was intentional. Seems more like abuse to me, lol.
7. Done.
8. Normal usage for the field is defined by the entity that uses the field. I think we're using the same concept here and saying it's defined by the permissions of the text format.
9. Not that I can see.
10. Fixed.
11. Fixed.
12. Fixed.
13. Fixed.
14. It doesn't define any, no.
Comment #38
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedI've added some additional hardening. Since anon users always had access to plain_text, they could visit /video-embed-wysiwyg/dialog/plain_text to get the form and make submissions which triggered thumbnail downloads, potentially allowing them to cause a lot of network traffic/fill up space.
This check ensures that you must have access to a filter that the admin has specified actually works with VEW.
Comment #44
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedTest fixes.
Comment #45
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedComment #46
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedFixing as per feedback.
Comment #48
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedThanks for the review.