[Plugin: Front-end Editor] Text area become very narrow

The “development version” that is available at downloads.wordpress is only 1.7.2, not 1.8a2. If you have fixed this in 1.8a2, maybe you should take the fix back to 1.7.3 as stable. It is a devastating bug.

The narrow WYSIWYG editor column problem occurs, in FEE 1.7.2, on FF, Opera, Chrome, on sites with very different setups and themes, both live (Linux) and locally served (Windows). It is fairly new (a few weeks?), doesn’t seem connected with any plugin change, and occurs with all other plugins deactivated.

It occurs regardless of FEE configuration — even if only checked “edit post content” (which avoids your multiple-id error — which really should be corrected, please).

For some reason FEE inserts into some divs completely unnecessary inline styles of width:nnn, where nnn doesn’t make any obvious sense, but is much less than full (and differs for me on different sites). By “completely unnecessary”, I mean that if I remove them (using FireBug magic), the display becomes correct.

Let’s get this fixed — I’ll start reading code now.

Kim Kirkpatrick

Version 1.7.2 is the former 1.8a2 dev version (I rolled it back to make it a minor release).

So upgrade to version 1.7.2.

Then, disable the WYSIWYG editor to make debugging easier.

Is the textarea still narrow?

If so, is the X (cancel) button red or not?

If it’s not, are you getting any errors in Firebug?

Finally, are you using any other plugin of mine (including WP-PageNavi or WP-UserOnline)?

For some reason FEE inserts into some divs completely unnecessary inline styles of width:nnn, where nnn doesn’t make any obvious sense, but is much less than full (and differs for me on different sites). By “completely unnecessary”, I mean that if I remove them (using FireBug magic), the display becomes correct.

That’s done by nicEdit (don’t ask me why).

It occurs regardless of FEE configuration — even if only checked “edit post content” (which avoids your multiple-id error — which really should be corrected, please).

It’s the first I’ve heard of the “multiple-id error”. Please open a new topic with further details.

Yes, I’m using 1.7.2. Without WYSIWYG, textarea is narrow. The X is red. I have disabled ALL plugins except FEE.

Evidently something is cached or saved in WordPress that causes this. Here’s the complicated story.

Those inline width styles which are inserted by nicEdit create the problem. They are calculated at lines 323 and 419 of nicedit.dev.js, using the expression
parseInt(e.getStyle('width')) || e.clientWidth
For some reason the width style retrieved from the element e is wrong.

If the parseInt expression is replaced by, say, 400 in both places (ie 400 || e.clientWidth), the width of the resulting editor is 400px.

But, as I said, these width stylings are unnecessary; the editor displays correctly without them. So in desperation I forced the editor to display correctly by getting rid of all width style settings that involve these calculated values — commented out width stylings at lines 323, 426, 429, 592, 1422. This makes the editor full width (this works in the several themes I’ve tried, one and two column, fixed and flex). And the non-WYSIWYG editor is full width, too.

Here’s the mystery. On one of my sites, after doing this, I reverted to the original nicedit.js, and the display remained corrected! (On all browsers — this is not a browser cache problem.) But I haven’t been able to replicate this healing on other sites. So whatever stored data that got changed in one system by temporarily correcting the display, didn’t get changed in others.

So on those other sites, I’m using the brute-force correction of the modified niceditor.js. I don’t like it, but whatever. Perhaps eventually that mystery healing will occur.

The problem with older versions of FEE was that front-end-editor/editor/editor.css wasn’t loaded. But if you say the X button is red, that means it’s now loaded.

So, for sites where the textarea is narrow, check with Firebug if there’s a width: 100% CSS rule applied to it or not.

i confirm that this nasty bug is still present in v. 1.7.2 and with internet explorer! ??

it’s ok in firefox and chrome…

checked with firebug and the width: 100% css rule (!important) is present!

pic

Here is what I’ve come up with, attempting to get FEE to work with IE6, 7, and 8, Firefox, Chrome, Safari, and Opera (on Windows; no idea about Mac or Linux browsers).

1) IE 6, 7, 8 seem to require the following surgery on nicedit.js: in lines 323 and 419 (of the nicedit.dev.js file), I changed
(parseInt(e.getStyle('width')) || e.clientWidth)
to
(e.clientWidth || parseInt(e.getStyle('width')))
I found this suggestion on the nicedit forum — others have had the same problem with nicEdit on IE, and not just within WordPress.

(Note that this “||” is the rather unusual “assignment or”, not a logical or: If the first value exists/is “true”, that value is returned, otherwise the second value is.)

This fix seems quite necessary for all IE’s — I see the problem, and the success of this fix, on several quite different sites using a number of different themes, including classic and default. Fortunately, I haven’t seen any negative effect due to it.

2) Because width is not inherited, it may be necessary that the enclosing div be given a width explicitly in the css. But not always — for example, not in the default theme.

3) And several browsers (IE and Opera are the fussiest) don’t like widths in % or auto or inherit. Only absolute units (px, em …) seem to work for all browsers.

This is a flakey problem. It is real, but not universal. It is not a simple WordPress plugin interaction, since it occurs even with all other plugins deactivated (though some may have left traces in database’s wp_options — perhaps that is where the problem is, and why it sometimes seems to appear/disappear spontaneously). And it occurs outside WordPress (see the nicedit forum), so it’s not just a plugin interaction.

Each of the “cures” mentioned above is quite repeatable within a specific situation (site, theme, browser) — that is, if I remove the fix, the problem returns, and goes away again when re-fixed. But, as I said, they are not all necessary for all setups — except perhaps for the first fix.

Feedback?

Kim Kirkpatrick

Wow, thanks for the in-depth research, Kim. ??

I’ve included solution 1): [215091]

For testing, grab the development version in about 15 minutes.

I’ve included solution 1): [215091]

For testing, grab the development version in about 15 minutes.

I have this version (1.7.2) and the problem of narrow edit window in IE8 still exists.

The development version is 1.8a4.

I just downloaded the development version, but I’m still having the problem in IE8.

Should that be the case? Seems from what I read above the development version should resolve the issue.

It’s working fine for me in IE 8. It’s probably an issue with your theme.

See if it happens with the default WP theme.

I can only explain my incompetence by the hour of the night that I was working.

Somehow, I was still on 1.7.2. Thought I’d upgraded. Who knows…

Anyway, yes, it works fine. Thanks to everyone who contributed to getting this fix done.

Scribu

Having problems with the editor width issue in FF, Chrome, Safari, I am using Thematic theme. I read through this post and it all makes sense even checked the nicEdit.js file but the fix is in the latest version. I tried the development version and it fixed the width but the WYSIWIG editor bar disappears. Any idea what could be going on? Kinda stuck.

Thanks

I have one possible workaround for this (see below)

I have the same problem — just installed 1.9.2.1 in WordPress 3.0.4. I’m viewing using Safari (which is what my clients will be primarily using).

All seems ok when the WYSIWYG editor is turned off. When the WYSIWYG Editor is turned ON, I get the narrow texarea. Inspecting the element reveals that there is an inline style width of 104px applied to two divs. The first div seems to be a container for the WYSIWYG editor buttons and the second is a container for the editable text itself. There is also another nested div with a width of 96px. Here is the relevant code I’m seeing:

<div class="fee-form fee-type-rich fee-filter-the_content">

	<div style="width: 104px; " unselectable="on">
	  <!--- HERE IS WHERE A ALL THE ELEMENTS OF THE WYSIWYG BUTTON-BAR ARE DISPLAYED --->
	</div>

	<div style="width: 104px; ...ETC>

		<div style="width: 96px; ...ETC>
			<p>
			MY POST CONTENT BEING EDITED HERE
			</p>
		</div>
	</div>
	<!--- MORE DIVS CONTAINING ELEMENTS SUCH AS SUBMIT BUTTON ETC --->
</div>

I have made it usable by adding the follow CSS to my template style sheet (only tested in Safari so far):

div.fee-form > div {
	width: 100% !important;
}

div.fee-form div > div.nicEdit-main {
	width: 98% !important;
}

Another problem is that when the WYSIWYG Editor is turned ON, the “Display a tooltip above editable elements” option does not function, even though it is also enabled.

Thanks.