Simple Content Management (with Templates & Permissions)

I’ve been working on a sort-of content management system at work and I wanted to get some opinions on the structure of it. Here’s the basic summary:

I have a database table that keeps the content for me (title, content, date stamp, etc) – each item has a type. My goal was to have a system that would be flexible and allow me to store both hierarchal and date sorted information easily and all in one place. I set out with the intent to make it something I could potentially use for simple blogs, forums and even static content like FAQs.

Basically, everything is a child of something – there’s a starting point (the top parent) and all of the children from there down. Since it’s on Oracle, CONNECT BY is my best friend. I can point it at a parent and get back a recursive array of the values. So, if our top level was “blog” then its children might each be a “blogentry” with each of those having a collection of “blogcomment” content blocks.

You can see how the same sort of thing could apply itself to a forum layout (remarkably similar, actually). Parent/child all the way down, allowing for any number of nested levels of categories and topics.

Now comes the fun part – the PHP code.

I’m not quite done working all of the kinks out of it yet, but it’s close. Here’s the though process behind it, though. A fetch() function is called on the top-most parent to get it and its children’s data. This is passed to a display() call to be handled. Inside of the display() call is a bit of logic that starts looking at the types of the data. The TYPE column in our table is really the key to how the whole system works. The display() logic looks at the type of the first item of data passed in and loads in a Helper from a predefined directory (include_once, of course). These are named according to the type they help with – so HelperBlog helps with type “blog”, HelperBlogentry helps with “blogentry”, etc. These are loaded, a new object is made and the display() method is called on it.

The children are passed in to this method where, if the child class (HelperBlog or whatever) chooses, they can be iterated over. The fun thing is that since the class extends our main class (in my case DynContent), we can just call the parent::display() method with the child data and it will recurse down through each of the layers.

There’s more to it than just this (templating, permissions, etc) that I’m still working on, but it seems like it has potential. I’m curious as to if anyone else out there has approached this kind of idea in a similar way. I’d love to hear feedback/comments/whatever about the idea from anyone out there.

I don’t have the code posted anywhere yet, but if you have an interest let me know in the comments.

Book Review: Beginning PHP and Oracle (Apress)

The nice friendly people over at APress sent me a few new books the other day, one of which is “Beginning PHP and Oracle: From Novice to Professional” by W. Jason Gilmore and Bob Bryla. Of the three, I was most interested in this one as a possible resource to hand off to other people in our company (the Oracle developers, specifically) for them to get started with PHP. Thankfully I can say that, after going through the book, it looks like an excellent fill to bridge the gap between most Oracle developers and the world of PHP.

If you’re a PHP developer, pick up your copy of the book and follow my lead – set the book, spine down, on the table and stick your finger right in the middle. To your left is all of the PHP knowledge you’ve already learned and to your right is a wide open range of Oracle goodness just waiting for you to soak it all in. The first half of the book is an excellent introduction to PHP and can be handed to that special Oracle developer in your life who would like to get to know the language. The usual topics are there – the basic syntax, functions, arrays, object oriented programming, PEAR and lots more. If you’re just going in for the Oracle/PHP combo, you’ll find a lot more than you were asking for (which can be good and bad).

Things switch around at about the Chapter 26 mark where the first hints of Oracle start to show. This is where a lot of the Oracle developers out there can tune out a little more. The first few Oracle chapters deal with setting up and getting to know the Oracle environment, how to use views and transactions. Things get interesting when PHP jumps back in, though. PHP and Oracle developers alike can learn lots here.

Starting from Chapter 32 on, the rest of the book is devoted to the happy union of PHP making requests via the Oracle drivers to a local database (they use a local copy of Oracle Database XE in their examples). They include examples using transactions, generating a table of results with PEAR’s HTML_Table and using views and triggers in your application.

This book works well for both audiences – the PHP developer wanting to learn what all the fuss surrounding Oracle is about and the Oracle developer looking for a peek into the world of the web’s most popular web development language. There’s a little something here for everyone (there’s even a chapter on web services!) and it will be finding its way to the desks of several Oracle devs around here that have been bugging me to show them “that PHP thing” they’ve been hearing about.

Something a little more substantial – the Table of Contents:

  • Chapter 1 Introducing PHP
  • Chapter 2 Configuring Your Environment
  • Chapter 3 PHP Basics
  • Chapter 4 Functions
  • Chapter 5 Arrays
  • Chapter 6 Object-Oriented PHP
  • Chapter 7 Advanced OOP Features
  • Chapter 8 Error and Exception Handling
  • Chapter 9 Strings and Regular Expressions
  • Chapter 10 Working with the File and Operating System
  • Chapter 11 PEAR
  • Chapter 12 Date and Time
  • Chapter 13 Forms
  • Chapter 14 Authentication
  • Chapter 15 Handling File Uploads
  • Chapter 16 Networking
  • Chapter 17 PHP and LDAP
  • Chapter 18 Session Handlers
  • Chapter 19 Templating with Smarty
  • Chapter 20 Web Services
  • Chapter 21 Secure PHP Programming
  • Chapter 22 SQLite
  • Chapter 23 Introducing PDO
  • Chapter 24 Building Web Sites for the World
  • Chapter 25 MVC and the Zend Framework
  • Chapter 26 Introducing Oracle
  • Chapter 27 Installing and Configuring Oracle Database XE
  • Chapter 28 Oracle Database XE Administration
  • Chapter 29 Interacting with Oracle Database XE
  • Chapter 30 From Databases to Datatypes
  • Chapter 31 Securing Oracle Database XE
  • Chapter 32 PHP’s Oracle Functionality
  • Chapter 33 Transactions
  • Chapter 34 Using HTML_Table with Advanced Queries
  • Chapter 35 Using Views
  • Chapter 36 Oracle PL/SQL Subprograms
  • Chapter 37 Oracle Triggers
  • Chapter 38 Indexes and Optimizing Techniques
  • Chapter 39 Importing and Exporting Data
  • Chapter 40 Backup and Recovery

Deploying PHP Applications?

So, a question for everyone out there – we’re looking to do a bit of an overhaul for our build and release system and I was wondering what kind of setups you all out there had for your releases?

I’ve seen all sorts of different things (including a version control->rsync to production push and a fully CruiseControled push for everything) but I wanted to hear back from you fellow PHPers out there as to the kind of stuff you’re using. We’re looking to try to keep it open sourceish stuff, so suggestions down that line would be best but we’re pretty open.

I don’t have much experience with a more formalized build process but we’re coming up against a need to separate out the responsibilities a bit more.

What do you use for your build (and deployment) process for your PHP applications and websites?

Keep PHP Alive! Grow a Beard!

Apparently, beards and programming languages have a direct correlation with each other, at least according to Tamir Khason. His latest list (a “take two” from this older post) reinforces the idea, pointing out lots of different languages and the people involved. Basically, the facial hair (beard, mutton chops, goatee, soul patch, whatever) of the major players involved is an indication as to how well the programming language is doing. Language in the “No Facial Hair” crowd include F#, IronPython and Prolog while the cool cats in the “Facial Hair Everywhere” group include C, Perl, Ruby and Python.

So, where does PHP fit on the list? Well, he points to this picture of Rasmus Lerdorf as a positive indicator for our beloved language, but there just might be enough other developers out there to counteract his effect.

For example:

Though thankfully, there’s one growing part of the PHP community that makes it so much better without even having to worry about the facial hair (thank goodness) – the PHP Women (coming soon to a conference near you!)

So, what’s the result? Does PHP pass the “Khason Test” for survival? Could the best way to support the community possibly be to let that facial hair grow? It’s too soon to tell, if you ask me – right now, though, I’d say the current follicle count is tipping in favor of PHP being around for a good long time…

(Oh, and in case you’re wondering – yes, I am a little on the scruffy side myself)