Thread

Either I’m missing something really obvious here, or there’s an obvious hole in the RTE functionality. I want to place a ‘soft’ carriage return in an RTE field’s contents — ie. not start a new paragraph but simply insert a line break into the existing paragraph. In a word processing environment this would typically be accomplished with a Shift-Return but using that key combo in EE’s RTE fields simply creates a new para, just like a regular carriage return does. I can type in a <br> element and that will sort of work, but not only is it clunky (I sometimes have to submit the entry twice or more for the line breaks to ‘take’)* but it also breaks the no-code-required environment that I’m trying to provide for the client.

To my mind the RTE field should either accept a shift-return keyboard input as a simple line break (it works in this forum, after all), or there should be a button available as standard to permit the insertion of a <br> element. I realise that it is possible to create new buttons for the RTE but that’s getting may deeper into developer territory than a designer like me is comfortable with, and it shouldn’t be required just to get something as basic as a line break, surely?

* Often , after the first submission, they simply appear in the template as the characters <br> rather than being interpreted as a line break as intended. Resubmission of that entry normally corrects this — maybe something about the javascript that turns the <br> code that I’ve typed into an actual, behind-the-scenes HTML element needs a couple of passes at it — but that’s nothing I want to present a client with.

There’s no chance you’re using a regular text field with formatting buttons enabled, rather than a rich text field is there?

Definitely. The field I noticed it in was actually a Rich Text field within a Grid field, but the same problem manifests in a basic Rich Text field also. (I just created a new Rich Text field as a test to make sure). In both cases, typing a Shift-Return starts what appears to be a new paragraph in the editing field (ie. a new line that is spaced out from the preceding one), and when rendered in the template these lines are individually wrapped in <p> tags. In other words, using a Shift-Return gives exactly the same result as using an unmodified Return.

That’s odd. I don’t get that behaviour using 2.7.3 - what version are you using?

It might be of interest to see the various RTE bugs that have been fixed here:

http://ellislab.com/expressionengine/user-guide/about/changelog.html

Maybe you could try a fresh install, with default settings and no plugins. Or perhaps try a different browser (for example the RTE doesn’t perform consistently with IE11 in my limited experience).

I’m on 2.7.3 as well. Dang it. I guess I’ll back up the database and start deactivating plugins one at a time, see if anything fixes it. If not then I guess the fresh install is the only way to be sure (but I was hoping to avoid that particular dollop of faff).

I just found the thread below - having skimmed over it (particularly the last page) I imagine you might be better off trying an alternative (I’m using Expresso which seems to work alright, albeit a touch slow to load).

http://ellislab.com/forums/viewthread/217397/

The only other thing I can think of is if you might have a plugin that automatically strips and replaces tags upon input - though I imagine a bug in the RTE is more likely.

Thanks for that, Finn. It’s not encouraging though, is it? That thread is a year and a half long and it seems that there’s been no measurable progress on fixing the problem. The RTE is a pretty major component of the EE editing options and for it to just be left as this broken ‘thing’ that so many people are having problems with is, IMO, not really good enough for a commercial product. Especially when it’s not a behind-the-scenes problem either, but something that clients come back and complain to their web designers/developers about. It creates damaged relationships down the chain.

I guess I might have to look into a third party solution—at extra cost. That’s tough when one has already had to make the argument to one’s clients about why EE, at $300, is a better choice than a free solution like Wordpress. Come on Ellis Labs, sort out the RTE. I’d almost prefer that it wasn’t there at all, rather than me implementing it and then having to waste valuable time a) trying to fix it and b) swapping over all the uses of the RTE to a third party add-on.

Anyway, on the off-chance that my issue is not the same as those discussed in that thread, I’ll still try stripping out other add-ons in case one of them is interfering.

Just coming back to this after working on other things, and before I start stripping out add-ons can anybody here confirm that they CAN get a soft return in the RTE by using ‘shift-return’? If any of you guys can do so then it means that it’s probably something conflicting in my installation. But if nobody can get a soft return in that way then the problem is probably the RTE itself – in which case I probably won’t bother with the whole, tedious, stripping-out-add-ons-one-by-one business.

So: anybody?

Yes soft returns work fine here. Personally I’d try a quick install of a fresh copy of EE, and perhaps try a different browser at the same time.

Finn, you’ve nailed it. The problem, it seems, was the browser I was using (Safari, Mac, v6.1.2). It really never occurred to me that different browsers would interpret hard/soft returns differently—surely a character is a character? But I switched over to Chrome and hey-presto, a shift-return inserted a soft return as one would expect. Regular return started a new paragraph—again, as expected.

Went back to the same entry field in Safari just to double-check and, sure enough, both return and shift-return started a new paragraph. So Safari definitely has an issue here. I have no idea whether this is a fault with Safari, or whether EE ought to be more forgiving re. how it processes input from the browser, nor do I know how to find that out. But a change of browser does away with the problem.

Not sure how I feel about telling clients that they need to use (or not use) a specific browser, though. For that reason alone I might yet switch over to using Expresso for rich text.

Pleased it’s working now Rick!

Jut noting that this still a problem. It’s logged as a bug though. http://goo.gl/SX9gl3