General
| Name | cjhaas |
| Website URL | |
| Current Location | La Crosse, WI |
| WordPress Origin Story | WordPress is for people who don’t know how to program… is what I thought. For more than a decade I built and rebuilt CMS’s for various projects. Step #1, built a user system. Step #1.5, remember how to probably salt and store a password hash. Step #2, figure out the different content types and build custom “page editors” for each. Step #n, explain that each thing that we didn’t figure out at the beginning meant either a big code change or forcing the editor to go into HTML mode. Rinse and repeat the above with whatever is changing. MD5 is out, SHA1 is in. TinyMCE is out, FCKEditor is on, then out again. Bye-bye text, hello varchar(max)! Unicode… About 5 years ago I started the process again for a new client but this time instead of just building what I knew I wanted to see what everyone else was doing possibly learn some new tricks. At the same time another client required WordPress for a project so I decided to get two carrots with one pull (vegetarian version of two birds) and dove into the code. One of the first rules that every WP developer is taught is “don’t hack core”. Unfortunately for me, WP core wasn’t outputting what I wanted in some cases so I was forced to hack the core (sorry). That is, until I found out about hooks. Holy crap! I also saw that other CMS’s were doing that too and it was a game changer for me. When I went back to my custom CMS that I was building I knew I wanted these hooks so I rewrote most of it with this concept in mind. Next I looked at WordPress’s actual database tables and I couldn’t find where they were storing the descriptions of their content types. There was a table called “wp_posts” with a “post_type” field, but where were the tables that described these types? There should be a “types” table and a “fields” table and a “field_types” table, then there should of course be the various join tables of “type_fields” and “field_field_type” and so on. But nope, WordPress did it all in code and they basically put everything into two main tables for “posts” and “meta”. Huh, a key-value store or property bag for meta information that allows for n items and I don’t need to rebuild my SQL code over each time. Okay, let’s rebuild my custom CMS with this in mind, too. I think I rebuilt my custom CMS at least a half a dozen times with things that I learned from WordPress. Eventually that project shipped but I decided for my next project to jump in and give WordPress a full fair try and I haven’t looked back since. |
