ezPublish: slow and crufty

ezPublish has exactly the right idea. It is Inklog in every shape and fashion. It does exactly what I want to do. It’s perfect… in theory. In practice, however, it’s not so good.

It comes with it’s own template system that is slow, crufty and difficult to extend. Not nearly as simple (though almost as usable) as Smarty. Templates are used for everything, which is great. Unfortunately, Figuring out what goes where and how is not a simple task. It took me about 3 hours just to figure out how to get the thing to spit out raw HTML. And, in the end, instead of using a simple modifier in the template, I had to design a whole new template just to take care of what should be a simple task.

Possibly due to the version of PHP that I run, or, who knows, it insisted on putting "index.php" in all of my URLs. I eventually, convinced it otherwise by, essentially, cheating.

If it implements different view methods, I surely can’t figure out how. The templates are all over the place and nothing is where you think it should be. It caches things when you don’t think it should, and it doesn’t always know when it should refresh the cache. It uses 80-something database tables, and I’ve yet to figure out what goes where.

The object model they implement is… crazy. There are classes for everything, which is great. But deciding what does what is difficult. They have some classes to implement a "content" object. From there, you can ask the "content" object to give you an "contentclass" object, which is really a class that manipulates "content" objects. Why don’t the objects manipulate themselves? That would be much less confusing.

On top of all that, it’s slow. I expect it to be slower than a static page, of course. I even expect it to be slower than most dynamic websites because so much more is involved. But, I tested it. My current home page takes about 0.6 seconds. Inklog (which isn’t feature complete) takes about 0.5 seconds. ezPublish, with very little data in it at all, takes about 1.6 seconds. And, get this, these times are with "caching" ON! Part of the reason is very inefficent code. Not that much time is really spent in the database. Most of it is spent doing complicated regular expressions on things like PHP_SELF just to figure out what its own name is, and other assorted silly things. If you look at memory consumption as the thing is running, you’d kill yourself. I think I estimated about 12MB to render a single dinky page. And that doesn’t count Apache, PHP, MySQL and other stuff. And, I’m relying on thier benchmarks to analyze memory usage, so it might even be wrong.

I thought about modifying their code and contributing to the project. But the code is a mess, it would take me longer to understand it, determine what needs to be changed, get thier approval, and then modify it than it would to write it all myself.

But, they do have some really good ideas. Many of which I will implement in Inklog. For instance, I was making a class for each display object type. This is not really needed. Most object types do the same things: "view", "create", "edit", etc. So, I’ll implement a single "Content" object and a single "Node" object that can dynamically structure itself for different types of content. I’ll also implement an "Attribute" object to handle holding the data (the "Content" object will just organize it). Versioning will be added and implemented in the Content object as will Published/Draft status. DataTypes will also be implemented. The "Attribute" object will merely determine the DataType and allow access to it. Then, to ensure that complicated things can still be done if desired, I’ll implement an extensible "Module" system. In fact, the part of the system that deals with these "Content", "Node", and "Attribute" objects would be a "Module" itself. Maybe not "Node"… that’s still to be determined.

ezPublish went through the trouble of assigning "names" to "node"s. To me, that seems silly. A "node" should represent a location in the URI structure. It should point to a "content" object, and point to a "template". It might have a "URI" name if anything, however, if desired, this could be held in a completely different table as a URI to node relation. I think they did it so that they could do a search by Node Name, or maybe to save them one table look up just to list nodes. That’s silly. A "node" should get its name from the "content" object it references. If that means one more database hit, then so be it.

I’m still desperately looking for coders to help this project along. People to write code, people to document code, people to comment on functionality, people to bounce ideas off of. If a system like ezPublish (but cleaner, faster, and easier to extend) sounds like something you’d desire, then send me an email and let me know.