Essentially: it does what it says on the tin. My bbPress forums were
a) Magnets for spammers of every *dol, Cia*, Dolc*gab* and Ho*ref*nance
2) CPU chewers for little payoff
D) Not really used by y’all or me*
So, in short, I’m deactivating them and shall breathe a sigh of relief.
If you’ve comments related to my posts, feel free to leave them in the, errrm, comments sections. If you’ve Elbee Elgee-related bugfixes or feature requests, plunk ’em in the Bitbucket issue tracker. I’ll also keep an eye on the forums over on WordPress.org in order to keep current.
In shorter short: so long, and thanks for all the fish, bbPress!
Elbee Elgee Version 1.3/1.3.1 Aka “The Tabbed One”
After a healthy delay, I’ve released Elbee Elgee 1.3 to the Dot Org Theme Repository. I’ve added a few things worth noting.
Tabbed Admin Options
The first change that I’m rather proud of is the inclusion of tabbed admin interface elements. While the code powering this setup could use some optimization and simplification, this tabbed step lays the groundwork for some other exciting features I have planned for forthcoming releases.
As you can see in the screenshot above, Elbee Elgee will now detect whether you have BuddyPress and/or bbPress installed and active and will separate out admin elements relating to their functionality into separate tabs. They’re simple examples but they demonstrate the power of this approach.
The Beginnings Of Theme-Wide PHPDoc Documentation
I’ve started documenting the ins and outs of the master parent theme in an effort to both assist my lousy memory and to give pointers to users and (hopefully) other theme devs that choose to use Elbee Elgee as a basis for child themes. All files that originated in this theme should eventually have a PHPDoc doc block at their top and all functions will eventually have associated doc blocks as well.
This is very much a work-in-progress but I hope to have the theme thoroughly documented within the next couple of revisions.
BuddyPress 1.5 Support
The recently-released BuddyPress version has radically changed the way many of BP’s core functions work. I’ve adjusted the included theme templates included in Elbee Elgee to compensate for this and am fairly confident that this theme is one of the few freely-available themes out there to offer such.
bbPress 2.0 (Final) Support
There have been some minor revisions in support for bbPress. Not much changed between 2.0 betas and the final release, so not much has changed internal to Elbee.
bbPress Single-Column Layout Support
Tucked away in the new bbPress tab you will see the options shown at right.
Previously, theme users employing 2- and 3-column layouts were potentially constrained in their forum views. Personally, I feel like bbPress tends to feel a bit “cramped” in the cases where it has to contend with sidebars.
In order to address this, I added the ability to disable the default sidebars and default footer widget areas.
Check out the examples below for a taste of what I’m talking about.
Here we have an example of the standard 2 column layout.
And here’s what it looks like without sidebars. Much breezier, no?
Here we have both sidebars and footers disabled, for those who really dislike widget areas cramping their style.
CSS-Only Drop-Down Multi-Level Menu Support
1.3 And 1.3.1? Huh?
1.3, the version currently available in the WordPress.org theme repository, actually contains a small bug that will incorrectly limit layout options if you have bbPress enabled. I’m in the process of getting 1.3.1 approved and your auto-updaters should pick up the update as soon as it’s cleared by the Theme Review Team.
In the meantime, if you want to grab a copy of 1.3.1 to install directly:
I’m excited to announce the first public release of my oft-delayed theme, Elbee Elgee. It’s available right now over at its page on WordPress.org. I’ve been working on this for the better part of the last few years, picking at the code here and there but never with any real drive towards a release.
Why Release A “New” Theme?
As I said above, I’ve been kicking this theme around for several years. It’s been the engine powering Literal Barrage (in various incarnations) and I’ve always meant to release it, though I’ve always lacked the motivation.
Chip and Michael’s respective theme releases lit a fire under my butt and I decided to get the theme into shape for release.
I wanted to make sure I understood the WordPress theme development process from front to back and I wanted to integrate some ideas that had been floating around in my head since I published my original theme options page tutorial.
After several rounds of bugfixes and refinements, I cleared the WordPress Theme Review Team’s review process and, well, you can see the result over at the official demo site (or you can check out your current surroundings — Literal Barrage is running a child theme of Elbee Elgee).
What’s so exciting about Elbee Elgee?
I’m pretty psyched about several noteworthy features that I’ve included in this theme. Check ’em out below. …
Regular readers will no doubt have noticed that this site is undergoing some visual changes. I had grown tired of the old look and thus am undertaking a bit of a rehabbing. There are all sorts of nits to fix (the archives page doesn’t work correctly, for instance) and I felt that I needed some inspiration.
While the code underlying the site is still going to be the Elbee theme I have been working on (forever!), you should notice a bunch of different visual tweaks to that code in the coming days and weeks. I’m by no means wedded to the black and white, high contrast look, but I felt that I needed to strip the site down to its essential visual “bones” and then add things back in, give myself a chance to figure out what works, what doesn’t, what needs to stay, what needs to go, etc.
So, thanks again for your patience and I’d love any feedback you might have on the subject.
NOTE: This tutorial is old and out of date and predates much of what is now state-of-the-art in the WordPress world. Instead of pursuing this method, check out One Design’s How to Create a WordPress Theme Options Page for an up-to-date take on creating theme options pages. I’ve removed the downloadable .zip file containing my old functions.php in order to remove confusion.
NOTE: The contents of this post may shift about a bit as time goes on. For some reason, the code-highlighting plugin I’m attempting to use isn’t working correctly. There may end up being some more code snippets that find their way into this post if I figure out what’s going wrong. Fixed it by moving to a different code-highlighting plugin. Dunno what the issue was, but it’s gone now.
For theme authors looking to customize their theme offerings with a fancy options/administration screen, functions.php is the place to start. By default, WordPress loads it whenever your theme is active — on the front page or on the back end. A brief discussion on the wp-hackers mailing list today prodded me to post the following code from the functions.php I’m including in Elbee Elgee (whenever I get around to releasing it, that is…). I took the guide offered by The Undersigned as a jumping-off point and added some nice tweaks. In particular, The Undersigned’s version only allowed for text and select form inputs — I wanted/needed more flexibility.
The file itself is fairly simple and almost self-documenting, but in the interests of full disclosure, I’ll comment upon it here:
1. I set the descriptive and short names of my theme at the head of the file.
If you were paying close attention, you would have noticed that the “Elbee Elgee Development” section of my footer was messed up for the past few days, and with good reason. That little bit of content is generated by parsing the RSS feed for the timeline on my Elbee Elgee Trac installation. Sometime earlier this week, the SQLite database that provides the backend for that install freaked out and locked itself up good n’ tight which necessitated me spending several hours debugging and de-wedging the DB.
The problem can be summed up thusly: it seems that Trac sites running on FastCGI have a tendency to try to access the default SQLite database fairly quickly and, if the DB files happen to be stored on an incorrectly-tuned NFS share, a race condition can ensue and incorrect file locking can occur, leaving the DB in a locked state.
It was initially a very long and frustrating process, as I scoured teh Googols for information on how to unlock a SQLite database. I found that a second file was created in the db/ subdir of my Trac site – trac.db-journal, which apparently indicates that a transaction is in progress or was incorrectly aborted. Search result after search result implied that one could unlock the database by
Killing all process accessing the file
Moving the -journal file
Moving the .db file itself
Rebooting the machine
Since I’m on a shared hosting account at Dreamhost, options 4 and 5 were obviously Right Out. No amount of lsof or fuser tweakage, combined with judicious use of `kill -9` managed to unwedge the DB, so #1 was a bust. Options 2 and 3 allowed me to use the sqlite command line tool to connect to the database and run SELECT statements, but any INSERTs were met with “Database locked”-style error messages and thus Trac stayed broken.
Then it hit me – since I could SELECT, I could (conceivably) dump the contents and then reimport them into another DB. I cd’d into my Trac site’s db/ folder and executed the following: