When coding a CMS system, should HTML be stored in the database?

Ex. If the structure of the db table is this:

create table annoucement (
id int unsigned NOT NULL AUTO_INCREMENT,
title tinytext,
body text,
PRIMARY KEY(ID)
);

What if the user wants to be able to make certain text in the body field of the db bold, italic, different color, etc. Should they be allowed to enter HTML in the text field or should there be some sort of special tags (like vbCode).

I would lean toward having special tags, but I can't explain to another person in a clear way as to why we shouldn't store HTML in the db.

Also, I don't know if anyone has see some of the IE specific WYSIWYG editors that are floating around. Those are nice for people who do not know HTML, but they insert HTML tags into the body field. Any thoughts? I don't mind that it's IE specific the backend/administrative section can be IE specific, and the what a visitor sees will be cross browser compatible.

Is there any WYSIWYG editors out there that allow for me to customize what tags they insert?

    yes, of course you can and should store html in a database! i would not be worried about making up your own tag system.

    In regards to wysiwyg editors, if your cms back end is only IE only, doesnt mean your front end has to, concidering that its only html

    If you want to restrict the tags allow from an input form or in your case wysiwyg editor i suggest you look at the strip_tags function.

    so something like

    $string = strip_tags($string, '<a><b><i><u>');

    should do it

      Originally posted by philwong
      yes, of course you can and should store html in a database! i would not be worried about making up your own tag system.

      The reason I asked is because I want to keep the raw data seperate from the presentation layer (in accordance with the 3 tier architecture).

      HTML code in the db would break that architecture. HTML is part of the presentation of the data (as is Smarty, the template engine I'm using). PHP is the application logic, and the database the raw information.

      I don't like mixing raw data and presenatation logic.

        I'd store both, myself. The customised code, so that future presentation-level changes don't hurt it and to allow future editing, and the HTML version, so that you don't have to reparse the custom code over and over on every request for it.

        You can reparse the custom source and store the resulting HTML whenever a change is made to the source (or it's added) (and do a bulk reparse of all the source into HTML if and when a presentation-level change is made).

        An alternative would be to store the custom source and leave the HTML field null initially. If the source is altered, null the HTML field. If the relevant part of the presentation layer changes, null the HTML. When a request is made for some HTML to display, look to see if there is HTML present; if there is, display it; if not, parse it from the source, store it for future use, and then display it. The HTML field is used as a cache, in other words.

        The second approach is probably a bit more complicated than necessary; certainly, the first is much simpler, since the source parsing and HTML display code is kept separate.

        Either way, both get stored - once for convenience and content/style separation, and once for speed of delivery.

        Of course, if you don't want to store any HTML at all in your database, then you've pretty much answered your own question 🙂

          Originally posted by Weedpacket
          I'd store both, myself. The customised code, so that future presentation-level changes don't hurt it and to allow future editing, and the HTML version, so that you don't have to reparse the custom code over and over on every request for it.

          You can't be serious. That gones against normalization. If I store 2 version of the body of the text in the db, I'd be wasting a lot of space.

            Originally posted by jasonla


            You can't be serious. That gones against normalization. If I store 2 version of the body of the text in the db, I'd be wasting a lot of space.

            Drat: sprung 🙂 It's a tricky business, is satire...

            As I added at the end of my post, though: if you don't want any presentation-level code in your database, you've pretty much answered your own question...

              Write a Reply...