Thread

I developed a site in EE 1.5.2 (we’re not upgrading to 1.6 yet) and have the FCK Editor plug-in as well.

Most stories behave properly, but once in a while, content editors enter stories that get entered fine, display fine, but give blank screen when editing through the control panel. I did tail -f on the Apache error_log and nothing is appearing.

This problem has only occurred twice, but it renders the stories uneditable. I was able to go directly into the database and extract the HTML for these storeis. It was ugly HTML to say the least.

The HTML had tons of Word cruft in it, not to mention a ton of other font tags and font tags within font tags and tables with style=“lots of stuff” repeated over and over in the TDs. If I remove all font tags and most of the ridiculous and repetitive style=”...” stuff, the story is fine.

(The editors aren’t particularly HTML savvy and prefer a complete WYSIWYG type of environment. I have explained that such an animal isn’t really feasible through a web interface, but the FCK Editor does a decent job without being a cure-all, and need to have relatively clean code pasted into it, or at least not RTF stuff.)

So the question is, what in those unwanted tags is causing EE to bomb? Aside from warning editors to only paste in “clean” HTML, how ca we prevent this.

I’d be happy to grant access to the site for any EllisLab employees who want to take a look at the stories in question or the raw DB. Alternatively, I can dump the database.

It sounds like FCKEditor itself may have run out of memory. Do you have php errors set to on for both EE and your server environment?  Also, how many characters were in the email?

If you disable FCKEditor and try to submit the entry - do you get a blank page?

Thanks for the reply!

The submissions are not through email but through the standard control panel.

And thank you for the nudge in the right direction. I had my blinders on and didn’t think to disable the FCK editor extension.

Once I disabled the FCK Editor Extension the story was editable, so that’s obviously where the problem lies. And I suspected it was running out of memory as well since it’s on a virtual server with rather tight constraints.

What’s the easiest way to get the extension to use a bit more memory without causing unwanted effects or wasteful memory usage everywhere else in the CP? Hack the extension itself with a php_ini() call at the top of the code?

Oh, woops - I meant “how many characters are there in the entry?” - sorry about that.

You would need to up the memory available to PHP - something you can talk to your host about doing.

The entry has around 36K characters, give or take. I looked at the db schema and it looks like 65535 is the upper limit, so I don’t think we’re bumping heads there.

I’d rather just up it in the ini_set call. The host isn’t going to change it, but I’ve had luck with other applications on similar machines with the same host and upping it myself. I’ll hack a few files in the FCK Extension and see what works out.

Thanks.

[EDIT: I don’t know my function names. It’s INI_SET! 😊]

Ah, well, if you have access to increase the memory, then by all means; but if you did need help with it, then your host would be the one for that particular support. =)

It’s fixed! Thanks for the guidance, Lisa.

I added:

ini_set ('memory_limit', '80M');

to the top of the ext.fckeditor.php file in the extensions folder and all is good with the world now. Yeah, that’s a lot of memory, but it’s not like 10 people hit this script at once, so no fears and 80MB ought to be more than enough.