Categories
Technology Weblogging

Adapting Admin for extensibility

Recovered from the Wayback Machine.

Many of the earlier changes I’m making to WordPress will be behind the scenes, in the administration pages. In fact, when I finish these changes, I probably will release a copy of the product as it will then be sufficiently different enough from WordPress to have earned status as a separate product.

One change I started coding a few weeks back was to make the administration pages more adaptable. For instance, rather than hard coding the post and comment status into the administration page, I’m adding these as database values and building the options list dynamically. With this developers who want to add new statuses for each can do so with an update to the database, leaving the code untouched for future upgrades.

(The post status can be passed to blog header, for processing for preview, display, etc. The comments files will also handle different statuses, as I already do so in my current comments pages.)

In addition, the menus and submenus of WordPress are built from a file, and this again makes it so that those who create extensions either have to modify the file or using some kind of DHTML to add options. A more adaptable approach, which I’m building into Wordform is to load the menu options from the database, rather than from a file.

A third area of adaptability is to modify the buttons below the text for a post to add options for what can be done with this post. With this, when I wanted to post a full page preview of a post (using the same stylesheet as the weblog), I wouldn’t have had to hack the page — I could have just added an option into the database and the functionality as a plugin.

All this cuts into the space in the page. What I’m thinking, and looking for feedback on, is to drop the in-page preview, since I’m providing a fullpage preview. I’m also thinking of making slug and trackback that display below the post into buttons that open small windows for each and doing away with separate simple and advanced edit pages. (See diagram of specific changes.)

I had also considered making the category into an option to open in another window, similar to how Movable Type handles it. The category hierarchies don’t display well in the page, and cut into text edit space.

However, is all of this too many window openings? Should I leave the categories as is, but open windows for some (or all) of the others?

Print Friendly, PDF & Email