When using panel's custom content, dragging atom's into the textarea works fine (with some custom code to trigger the library of course). But once saved the atoms will not appear on display, only their sas code.
That is because the filter will run to replace the placeholder to a sas placeholder. But then the mee_field_attach_view_alter will run, and that seems to not work when its a panels custom content. It will only detect the content from the node.
Either use a panelized page where you can add a new custom content, or simply make a panels page and add a new custom content. Drag atoms into the wysiwyg editor there. Then once some atoms have been dragged, save the custom content, and go to a display.
The atoms will appear in the SAS format instead of being rendered.
Comments
Comment #1
nagy.balint commentedComment #2
nagy.balint commentedA patch like this could work to solve the problem.
Comment #3
nagy.balint commentedHere is a more complete patch.
It handles the case where the filter is disabled for widget.
I think the only issue could be that here we dont have any field settings, and maybe we wont have any. So resource manager is missing and default content settings.
But at least this makes it work, and the extra form alter will make the dnd appear on the form as well.
Comment #4
nagy.balint commentedI know about scald_panels_dnd module (thanks for that), however i think it would be best to eventually integrate it into the main module since that is just a few hooks to add dnd to certain places.
Also it was already done in core before for the edit module, so why not have it also for the panels module.
Comment #5
nagy.balint commentedComment #6
nagy.balint commentedActually it turns out that in IPE the modal has button tags instead of input tags, so needed to modify the js that prevents the continue click on plupload when its empty, and waits with the continue button when the upload is still in progress.
Comment #7
nagy.balint commentedNo objections in 10 days. And it seems to work fine.
Will anyways receive a bit more testing.
Comment #9
aron novakI reviewed the code, I have one notice, what you can consider.
We have this condition:
is_string($content->content)Can we generalize the solution for render arrays too, is it meaningful? Or is it something that simply won't happen?
Also, a little coding standard hiccup was introduced:
Comment #10
aron novakComment #11
nagy.balint commentedThe custom content pane's $content->content is always a string, so the idea was there to detect when its a custom content pane, and then do the process on it.
For fieldable panel panes it also works since its field based.
The only way it would not work is that if its a custom pane with some ckeditor enabled textarea fields. But then we would need to loop on all items in the render array and do it for every textareas that are ckeditor enabled, but also we would have the same issue as with the custom content pane that there are no settings possible, so the user cannot say which textarea should have dnd enabled and mee enabled and which one should not.
So in this issue the goal was just to fix the case with the custom content pane, and then if there will be further need, there can be further issues about it.
Creating another issue about the coding style error.