Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Alpha5 displayed the unprocessed "raw" entity field value in the edition form, Edit 7.x-dev displays the whatever HTML is currently being rendered by the browser.
Which is totally wrong when we assume field may not have actual html but something that was processed in the client-side, it can be a canvas, a chart, or mathjax.
Comments
Comment #1
wundo commentedHow to reproduce:
1) Enable edit module
2) Enable mathjax module
3) Create a node with Latex in the body
4) try to inline edit the body
Comment #2
nod_More descriptive title. I am not familiar with mathjax module.
Please check with mathjax module maintainer to have some details as to how this module changes the default field markup. Currently we're not supporting modules that changes the default field markup (Display Suite is not yet supported for example).
Comment #3
wundo commentedAFAIK this is not a Support request, Mathjax is "like an input filter" but it runs in the client-side replacing LaTex code with the proper image.
This is not Mathjax related here is a few steps to reproduce without relying in Mathjax:
This is something that didn't happen in Alpha5
Comment #4
wim leersAll issues are support requests until proven to be bugs.
This only happens when you start editing a text field that has "text processing" enabled, I suspect?
Comment #5
wundo commentedWhat "more info" you need?
Do you have any doubt about the steps posted in 3?
If you don't want to invest five minutes to follow the steps I posted in 3, you will have to take my word that it's a bug, if you're marking as needs more info please specify which info do you need.
Comment #6
wim leers#5: My apologies. I simply knew that it was working well while I was working on it. But somewhere in the forward porting of D7 Edit to D8 Edit, nod_ must have removed the logic to deal with
rerenderProcessedTextURLand the different filter types.The solution is to bring back that functionality (as it exists in D8), require D7 filter modules to indicate the type of their filters (like they will have to do in D8) and then all will be well. Mathjax would have to indicate their filter type was FILTER_TYPE_TRANSFORM_IRREVERSIBLE. I think it would be okay to assume FILTER_TYPE_TRANSFORM_IRREVERSIBLE if no filter type is set.
I agree, this is critical.
Comment #7
wim leersComment #8
wim leersWill work on fixing this.
Comment #9
wim leersWorking on fixing this. Fix will be committed later today.
However, the Mathjax module is not quite kosher… it should be a filter, but it is not. It's simply loading the MathJax JS on *every* page! Hence, it is impossible to do any reasoning, and hence it's impossible to make Edit work with the MathJax module. The simplest way to solve this is by adding a filter that does nothing to MathJax, so that modules like Edit module can at least reason about it.
Comment #10
wim leersFixed: http://drupalcode.org/project/edit.git/commit/2934168
This commit also fixed the loading of "external" CKEditor plugins (i.e. those that are not part of the CKEditor build). This was broken and would surely cause problems in production, because e.g. the "drupalbreaks" plugin that CKEditor ships with to support Drupal's teaser indicator wouldn't load anymore.
Comment #11.0
(not verified) commentedBetter description