Tag: Wordform

Wordform is not being developed in isolation, specifically because I hope to capture input from people who could be considered the potential users of the product. It is more fun to go ‘Ta Da!’ and have the application all finished, to ooohs and ahhhs; but an inherent problem with this is that each of us brings our own interpretation of what is an oooh, and what is an ahhh.

A better approach, then, is to communicate as you develop (rather than after), keep your mind open, and solicit feedback as much as possible. And for this, I need active users — people who are willing to step up and say what they want, and how they want it.

For instance, when Marius points out the polished interface to the textarea within Blogger, saying that this is more meaningful than the Quicktags within WordPress, we can quickly show him a screenshot of the prototype for the Wordform edit page, currently in development. This is using the beta of HTMLArea, which is a very rich text editor currently being tested with Mozilla-based browsers, such as Firefox. It, as with Blogger, will work with IE and any of the Mozilla browsers. Unfortunately, it won’t work with Safari; but then, neither will Blogger.

The PHP program will test browser and insert quicktags, HTML tags, for browsers that can’t work with these rich text editors. However, Blogger’s switching back and forth between WYSIWYG and HTML tags, is a very nice feature. Luckily it’s already included as a feature within HTMLArea — just click the button labeled “<>” to toggle between HTML source and WYSIWYG.

As a sidenote, the new Comment Edit window in Wordform will also have a rich text editor, but I’m removing the HTML capability (HTMLArea is completely customizable). Why? So that I can ensure that tags are properly closed and that nothing harmful is added, while giving commenters a very rich editing experience.

Oh, and HTMLArea has plugins that will allow me to add in spellcheckers and various other nifty goodies. Don’t you just love open source?

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?

Wordform is a project to create a new weblogging tool that incorporates some ideas I’ve had for a tool for a couple of years now. It’s based on WordPress, an open source, GPL PHP/MySQL application; inheriting some functionality, while extending the product in new directions.

This site serves as the test site for Wordform development, as well as the beginnings of tool documentation. I will be documenting each change, before I make the change, describing the purpose and planned behavior; after with the code.

Stay tuned…

The first changes being made to the initial snapshot of the WordPress 1.3a code is to incorporate the ‘floating cloud’ design currently being used at Burningbird into a 1.3 theme. While I’m at it, I’m also moving the default pages down into the themes directory, to minimize the number of files at the root directory of the installation.

While I’m making the changes, pages and links may break from time to time. When finished, this effort should also be usable as a template/theme for WordPress 1.3a, and will incorporate, among other things: live comment preview, post-comment editing, and comment spell checkings.

A vulnerability was discovered with WordPress 1.2.1 and 1.3a, as detailed here and in a forum thread for WordPress, here. This was caused by the fact that an important system variable, siteurl is modified in wp-login.php if the application detects that the URI used to access wp-login.php has changed from what’s stored in the database.

As detailed in both of the above locations, there is usually more than one way to access a specific file, and accessing the file using different variations of URL results in a change to this value that could cause problems with the site. At a minimum, it could result in unnecessary updates to the database.

The current WordPress release was modified to lessen the amount of destructiveness of this vulnerability, but it hasn’t eliminated the problem completely. To fix the remaining vulnerability, I’ve removed the code that updates this value in the database from wp-login.php (though I’ve left the option in the database for now). Unfortunately, this leaves the original problem that served as reason for this code, which is to make it easier to move your WordPress weblog if you need to. Without this code, moving your weblog to another directory can make the administrative pages impossible to access. When I removed the vulnerability, I added back this problem.

To fix this original problem, I added SITEURL as a new parameter to the wp-config.php file, now renamed wf-config.php to differentiate it from the WordPress file. Now, when the WordPress weblog is moved, you can use a text editor to change this value:

define (’SITEURL’, ‘http://wordform.org’);

I also modified the code in the functions.php file that loads siteurl from the database, setting the cached values to that of SITEURL from the wf-config.php file.

if (’siteurl’ == $option->option_name) {
$option->option_value = preg_replace(’|/+$|’, ‘’, SITEURL);
}

This is an interim fix, while the rest of the code is adjusted not to depend on this as an option loaded from the database. Once I’m sure this is so, I’ll remove the option from the database.