[RESOLVED] Textarea input: saving, displaying and editing text submitted by "normal" people

[Joseph_Sliker]

Hi;

I rarely do <textarea> inputs on forms to be submitted by users, but I have a project that will require this. The problem is dealing with all of those things that non-HTML literate folks would enter into textarea fields (ie. typical [enter] carriage returns, quotation marks, apostrophes, commas...) all that good stuff that might get turned into alternate characters, or cause an entry to be parsed/saved incorrectly, etc. etc.

What is the general process for storing such "prose" type entries into database (MySQL) fields, displaying it as the submitter intended (ie. paragraphs broken in the right places, no lost text because of apostrophes, AND if the user goes back to re-open the record for future edits, seeing the text returned to the online form/editor just as he/she originally entered it? I think I accomplished this on some project in the past, but I can't quite seem to recall the concepts involved.

Thanks.

[dalecosp]

Have you tried invoking CKEditor on them? It can handle some of that complexity and an escaping function can do most of the rest....

[Joseph_Sliker]

Hmmm...that looks interesting. Is this a WordPress thing (still not clear on how to do the slightly fancy .php stuff I know how to do in that environment), or can I invoke it on a regular ol' .php page?

Just downloaded the standard package. Will see if I can comprehend what to do with it.

[bradgrafelman]

Joseph Sliker;11040065 wrote:

The problem is dealing with all of those things that non-HTML literate folks would enter into textarea fields (ie. typical [enter] carriage returns, quotation marks, apostrophes, commas...)

Why (and/or what) is there a problem with "dealing" with that data?

Why would the level of literacy with HTML have any relation to the type of data entered into the field? For example, I quite regularly (especially right now as I type this message) use all four of the example types of data you mentioned; are you saying that I am one of those pesky "non-HTML literate folks" (whatever that means)? 🙁

Joseph Sliker;11040065 wrote:

all that good stuff that might get turned into alternate characters, or cause an entry to be parsed/saved incorrectly, etc. etc.

Why do you fear that any of the above (including whatever the ellipses represents) will get turned into "alternate characters" ? Who would do that translation, and why don't you have control over it? Why doesn't your normal method of preparing data for parsing/saving work when such values are used?

Joseph Sliker;11040065 wrote:

What is the general process for storing such "prose" type entries into database (MySQL) fields, displaying it as the submitter intended (ie. paragraphs broken in the right places, no lost text because of apostrophes, AND if the user goes back to re-open the record for future edits, seeing the text returned to the online form/editor just as he/she originally entered it?

I'm personally a fan of never losing the integrity of the original data itself. In other words, I would store it in your SQL database exactly as it was given to you - line break characters and all. If it's a lossless translation, and a case could be made that the CPU utilization would be better suited to store the data in a "presentation" format (e.g. store "<br>" rather than a line break), then sure, I might be agreeable with that, too.

Assuming no transformations were done on the data when you stored it... when you go to retrieve that data, you then have to think about how you're going to present that. Are you plopping the value in between <textarea>..</textarea> HTML tags? If so, you don't wan't to convert line breaks.

Either way, you probably do want to ensure at least '<', '>', and '&' get translated into the appropriate HTML entities (e.g. '&lt;', '&gt;', and '&amp;' respectively) to ensure your HTML markup doesn't get broken. You might need to worry about quotes (single and/or double) if you're outputting the data inside of attribute's value in an HTML entity. In other words, you'd probably want to use [man]htmlspecialchars/man (although some may go the extra mile and use [man]htmlentities/man instead).

[Joseph_Sliker]

bradgrafelman, you've clearly underestimated my fundamental ignorance about a whole lot of very basic stuff! :o . My scripting is often soooo very basic that the experienced professionals here would probably be moved to impose a cease and desist order against me for my own protection if such a thing could be enforced. I think I have used php functions like urlencode(), urldecode() a couple of times in the past....but I have forgotten where/why I needed those, and I am thinking there must be some sort of similar functions having to do with the reception/storage and retrieval of user text input. For instance, I did build such a form today, put some regular carriage returns into the text before submitting, and then when it was displayed on a resulting page, viola! no line breaks where I wanted them. (I have to put <p> tags into the text so that it will work....which my non-technical users won't do, because they do other types of stuff.) I have the experience of apostrophes/single quotes and commas truncating input that other forms were supposed to store/preserve. (I'm certainly not knocking them, I'M the one with the problem.) I absolutely agree that I don't want to mess with the integrity of their input...I just want it to go into the database correctly, have it retrieved and displayed as they intended, and allow them to edit it in the same form. But my very simplistic forms and scripts often fail to deliver that experience.

[dalecosp]

Joseph Sliker;11040073 wrote:

Hmmm...that looks interesting. Is this a WordPress thing (still not clear on how to do the slightly fancy .php stuff I know how to do in that environment), or can I invoke it on a regular ol' .php page?

Just downloaded the standard package. Will see if I can comprehend what to do with it.

It a Javascript "web editor" application that should be fairly trivial to implement. I have it on a work site (placed there by someone else) from some years back. I d'loaded the new version just the other day and put it into a personal "charity" project and was quite pleased with the progress they've made with it.

IIRC, installation was something like 1] Unzip and upload to the WEBROOT directory. 2] Put "<script type='text/javascript' 'src=/CKEditor/CKeditor.js'></script>" tags in the "Head" section of all pages (which was trivial because they're simply one PHP file), and 3] add "class='ckeditor'" to the <textarea> tags where I wanted the editor invoked.

YMMV, of course. 🙂

[Joseph_Sliker]

I monkeyed around with htmlspecialchars() for saving the textarea contents into the database. I can reopen the record and if I wrap the retrieved field $value into the textarea wrapped in htmlspecialchars_decode(stripslashes($value)), it appears just the way the user entered it. BUT if I echo the same $value OUTSIDE of the <textarea> box (like one would typically do for a display for readers/visitors to the site) the line breaks go missing.

[ATTACH]5089[/ATTACH] so I feel like I am getting closer, but I would like the user's line breaks to be where they are supposed to be without them having to add <p> or <br /> tags.

textproblem.jpg

[Joseph_Sliker]

dalecosp: Oh Wow! Oh Wow! Oh Wow! This CKEditor thing looks fantastic! AND I actually figured out (from your directions) how to set up and make it work!

(just a quick aside: there was a misplaced single quote & slash in the directions that threw me off until I looked more closely:
"<script type='text/javascript' 'src=/CKEditor/CKeditor.js'></script>"
should be:
"<script type='text/javascript' src='ckeditor/ckeditor.js'></script>"
)

AND IT WORKS! I believe I have barely scratched the surface here, but wow. This is going to be a major improvement to a LOT of the sites I do for people.

Thanks for the huuuuuuge lead!

[Joseph_Sliker]

I would call this problem solved because of CKEditor, but I would STILL like to understand what is happening here:

Joseph Sliker;11040093 wrote:

[ATTACH]5089[/ATTACH] QUOTE]

[bradgrafelman]

View the source code of the page and you'll find that the line breaks didn't go anywhere - they're right where the should be. Where you're going wrong, however, is that assuming a line break in the HTML markup results in a line break in the content displayed. That's not true; HTML parsers translate line breaks into a normal space and also ignore repeated whitespace characters.

If you want a line break to be rendered, you need a <br> entity or you need to interpret multiple line breaks as paragraph separators and wrap the resulting individual paragraphs in <p> and </p> entities. For the former method, that's why the PHP function [man]nl2br/man exists.

[Joseph_Sliker]

Thank you, bradgrafelman! Before much longer (ie. maybe before the whole world runs off to start writing everything in "hack") I have to make myself wade through a complete reference to built-in php functions. nl2br() was exactly the thing I was looking for...but it never registered with me (and I could have used it in many places in the past).

I found that I do have to use it with stripslashes().

ie. I can construct my update or replace query from the values in $_POST[update_rec], like so...

foreach($update_rec as $u_fld=>$u_val) {
    $updatestring.="$u_fld=\"".stripslashes($u_val)."\",";
}
$sql="update table [name] set ".rtrim($updatestring, ",")." where record_ID=$record_ID"; 
// rtrim chops off the pesky extra comma that the foreach loop will add

Then, whenever that record is retrieved for display purposes, I have to remember to echo the retrieved value for the field in question thusly:

echo "".nl2br($value)."";

I think I will be exploring the use of CKEditor, going forward, but it seems like this simpler solution has it's merits where less-adorned text or quicker processing/display would be desirable.

Thank you all so much!

[dalecosp]

If you know the data is always going to be displayed in HTML and not in plain text, you could nl2br it before placing it in the DB. However, this will probably create <br> tags in the plaintext output (CKEditor notwithstanding as it interprets HTML).....

[bradgrafelman]

Joseph Sliker;11040117 wrote:

I found that I do have to use it with stripslashes().

You should never be required to use that function. If you're using stripslashes() just to get DB-stored data to look right, that tells me that one (or both?) of the following is almost certainly true:

1. You (or someone else) has committed the horrible transgression of enabling magic_quotes_gpc. Kill it with fire.

2. You (or someone else) has accidentally escaped/sanitized data destined for a SQL query more than once. This would include "automatic" sanitization, e.g. you used [man]mysqli_real_escape_string/man on data before binding it to a placeholder in a prepared statement; the data will have been (unnecessarily) escaped twice, requiring you to further process it once you get it back from the DB to get back to a net zero result.