Better Formats recently added some additional options on the Body field/Text Area settings (please see attached).
This option, when not set appears to hide the entire Text Editor from all other users except Admin. Please my comment here Please see attached for screenshot of the problematic options.

#5 better_formats.zip14.16 KBJumoke
better_formats_why_this.png22.5 KBJumoke


dragonwize’s picture

Status:Active» Postponed (maintainer needs more info)

I cannot reproduce this. I would need to know more about your exact setup and all options you have set.

Jumoke’s picture

Status:Postponed (maintainer needs more info)» Active

I was able to easily replicate this issue on a brand new drupal installation with WYSIWYG and Better Formats configured to give Full_HTML and Filtered_HTML to some users. And with a default Text Editor (Filtered_HTML) set on 2 content types . Without those extra options set (see my attached screenshot in my previous posts), the Text Editors does not show for all other users except user1. No other special configurations. Please check this.

dragonwize’s picture

Priority:Critical» Normal
Status:Active» Postponed (maintainer needs more info)

Your description is very vague which makes it hard to follow. There is more to it as you point out:

configured to give Full_HTML and Filtered_HTML to some users

Configured how? to what users?

with a default Text Editor (Filtered_HTML) set on 2 content types

Default Text Editor (Filtered_HTML)? What does that mean? A WYSIWYG editor? Which method was used to make it default?

broeker’s picture

I can confirm and duplicate:

We did an upgrade over the weekend to the latest Drupal core, along with several modules including Better Formats to Beta 1.

The WYSIWYG editor immediately stopped working for all users except User 1.

If we disable Better Formats, everything is working again.

As far as our setup it is simple: only a few internal editors so all text fields use Full HTML and all users have access to that format.

No script errors, no page errors, no Drupal log errors, and no Apache log errors that I see. The editor just disappears until BF is disabled.

Thanks, let me know if you need more setup info.

Jumoke’s picture

new14.16 KB

Hi dragonwize, thank you for your time, however, I believe I have the regular settings expected on a Text Editor setup. Nothing special, so I am not sure what other explanation you are looking for outside of what I have given.

What I have done "for now" (cos I am so overwhelmed with work to figure this out now) is to revert Better_Formats back to the earlier working dev version I had before. And i was able to get my Text Editor showing and highly esteemed Clients/Content Editors happy again.

I'll be back in a few days to check the code hopefully i can detect the trouble.

PS to anyone in a desperate situation: Attached is the dev version that brings no sorrow :)

rocketeerbkw’s picture

Version:7.x-1.0-beta1» 7.x-1.x-dev
Status:Postponed (maintainer needs more info)» Active

These are the exact steps I took to reproduce the issue:

  1. Install Drupal 7.15 (standard installation profile)
  2. Create test user (no extra roles)
  3. Give authenticated users permission to create Articles
  4. Install WYSIWYG 7.x-2.x-dev
    • Install CKEditor
  5. Install Better Formats 7.x-1.x-dev
  6. Add CKEditor to Filtered HTML Format
  7. Go to /node/add/article as user1, see that CKEditor shows up
  8. Go to /node/add/article as test user, see that CKEditor does not show up

A few things to note:

mrfelton’s picture

Confirming the issue too. Pretty much the same steps as @rocketeerbkw

mrfelton’s picture

I found that giving the 'Show format selection for nodes' permission fixes the issue. Roles that do not have this permission are unable to use the WYSIWYG editor, even if it's configured to allow only one input format which the role has access to, and to have that format set as the default.

Jumoke’s picture

But that's wrong. What if admin doesn't want to give format selection for nodes at all?!

nevergone’s picture

My site is affected, first bad commit is 82de0201ba214b17cd6dfd89f6dec09c834c6cdf

mrfelton’s picture

@Jumoke - yes, I know! That's why I pointed it out. One of our main reasons for using better formats is so that we hide the format selector as it just confuses people.

rocketeerbkw’s picture

I have a patch for WYSIWYG which fixed this issue for me

berenddeboer’s picture

Status:Active» Needs review
lsolesen’s picture

I can confirm that applying the patch from #23 in #934976: Provide method to hide input format fields without disabling WYSIWYG also fixed the issue for me.

jenlampton’s picture

Status:Needs review» Closed (duplicate)
igorik’s picture

Status:Closed (duplicate)» Active

I dont't think that this is a duplicate of that.
Confirming that patch from #23 works nice.

fonant’s picture

Issue summary:View changes

I have found that standard Better Formats, with WYSIWYG 7.x-2.2, plus the wysiwyg-one-format.934976.23-alt.patch patch from #934976-23: Provide method to hide input format fields without disabling WYSIWYG fixes this problem.