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).

Quick edit active on node view

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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fubhy’s picture

Looks 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.

msmithcti’s picture

FileSize
13.55 KB

Just 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?

dmsmidt’s picture

To 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.

dmsmidt’s picture

Tried everything again on another clean install with latest git versions.
The problem persists.

@fubhy did you manage to have a look at it?

msmithcti’s picture

I'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.

dmsmidt’s picture

Sure: 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)

dmsmidt’s picture

Status: Active » Closed (works as designed)

Thanks 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.

dmsmidt’s picture

-deleted-

dmsmidt’s picture

Title: Body content can't be inline-edited with Edit module. » Body content can't be inline-edited with Edit module and CKEditor
Status: Closed (works as designed) » Active

Sorry 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.

Wim Leers’s picture

I went over all settings at admin/config/content/ckeditor and I couldn't find an "autoload" setting anywhere?

dmsmidt’s picture

My 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.

msmithcti’s picture

Thanks 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:

 -   $classes = 'field_item ' . ($delta % 2 ? 'odd' : 'even');
 +   $classes = 'field__item ' . ($delta % 2 ? 'odd' : 'even');

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?

dmsmidt’s picture

Splatio 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 .. ?

fubhy’s picture

I 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 ;).

Wim Leers’s picture

Indeed, 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.

fubhy’s picture

@Wim: can we use a data attribute instead?

Wim Leers’s picture

Yes, Edit could do that. The reason you suggest that is to avoid this:

And that's precisely what most themers complain about: too many divs, classes and IDs. Edit tries to keep it simple.

Correct?

fubhy’s picture

Yep. 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).

richardtmorgan’s picture

I 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??

PI_Ron’s picture

Has 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

dmsmidt’s picture

As 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).

PI_Ron’s picture

Thanks @dmsmidt temporary fix in #21 works great.

sokru’s picture

Issue summary: View changes

Another temp fix is to copy DRUPAL_ROOT/modules/field/theme/field.tpl.php into YOUR_THEME/templates/ and rename to field--body.tpl.php

vulfox’s picture

Created an issue on quickedit:
https://www.drupal.org/node/2393063

katrien_w’s picture

Same 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".