Well, I stopped by the WordPress forums today to see what Podz was talking about regarding the numerous CSS issues that WP users have. That’s when I found this old Exhibit thread.
I haven’t given up on Exhibit - I use it nearly every day. But I have been lax in updating it. There are a few things that don’t work quite right, and not necessarily through any direct fault of mine. There have been a lot of changes in WordPress core code for 1.3, and people are having more issues with the plugins each day.
What folks need to realize is that WordPress 1.3 is an alpha product, and they shouldn’t be using it unless they are prepared to deal with the anomalies that are caused by using an alpha product. That said, it’s nice to get reasonable reports of problems to know what’s going to be an issue in the final release of WordPress. But it’s going to be a long time before that happens, and I’ll tell you why.
I’ve been watching the wp-hacker and wp-docs lists and CVS repositories carefully, and I’ve noticed that there is a new trend for cached filter support. Right now, WordPress applies filters to every post that is displayed, as they are displayed. This is apparently a huge resource drain. What proponents of the cached filter system (basically, there are no opponents) would do is pre-filter the post when it is written, then store the filtered output in the datbase. Using this method, WordPress could simply dump the pre-rendered post to output without running it on any filters. The processing savings should be tangible. But the changes required to implement it are far-reaching.
I was sifting through some code for implementing some changes in 1.3 to improve the fight against comment spam. In that code from CVS I found traces of pre-rendered comment filters. It seems that the transition is already under way. I won’t suggest that it’s a bad idea, just that the code probably should have been optimised before committing to such a large operation. There are many places where had the code been optimised, the caching changes could be made simpler.
Using my local PHPXref of WP 1.3 CVS, I found three places where the function check_comment is used. Basically, three places where code was duplicated to acheive mostly the same result.
A function exists to add comments to the database, and is well-suited to all three methods of adding comments. Yet this function is only used in one of the methods. The changes I made for the comment spam issue consolidate all of the comment committing code into that one function, and eliminate about 80 lines of redundant code. As a result, the caching code is required in only one location instead of what should have been three, but was actually only two because one spot was overlooked. The missing implementation is the type of thing that could have been avoided by optimising first.
Adding this code to CVS totally overlooks the possible issue of rushing into implementing a solution without peer review, which the WP devs have been able to narrowly avoid so far, but could really catch them this time if the caching isn’t done just right.
Anyway, I’ve strayed far from what I really wanted to say, and headed off into “I wish that there were more developer docs and a roadmap to WordPress”-land.
I’m going to finish up my comment spam patch, and if it’s committed or not it’s not a big deal. I think that adding a user filtering function is a good idea, and it’s something that Ryan (one of the devs) had suggested doing anyway. I’ve also added a new ability in the user comment filter to let the filter discard comments entirely, rather than even letting them into the moderation queue. This suits me well, since certain keywords (like ‘appleproxy’ in the HTTP headers) indicate nothing but spam, and can’t be checked at all using the current methods.
After the comment spam patch is complete, I’ll move back to Exhibit. I want to go through the support thread and pull issues to address. There are some significant things that need to change in Exhibit’s next version, such as:
- Storing content in wp-content by default
- Updating for new plugin hooks
- Using the new database upgrade functions
- Adding an admin page for the Exhibit options
Most of these require 1.3 to work. I will also need to reduce the code size while I’m in there, and I think I will do that by removing support for the external file. I haven’t heard of anyone using that that wasn’t better served using different Exhibit options.
Also, I’d like to clean up the image-add interface. There are two things that I’d like to do. First, I want to change the frame reload javascript to use the stuff that that Boggle website uses for background server communication, so that the file-picker frame doesn’t reload when you choose things. Second, I want to reorganize the interface a bit so that it fits on my screen nicely instead of spreading all over the freakin’ place and making the post writing page really long.
I would also like to add support for a next/previous link on the image popup, which means ditching the old popup and making the experimental one (which is really nice, if you’re not using it already) the default option. I would seriously like to add some indexing features.
The indexing features would key images that are attached to posts with keywords from the posts and let you search for images that way. So say you wrote about your Aunt Jean one day and attached some pictures to that post. If you did an image search for “Jean”, those pictures should come back. This would be great for searching for Abby pictures, for example.
Anyhow, that’s the plan. It’s not a good one, but it’s what I’m going to go with. If you’ve got suggestions, leave them in comments here. I think I will find time to do all of this by simply not reading my rss feeds any more. Who needs pseudo-news anyway?
By-and-by, the proposed fix for Exhibit on alpha 4 is online, but by no means final. Check it out and see if it works for you.
