Thinking Outside The Textarea

Quick little tip from me today. In the last week I've run into this problem twice: when using a . A browser will interpret this as the closing of the original textarea tag and run the rest of the content as the rest of the content editing form, which is clearly going to cause problems. The solution to this problem is ridiculously simple.

First of all you just realise that the problem is being caused by the content being treated as actual HTML by the web browser. This is because the systems I've seen (including one written by me) initially loaded the textarea in the following way:

`Quick little tip from me today. In the last week I've run into this problem twice: when using a . A browser will interpret this as the closing of the original textarea tag and run the rest of the content as the rest of the content editing form, which is clearly going to cause problems. The solution to this problem is ridiculously simple.

First of all you just realise that the problem is being caused by the content being treated as actual HTML by the web browser. This is because the systems I've seen (including one written by me) initially loaded the textarea in the following way:

`

The content is being loaded in as is and is thus causing the problems. The solution is of course to filter the content to make sure a browser doesn't treat it as HTML. At the same time it still have to be HTML so that the user can edit it and have it load as HTML when being used as the content of a page in the system. The way to do this is simply convert < and > characters into < and > respectively so that the browser will render them correctly for the user but not use them to render the page itself.

A short line of PHP using regular expressions will handle this nicely. (Look up regular expressions in your language of choice if you don't use PHP.)

``Quick little tip from me today. In the last week I've run into this problem twice: when using a . A browser will interpret this as the closing of the original textarea tag and run the rest of the content as the rest of the content editing form, which is clearly going to cause problems. The solution to this problem is ridiculously simple.

First of all you just realise that the problem is being caused by the content being treated as actual HTML by the web browser. This is because the systems I've seen (including one written by me) initially loaded the textarea in the following way:

`Quick little tip from me today. In the last week I've run into this problem twice: when using a . A browser will interpret this as the closing of the original textarea tag and run the rest of the content as the rest of the content editing form, which is clearly going to cause problems. The solution to this problem is ridiculously simple.

First of all you just realise that the problem is being caused by the content being treated as actual HTML by the web browser. This is because the systems I've seen (including one written by me) initially loaded the textarea in the following way:

`

The content is being loaded in as is and is thus causing the problems. The solution is of course to filter the content to make sure a browser doesn't treat it as HTML. At the same time it still have to be HTML so that the user can edit it and have it load as HTML when being used as the content of a page in the system. The way to do this is simply convert < and > characters into < and > respectively so that the browser will render them correctly for the user but not use them to render the page itself.

A short line of PHP using regular expressions will handle this nicely. (Look up regular expressions in your language of choice if you don't use PHP.)

``

Basically, what this code is doing is searching for occurrences of < or > in $page_content and replacing them with < or > (the replacement is done respective of the positions in the arrays). This should be all that's needed to correctly filter your content to avoid this really simple bug.