Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wishlist: Get rid of the need for a patch #13

Open
agwells opened this issue Jun 16, 2016 · 0 comments
Open

Wishlist: Get rid of the need for a patch #13

agwells opened this issue Jun 16, 2016 · 0 comments
Labels

Comments

@agwells
Copy link
Contributor

agwells commented Jun 16, 2016

It would be great if the plugin didn't need you to patch htdocs/view/blocks.php. I think the reason it has this, is because the PluginBlocktype::get_instance_javascript() method only allows you to load up Javascript files that are stored within the blocktype's directory (e.g. htdocs/artefact/cloud/blocktype/box/js/...). But each of these blocktypes relies on the same couple of JS libraries, so reasonable these are stored at the artefact level (htdocs/artefact/cloud/lib...) instead of being duplicated under each blocktype.

I think I see a workaround for this, though. In looking through the implementation of PluginBlocktype, it seems that get_instance_javascript() can either mention files by name alone, in which case they must be located under the blocktype, or you can give a full URL to the file. Which means you might be able to work around this problem by making the cloud blocks use get_instance_javascript with the full URL to their needed JS libraries, calculated dynamically using $CFG->wwwroot.

I haven't had a chance to test this, though, so it still may not work. In which case, Mahara core might need a patch to improve the blocktype API to accommodate this situation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants