Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I'm testing some Spark stuff and also the Edit module for D7 which will be in core D8.
On full node view the body content can't be edited. I've tried the module on multiple other themes and it always works except for Omega 4.x.
In views the content can be edited.
As can be seen on the screeny below all other fields are editable (blue frames).
What does Omega do to this field? I couldn't find anything at first glance in the preprocess functions or theme files that was out of the ordinary.
Comment | File | Size | Author |
---|---|---|---|
#2 | omega-edit-module-bug.png | 13.55 KB | msmithcti |
Screen Shot 2013-03-28 at 11.47.27 PM.png | 27.23 KB | dmsmidt |
Comments
Comment #1
fubhy CreditAttribution: fubhy commentedLooks like we are doing something with the template itself that is not compatible with the Edit module. Thanks for testing. Will take a look next week.
Comment #2
msmithcti CreditAttribution: msmithcti commentedJust had a quick test of this and editing the body works just fine. This was on a fresh install of the latest versions of Drupal and Omega 4, along with Edit and its dependencies. There must be some additional factor affecting this - have you got any other ideas on how we could reproduce this?
Comment #3
dmsmidtTo be sure I create a fresh install as well. But the problem persists.
However, I notice that it only occurs when activating the CKEditor module.
It isn't strictly a dependency, but functionally it is. Did you install it?
Some (not too big of a deal) discoveries:
When the CKEditor is installed the wrapping div gets the class: "edit-type-direct" instead of "edit-type-form".
After toggling the Quick edit mode the class: "edit-app-click-prevent-processed" is added (which shows, some things works ...)
Other than using two dashes in class names instead of one, I can't find any markup changes.
Comment #4
dmsmidtTried everything again on another clean install with latest git versions.
The problem persists.
@fubhy did you manage to have a look at it?
Comment #5
msmithcti CreditAttribution: msmithcti commentedI've had a quick test with both the CKeditor module and WYSIWYG CKeditor. Which are you using? Could you paste the output from
drush pm-list --type=module --status=enabled
here and I will try to reproduce from that.Comment #6
dmsmidtSure: it's basically just a clean drupal 7.22 install with edit and ckeditor from git.
I'm using the CKEdit package (full version 4.1 with sourcedialog plugin) in the libraries folder.
Test it in full node view. Thanks for you effort!
X$ drush pm-list --type=module --status=enabled
Chaos tool suite Chaos tools (ctools) 7.x-1.3
Core Block (block) 7.22
Core Color (color) 7.22
Core Comment (comment) 7.22
Core Contextual links (contextual) 7.22
Core Dashboard (dashboard) 7.22
Core Field (field) 7.22
Core Field SQL storage (field_sql_storage) 7.22
Core Field UI (field_ui) 7.22
Core File (file) 7.22
Core Filter (filter) 7.22
Core Help (help) 7.22
Core Image (image) 7.22
Core List (list) 7.22
Core Menu (menu) 7.22
Core Node (node) 7.22
Core Number (number) 7.22
Core Options (options) 7.22
Core Overlay (overlay) 7.22
Core Path (path) 7.22
Core RDF (rdf) 7.22
Core Search (search) 7.22
Core Shortcut (shortcut) 7.22
Core System (system) 7.22
Core Taxonomy (taxonomy) 7.22
Core Text (text) 7.22
Core Toolbar (toolbar) 7.22
Core User (user) 7.22
Other Entity API (entity) 7.x-1.0
Spark Edit (edit)
User interface CKEditor (ckeditor)
Comment #7
dmsmidtThanks for your concerns with this issue.
For now it seems the latest edit commits solved this issue.
If the problem surfaces again, I'll reopen this issue.
Comment #8
dmsmidt-deleted-
Comment #9
dmsmidtSorry to reopen this issue so quick.
I thought the problem gone, but instead I found out that I stopped the CKEditor from automatically loading.
After enabling autoload of CKEditor, the problem is back.
So what happens:
If the CKEditor loads automatically (Default state setting) for the default input format then the body content on full node view isn't inline-editable.
Without CKEditor or without automatic loading it works fine.
Comment #10
Wim LeersI went over all settings at admin/config/content/ckeditor and I couldn't find an "autoload" setting anywhere?
Comment #11
dmsmidtMy bad, guess that I should've been more clear.
You can find it at: Editor appearance -> Default state
Disabling CKEdit gives the same result btw: it just works.
So I guess there is something tricky happening when Edit checks for CKEditor availability to chose wether or not to enable inline-editing with CKEditor.
Comment #12
msmithcti CreditAttribution: msmithcti commentedThanks for the extra info, I've managed to reproduce this now (the key was editing in full not teaser). I've also narrowed it down to this in Omega's field.theme.inc:
I haven't looked into edit deeply but I can see a couple of places where that class is used to target elements in the DOM. I think targeting a class that hasn't been specifically added by that module is a bit fragile. I'd be interested in what Wim thinks on this?
Comment #13
dmsmidtSplatio thanks for the help. You are correct about that line.
Because of the BEM syntax used by Omega edit doesn't work on some fields.
Instead of the class "field-item" Omega gives the class "field__item" to the wrapping div of a field.
The problematic line in the edit module can be found in EditService.js line no. 276
predicates = predicates.add(direct.find('.field-item'));
As you can see only the class "field-item" is targeted.
So how to move forward? Does edit need to be less strict about the naming? Should Omega get rid of BEM? Or .. ?
Comment #14
fubhy CreditAttribution: fubhy commentedI have to agree with Matt here. Using 'field-item' as a target for Edit is a bit weird. We should file an issue on the Edit module queue and provide a patch that applies an Edit-module specific class to field items. Omega is not going to get rid of BEM ;).
Comment #15
Wim LeersIndeed, Edit assumes that the
field-item
class is always going to be there. Why? Because otherwise it just needs to add *another* class (or some other attribute) to know what to target. And that's precisely what most themers complain about: too many divs, classes and IDs. Edit tries to keep it simple.Comment #16
fubhy CreditAttribution: fubhy commented@Wim: can we use a data attribute instead?
Comment #17
Wim LeersYes, Edit could do that. The reason you suggest that is to avoid this:
Correct?
Comment #18
fubhy CreditAttribution: fubhy commentedYep. To me it feels like a dedicated data attribute would do the trick while not upsetting people like @mortendk :P (tbh. I hate the mess with classes in D7 too). We took a rather aggressive approach in Omega 4.x to tame the mess with classes too which is causing this problem now (we went with BEM and rewriting Core CSS).
Comment #19
richardtmorgan CreditAttribution: richardtmorgan commentedI have exactly this issue with alpha-11. I have this issue in my custom theme, but if I switch to Bartik I also have exactly the same issue. Editing body copy for teaser display is just fine, but in the full view mode the 'edit-app-click-prevent-processed' class is added to my body and it is not editable.
The editing is fine with CKEditor turned off, but the issue appears as soon as CKEditor (4.x) is enabled.
If I switch off default security, and have the editor disabled by default (but togglable on) I can edit in place and switch to CKEditor - so I guess the problem lies somewhere within CKEditor module's security layer??
Comment #20
PI_Ron CreditAttribution: PI_Ron commentedHas anyone managed to get the Edit module & CK Editor 4.x inline editing working with an Omega 4.x subtheme?
It works fantastic when using Bartik, but does not seem to like Omega 4.x
Comment #21
dmsmidtAs a temp fix you can copy Omega's field.theme.inc file to your own theme and change line 24:
$classes = 'field__item field-item ' . ($delta % 2 ? 'odd' : 'even');
(Adding the field-item class).
Comment #22
PI_Ron CreditAttribution: PI_Ron commentedThanks @dmsmidt temporary fix in #21 works great.
Comment #23
sokru CreditAttribution: sokru commentedAnother temp fix is to copy DRUPAL_ROOT/modules/field/theme/field.tpl.php into YOUR_THEME/templates/ and rename to field--body.tpl.php
Comment #24
vulfox CreditAttribution: vulfox commentedCreated an issue on quickedit:
https://www.drupal.org/node/2393063
Comment #25
katrien_w CreditAttribution: katrien_w commentedSame problem but with bootstrap based 'Scholarly lite' team, which does by default add the 'field-item' class. #23 didn't solve my problem. In my case it doesn't seem to be theme related. Bartik doesn't work either.
Weirdest thing is that I have one view where the body field (full display) can be edited (save button appears) and another view (exactly the same except for different date filter) where the body field cannot be edited because NO save button appears. As soon as I try to edit console shows "profiles/spark/modules/contrib/ckeditor/ckeditor.config.js?&t=E0LB:40 Uncaught TypeError: Cannot read property 'theme' of undefined".