I've been developing a site with the help of one the clients staff. She was editing content this morning just fine. This evening, she can no longer edit pages or any other content because the body is disabled with the message "This field has been disabled because you do not have sufficient permissions to edit it." I have verified that admin is the only one who can still edit content

As far as I remember, the only activity today was checking for updates (none performed), and editing existing content. In an attempt to fix the issue, I removed the WYSIWYG editor profiles. This had no effect. Whether related or not, when I tried to recreate the profile, I was informed that the name and machine name were already in use.

Is this database corruption? If so, where do I look to fix it? If not, I'm open to ideas.


jontyler’s picture

UPDATE: I have discovered (according to the log) that the client has not edited anything since 2-11-2011, so she wasn't in this morning. However, after the last edit she made, the log starts recording missing ctools css in the log.

TYPE page not found
DATE Sunday, February 13, 2011 - 20:57
USER Anonymous (not verified)
LOCATION http://dev.iesmarion.org/sites/default/files/ctools/css/ee5de70db6367b3fa3a6c72f261fb014.css?lgfgpn
REFERRER http://dev.iesmarion.org/
MESSAGE sites/default/files/ctools/css/ee5de70db6367b3fa3a6c72f261fb014.css
SEVERITY warning

Am I wrong in assuming that nothing changed in content should affect the framework? The next entries in the log start showing php errors.

TYPE php
DATE Sunday, February 13, 2011 - 20:57
USER Anonymous (not verified)
LOCATION http://dev.iesmarion.org/sites/default/files/ctools/css/ee5de70db6367b3fa3a6c72f261fb014.css?lgfgpn
REFERRER http://dev.iesmarion.org/
MESSAGE PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'rounded-corner:#mini-panel-interfaith_sidebar' for key 'PRIMARY': INSERT INTO {ctools_css_cache} (cid, filename, css, filter) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => rounded-corner:#mini-panel-interfaith_sidebar [:db_insert_placeholder_1] => public://ctools/css/eec1854fae624a591e7c34fe6498c373.css [:db_insert_placeholder_2] => .t-edge, .b-edge, .l-edge, .r-edge, .wrap-corner { position: relative; /* hasLayout -1 ? For IE only */ zoom: 1; } #mini-panel-interfaith_sidebar .t-edge { background: url(/sites/all/modules/panels/plugins/styles/corners/shadow-t.png) repeat-x 0 top; font-size: 1px; } #mini-panel-interfaith_sidebar .b-edge { background: url(/sites/all/modules/panels/plugins/styles/corners/shadow-b.png) repeat-x 0 bottom; font-size: 1px; } #mini-panel-interfaith_sidebar .l-edge { background: url(/sites/all/modules/panels/plugins/styles/corners/shadow-l.png) repeat-y 0 0; } #mini-panel-interfaith_sidebar .r-edge { background: url(/sites/all/modules/panels/plugins/styles/corners/shadow-r.png) repeat-y right 0; } #mini-panel-interfaith_sidebar .wrap-corner { background: #fff !important; } #mini-panel-interfaith_sidebar .wrap-corner .t-edge, #mini-panel-interfaith_sidebar .wrap-corner .b-edge { height: 11px; } #mini-panel-interfaith_sidebar .wrap-corner .l, #mini-panel-interfaith_sidebar .wrap-corner .r { position: absolute; top: 0; height: 11px; width: 11px; background-image: url(/sites/all/modules/panels/plugins/styles/corners/corner-bits.png); } #mini-panel-interfaith_sidebar .wrap-corner .l { left: 0; } #mini-panel-interfaith_sidebar .wrap-corner .r { right: 0; background-position: -11px 0; } #mini-panel-interfaith_sidebar .wrap-corner .b-edge .l { background-position: 0 -11px; } #mini-panel-interfaith_sidebar .wrap-corner .b-edge .r { background-position: -11px -11px; } #mini-panel-interfaith_sidebar .wrap-corner .r-edge { padding: 5px 24px; } #mini-panel-interfaith_sidebar div.admin-links { margin-top: -14px; margin-left: -12px; } #mini-panel-interfaith_sidebar .panel-separator { background: url(/sites/all/modules/panels/plugins/styles/corners/shadow-b.png) repeat-x 0 center; font-size: 1px; height: 30px; } #mini-panel-interfaith_sidebar .rounded-corner { margin-bottom: 1em; } [:db_insert_placeholder_3] => 0 ) in ctools_css_store() (line 88 of /home/iesmarion/www/dev/sites/all/modules/ctools/includes/css.inc).

Although CSS errors shouldn't be locking a user out of editing a field, this is starting to concern me.
Lastly I'm getting the error "Missing text format: tinymce." in the log. I deleted this text format trying to correct the initial problem, but it looks like it didn't get deleted correctly. in fact I have verified that the 2 deleted text formats still exist in the dru_wysiwyg table.

I'm now noticing that content is missing from the front and other pages, and just seems to be randomly disappearing. I have searched the KB and forums, but I can't find anything like this. Should I abandon D7 and recreate the site in D6? It doesn't seem like it's stable if this sort of thing can just happen for no reason.

I am really looking for some help here. If anyone has any idea, I'm open to suggestions.

stkrzysiak’s picture

CSS shouldn't disable fields, but it could grey them out and make them 'disabled'. I'm actively working on this and will update accordingly.

stkrzysiak’s picture

The fix for me was input formats, aka text filters. Stumbled upon it via http://drupal.org/node/1034064

jontyler’s picture

Yes, I found that post as well. Unfortunately, removing the custom filters (CKeditor & TinyMCE) did not correct the problem, but introduced another issue (see my previous post).

I have restored from a backup I believe to be before the issues began. I have backups of the files/sql with the problem if anyone has a suggestion. I will be keeping a very close eye on the site from now on.

davidneedham’s picture

A little late maybe, but for the future reference of anyone coming across this, filters mean text formats but do not mean WYSIWYG. Text formats are the things like plain text, filtered text, full text (defaults in Drupal 7). WYSIWYG are things like CKEditor, TinyMCE, etc.

I saw this error when the client tried to edit content that had been previously set to use a format they were now not allowed to use. Fix: Give permissions to that role to use the text format, or go back through all of your content that may be using the incorrect text format and change them manually. No fun, I know, but it works.

grissly’s picture

I was having a similar problem. I don't believe it was as spontaneous as what the OP described. But I didn't notice it until the client brought it up after his training on how to edit content on the site.

Anyways, the above explanation of filters and permissions is what helped me to quickly fix this problem. I just set the filter to one that the client had permissions to use. The change only needed to happen to 3 nodes (all the ones of a specific content type). Thanks David!


borntosucceed’s picture

Is there a way via SQL or other to find out which content might be using the wrong text format?

drupalshrek’s picture

Thanks davidneedham. I had this problem, and it was indeed the fact that the particular role did not have authority to use the text format "Full HTML".

Please fill in my Learning a foreign language questionnaire if you have a moment.

Rob de Koter’s picture

I thought I was getting nuts....

rexgonzaga23’s picture

This worked ..

peteruithoven’s picture

Just a tip for others.
One easy mistake to make is leaving the default value on a text format that the visitor doesn't have the rights to work with.

leanderl’s picture

Thanks for this simple common sense tip. Saved me a few hours of debugging...

labac’s picture

It's work

Danny Englander’s picture

This happened to me when I created content as admin in a format that my site editors did not have access to. It was a simple matter of converting those over logged in as admin to the format my site editors did have access to. I did not have a lot of content to switch over so I suppose this would not work well if you have tons of content to convert.

Ccile’s picture

I had this problem yesterday and I just found the soluce there: http://drupalvid.com/vid/07-how-fix-field-has-been-disabled-because-you-....

Best regards,


knalstaaf’s picture

But the editor (role) hasn't got the proper permissions to use Full HTML. So he couldn't edit content created by the admin.

That was the reason indeed.

cdykstra’s picture

for posting the video. That worked!

firesidelibrarian’s picture

Thanks for posting the video, it gave me the answer I needed!

Todd Vandenbark

fcastrouk’s picture

Thanks davidneedham