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 http://drupal.org/node/1703078#comment-6317404. Please see attached for screenshot of the problematic options.

CommentFileSizeAuthor
#5 better_formats.zip14.16 KBjumoke
better_formats_why_this.png22.5 KBjumoke

Comments

dragonwize’s picture

dragonwize commented
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

jumoke commented
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

dragonwize commented
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

broeker commented

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

jumoke commented
StatusFileSize
new better_formats.zip14.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

rocketeerbkw commented
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

mrfelton commented

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

mrfelton’s picture

mrfelton commented

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

jumoke commented

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

nevergone’s picture

nevergone
Primary language Hungarian
commented

My site is affected, first bad commit is 82de0201ba214b17cd6dfd89f6dec09c834c6cdf

mrfelton’s picture

mrfelton commented

@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

rocketeerbkw commented

I have a patch for WYSIWYG which fixed this issue for me http://drupal.org/node/934976#comment-6438604

berenddeboer’s picture

berenddeboer commented
Status: Active » Needs review
lsolesen’s picture

lsolesen commented

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

jenlampton
she / her
commented
Status: Needs review » Closed (duplicate)

I think this may be a duplicate of #1687956: wysiwyg not shown when no permission to select text format

igorik’s picture

igorik commented
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

fonant commented
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.

igorik’s picture

igorik commented

I have this problem again, with Editor module...

steinmb’s picture

steinmb commented
Status: Active » Closed (cannot reproduce)

Unable to reproduce. Could have been related to the editor not loading if only a single input format is available. That could explain why admin did not see this. Current 7.1.x or 7.2.x doe not have this problem.