ansonargyris / moodle-atto_oembed Goto Github PK

I am wondering about your reasoning and use cases for the db/access.php. As a consequence of having it like now, your plugin is only available to users who are enrolled in a course (so it is not displayed when the user is editing own profile or composes a blog post).

Do you really need to check for permissions? Is there a valid use case that the plugin should be available for certain roles only? Would not it be better to simply remove the file and the relevant permission checks?

with timestamp update it once a day

All the code that refers to defaultflavor seems to be a forgotten relict of copy & paste.

This has been originally open in my comment at https://moodle.org/plugins/view/atto_oembed however I think this will be better place to discuss it.

Thanks Erich for sharing the plugin with the community. I must admit I
am not quite sure about the actual benefits of it though. Thing is, to
use the oEmbed protocol this way, you end up with the provider's HTML
code fragment injected into the text body. Many of the supported
providers use <iframe> to display their contents. As far as I know, to
be able to save and use HTML text with <iframe>, the trusted content
feature $CFG->enabletrusttext must be enabled and properly set up at the
server. Admins should be well aware of all the consequences of such
setup before attempting to allow it. That is also why implementing
oEmbed as a filter is imho better (and safer) solution.

Maybe you could re-think the overall design and purpose of this Atto
plugin and turn it into a user-friendly frontend for the oEmbed filter
functionality?

I would like to discuss these concerns more prior approving this plugin
here. Thanks for your understanding and the patience with the approval
process.