Burningbird

P is for PHP

Right about now I imagine all those folks who downloaded the promotional free versions of ExpressionEngine given out over the weekend are finding something out: not all PHP is ‘open’. PHP source code can be encrypted so that the source code cannot be viewed, much less edited or copied. From the bit of open code within the EE files, it would seem that pMachine, Inc. (parent company for EE) is using Source Guardian’s encryption technology to protect their code. Encryption adds an extra step of security, but more than that, protects a company’s proprietary technology.

These source code protection systems are rather ingenious. How they work is that they provide client side applications that encrypt the PHP files and generate matched decoder files that are then included as part of the install of the source code. The call to load these decryptor files is in ‘plain view’ so that the PHP installation can run this part of the code without any additional software. Once the encryption functionality been loaded, it acts as a filter, providing the processing necessary to decrypt the code and allow it be to processed. You can see these files in a subdirectory included with ExpressionEngine labeled ‘ixed’.

Of course, for this type of system to be successful for webloggers, it must run in most environments without having to make any administrative changes on the server, and this depends on how secure the PHP installation is. For instance, if the server is running PHP in what is known as PHP safe mode, and has disabled dynamic module loading (the ability to load new PHP modules in at run time, which is what Source Guardian needs), then the application will fail and the only way for it to run would be for the system administrator’s to either disable that aspect of PHP safe mode or, what is more likely, to add an entry to the PHP configuration to allow this application to run.

(Note for Hosting Matters users: Hosting Matters servers are not running safe mode. Why? Safe mode is a pain in the butt, and breaks most of the really great open source PHP applications. As the PHP developers themselves have said, security should reside in the server management and operating system, not in the language tools. )

I think the fact that PHP can be encrypted is a surprise for some people because it’s such a major component of the whole open source movement. Myths aside, yes, you can use LAMP technologies, including PHP, to create closed source, proprietary, protected, copyrighted, encrypted applications. Contrary to any expectations you might have because of my strong, verbal support for open source technologies, I don’t believe there’s anything wrong with proprietary software–not as long as good faith is maintained between the company publishing the software and the customers using it.

Is there a risk that if the company folds, the customer is stuck with something that is no longer supported? Sure, but the same can be said of open source projects that never inspire any new community effort; Source Forge is littered with these.

I prefer using open source products as much as possible for my own site and home use because as I’ve said before, I’m a tweaker. I like to tweak the code, and I like to make the tweaks available for others to use. But I see nothing wrong with people using closed source applications. If I felt that all closed source applications were wrong, I’d have to give up my beloved Adobe Photoshop. I’ll sacrifice my two laptops out the window before I let you take Photoshop from either one of them.

(Fly, TiBook! Fly!)

And you couldn’t hold a gun to my head to get me to have anything to do with C code, again, open source or not. No, I take it back. You couldn’t hold a gun to my cat’s head, and get to me to work with C code, again.

This isn’t to say you can’t tweak in ExpressionEngine. It provides a ‘plugin’ environment, just as Movable Type, WordPress, and Textpattern do. The only difference with these applications is you can’t hack the internal code in ExpressionEngine even if you wanted to; you can with Movable Type but you shouldn’t because of license and future compatibility; and you’re welcome to with Textpattern and WordPress, and can distribute the hacks legally–as long as you and the other users of your hacks are aware that your code may be overwritten in future versions of these products, so you’re better off trying to work within the plugin environment as much as possible.

Speaking of WordPress, hacking, and plugins, back to work…

I’ve become so caught up in the comradery of the WordPress effort, that someone only need mention something and I’m off coding it. However, I can’t put all my time into ‘tweaking’–much as I’d like to. I have other things demanding immediate attention, and the rest of the LAMP essays and code tweaks will have to wait a few days.

I do this reluctantly, afraid someone else will ‘do the code’ first for the modifications and add-ons I want to build. However, I forget that in a community driven project such as WordPress, someone else may ‘do the code’ first, but this doesn’t mean I can’t also ‘do the code’, or that there aren’t other things to do, and other code to write. So, the rule is have fun, and no need to rush. Besides I don’t want to hurry the LAMP essays and do a poor job in the writing.

Speaking of the LAMP essays, O’Reilly was kind enough to point out the series in their subscriber email list, and I appreciate both the kind words and attention. Of course, I realized in one of the essays that I made a statement about existing books on MySQL and PHP and how they aren’t focusing on the ‘teach by tweak’ approach; I then go on to mention how ‘teach by tweak’ is the better approach in my opinion. My, my – as someone who was once a dear friend said to me, why do I do this? All I can say is, I guess that’s just the way I am, and this is part of the total package that is me. Love me, love the package.

However, ‘learn by tweak’ isn’t for everyone, and for others the excellent books on MySQL and PHP that may or may not fully incorporate this concept put out by O’Reilly are the better options. And did I happen to mention how extremely attractive and intelligent O’Reilly people are?

Anyway, back to WordPress 1.2. The modifications I plan on making, or have already made, to my version of WordPress 1.2 are:

• Multiple weblog support: By this I mean written procedures for installing multiple weblogs, with scripts to help in the process, in addition to my multi-weblog emulation to the WordPress interface that allows a person to switch around among the weblogs.
• Static rendering of pages: This includes a WordPress plugin that can be activated and will render static pages of the syndication feeds and the main weblog page when a new post is created. In addition, an ‘on-demand’ static rendering item can be added to the existing WordPress menu that allows for on-demand rendering of any given page. I may also add this as a checkbox in the Edit page.
• Postmeta wrapper functions: WordPress 1.2 allows you to specify name-value pairs for a specific post. This means that you can attach information about the post, such as PHOTOGRAPH-FLOWER or STORY-CAT. You can see some key-value pairs I’ve added to recent posts in the test site; in the first couple of posts, at the bottom of each. At this time, there are functions to get this data, but not present it as one would like, and one of the wrapper functions I’m writing will allow you to ‘wrap’ the returned value in XHTML tags. Other functions will hopefully allow you to build lists of posts based on their key values.
• Full page preview: WordPress 1.2 has preview at the bottom of the page for the edit page. However, I like my full page preview hacked for the 1.02 version and will port this over to 1.2.
• Full comment preview: this is an iffy one. There is a inline comment preview workaround already implemented in WordPress that I can just include in my posts. I was going to do a full page preview, just as Movable Type implements for WordPress, but I’m not sure it’s a good use of my time. I think what I’ll do is implement the inline preview for now, and lower the priority for the full page preview. However, I will add my throttle code to that built into WP to ensure my comments don’t get crapflooded.
• Adjust the interface to allow on demand moderation: I edited WordPress 1.02 to allow me to turn moderation on, post by post. This has made an enormous difference in the handling of comment spam on older posts. Because of this, I was able to open the older posts for comments, and have received some lovely ones, while still keeping out the garbage. I am porting my code changes for on-demand moderation over to WordPress 1.2. In addition, I’m incorporating an existing modification that turns moderation on for all posts over thirty days, automatically.
• Bulk management of comments: WordPress 1.2 has the loveliest bulk comment management of any weblogging tool I’ve seen. I’ve been asking for this for over a year, and WordPress gave it to me. However, I am making one small change. In addition to the ability to search for comments by name, URI, email, text, and IP address, I’m also going to add the ability to pull in all comments for a particular time range. Once I have this, bulk deletion of comment spam will be trivial.

If you have other modifications you’d like to see, you can always add them to the comments. I may not be able to get to them, but I bet someone else will. Other than these items, though, I don’t have any other modifications I want to make. WordPress 1.2 really is a very good, straight from the box product. All I’m doing is ‘tweaking’ a bit to fit my needs, and possibly the needs of others (all of this code will be packaged and documented).

My plan is to go ahead and do the code and LAMP essays, but to ‘release’ the final version of the code only after WordPress 1.2 is released. This way those who want to play now, can now; but those who want stable can wait.

Once finished with the modifications, I have one more thing I’m going to do: I’m going to create a specialized version of WordPress to be the core element of the RDF Poetry Finder.

I’ve never forgotten the RDF Poetry Finder, nor the concept of building intelligence into metadata in order to not depend on fancy algorithms and luck to find complex semantic objects such as a poem. However, I’m a tweaker not necessarily a build from scratch person. If I was happy creating the Poetry Finder RDF/OWL vocabulary, and the processes to work with this data, I wasn’t happy about building the rather involved infrastructure that allows people to write about poetry, annotate it with their impressions, and then generate the RDF/XML searchable by external agents.

It was someone asking about WordPress’s postmeta data ability today that made me realize that for all intents and purposes, WordPress can form the core infrastructure of the RDF Poetry Finder. And since WordPress is GPL, I can make the modifications necessary to support the Finder functionality in the code, and then package it for others to use, as is, out of the box. After all, the more people using this application, the more data available; the more data available, the faster the spread of the data and the functionality; the faster the spread, the more people using this app….well, you see the cycle. Semantic web software doesn’t get distributed; it spreads, like a friendly fungus. Kind of like a mushroom you can eat and it won’t kill you.

So that’s one last thing on my to-do list, this long promised but never delivered functionality. It will be a relief to finish it.

Carthik.net has a good summary on must reads for moving from Movable Type to WordPress.

LibraryPlanet just wrote up a migration strategy (and provided code) that encompasses how to use WordPress 1.2 new slug feature to support the MT keyword-based shorter file names.

If anyone else has any links related specifically to exporting out of MT and importing into MT, please let me know. Especially if you’ve run into problems and have work arounds.