Question

I’m working on a PHP CMS like project and I’m trying to find out what’s the most convenient way of dealing with the CRUD functionality in PHP.

The CMS is programmed completely in procedural PHP (no OOP – I know that many of you will not agree with this…) and was designed keeping everything as simple and light as possible, as well as creating highly reusable functions and snippets of code.

The CMS allows multiple modules to be installed / activated on needs basis. These modules describe different types of content so I will probably end up having something like pages, news, blogs just to name a few.

For each of this content types I will have to create the CRUD operations and now I’m trying to find the most convenient way to achieve this.

One requirement would be that the form for each of these content types is contained in a single external file (for both insert and edit) and if there is some way to integrate server side input validation that would be a plus.

Answer 1

By CRUD operations do you mean just the (tedious) database queries?

You could just as easily setup your database so that except for a few common fields amongst content types, all data for a particular content type is stored as a serialized associative array in a TEXT field.

This way you only need 1 set of queries to CRUD any particular content type since the data passed to the CRUD functions is just blindly serialized.

For example, say we declare that content title, created/updated date, tags, and short description are considered common data. From there we have a blog and a page content type.

I would possibly create a database table as such:

CREATE TABLE `content` (   `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,   `name` VARCHAR  NOT NULL,   `short_description` TEXT  NOT NULL,   `tags` TEXT ,   `data` TEXT ,   `content_type` INT  NOT NULL,   `created_at` DATETIME  NOT NULL,   `updated_at` DATETIME  NOT NULL,   PRIMARY KEY (`id`) ) 

(Go ahead and assume we’ll create the reference tables for content_type)

And while the blog might require data like ‘pingbacks’ and the page might require nothing but the body, you just store the output of something like the below example for a blog:

$data = serialize(array(     'body' => 'Lorem ipsum',     'pingbacks' => array() )); 

Updates are easy, whenever you grab the data from the database you unserialize the data for editing into a form selected based on the content type. Displaying works the same way, just grab a template based on the content type and send it the unserialized data array. The template never needs to worry how the data is stored, just that it gets a $data[‘pingbacks’].

As for your forms, my suggestion is to break your anti OOP covenant and find a form generation library. If you can extract it from the framework, using Zend_Form with Zend_Config and Zend_Validate from the Zend Framework (all Zend_Config amounts to in this situation is a convenient interface to load and traverse XML and INI files) makes life really nice. You can have your XML files define the form for each content type, and all you would do is just render the form on your page (grabbing the XML based off of content type), grabbing the filtered data, removing the ‘common fields’ like name, created/updated dates, then serializing what is left over into the database. No knowledge of the schema for a particular content type is required (unless you wish to be strict).

Though as a personal aside I would highly suggest you look into grabbing Zend_Form (with Zend_Validate and Zend_Config) as well as using Doctrine as a ORM/database abstraction layer. You might find that at least Doctrine will make your life so much easier when it comes to running operations on the database.