After multiple attempts to work around its flaws, the time has come to remove the Zooming Image Tool, one of the built-in templates for the HTML block. You can find out more in the DEPR ticket, but the gist of it is that hasn’t worked in so long (since at least before Olive, possibly earlier), that this DEPR is accepted effective immediately. The template will be removed from master today and will not be present from Sumac.1 onwards.
We know some operators still make use of this via their own workarounds, but that’s just it: there’s no way to support those workarounds officially as the template stands now. As per the DEPR issue description, we think the correct way to support this in the future would be for somebody to reimplement it as its own XBlock.
Hi @arbrandes Just an FYI, someone flagged this for me today, but I have this tool actively working in live courses at MIT and on edX.org that use the latest versions of the platform. I have had it working for all 11 years. If you want to talk more about it, let me know.
Also, an important part of the DEPR process is to learn things that you don’t know from the community before moving forward. It does not feel right to jump to removal before getting approval. You can state that you want to skip the 6 month waiting period, but there should be room for discussion if you missed something. Thank you.
I’m reasonably certain this is because there is additional customization that was done to the MIT instances in question, as well as at edx.org. The way the tool is currently implemented in master and the last few Open edX releases not only does not work, it can’t be fixed: the code is out of the community’s control, as the javascript file in question is hosted in an edx.org course. The only way for Open edX to support this feature officially going forward would be to have it become its own XBlock.
Note, in any case, that the Zooming Image Tool as it currently exists is just a template for the HTML block: removing it has no effect on existing content. It also doesn’t make a huge difference to platform operators (such as MIT) that want a working version: they can just host a working version of the script (which they would have had to do anyway to get this to work) and recreate the template, which is very small.
A fair point, though I should say that the DEPR issue has been open for two years. There were multiple unsuccessful attempts made to get this to work, and there were no objections to removing the tool the many times the topic was brought up in the community, including today during the Sumac release meeting. As a matter of fact, the PR to remove it has been approved for months.
That said, we did miss making the official DEPR announcement here in the forum in that time. We figured it would just be a formality since the code has evidently not worked for so long - hence the immediate acceptance and removal. I’m genuinely surprised to hear that people are using it, which proves your point, @robrap. But, on the other hand, I’m equally surprised that in 2 years nobody that actually has this working has stepped forward given the multiple bug reports and attempts to fix it.
Which brings me to the crux: I’ll be glad to hear alternatives, but I still don’t see how we can support a feature that depends so directly on code being hosted by a third-party.
Your plan might be sound, but I’m just not clear enough on this issue to understand if the timeline is ok. You mention that those that have it working are using workarounds. What I don’t know is whether those workarounds are dependent on the existence of the code you want to remove, or if no one is using this code and it will have no affect on anyone. If it will have an immediate affect, it needs a longer timeline for people to respond.
Alright, at Axim we came up with what we hope is a best-of-both-worlds scenario: a reimplementation of the tool template that inlines everything, so we can a) fix the feature, while b) not having to write a whole XBlock for it.
The distinction between what needs an xblock and what is a template is an important one to consider.
I suspect a few xblocks we have are basically just iframe tools or slight modifications to some other block. Google calendar and google documents come to mind as being just text blocks with a slight editor layer on top of them.
I don’t know that this example requires an overcorrection to make other blocks into templates of a well maintained / fully supported block but it is something to keep in mind as we look to make improvements to the add components workflows via active projects: LTI Redesign, Visually Configure Course Components, Libraries Post-MVP updates etc
