Elbee Elgee Support Omnibus

Howdy all.
I’ve been fielding a lot of support requests about various aspects of Elbee Elgee, but most of them have been via email, so I figured I would summarize said questions and their answers so that all can benefit.
You know — I made a FAQ *grin*
Check it out and let me know if there’s anything I missed.

Elbee Elgee Version 1.3.5 Released

For those of you with Elbee Elgee installed, you should be seeing an update to version 1.3.5 showing up in your “Dashboard -> Updates” shortly. This is a bugfix release intended to remove the div element in the header that is shaded to 50% opacity when users select “Display Text: no” in the Headers options.
Previously, the theme would incorrectly remove the header text but leave the 50% div in place, thus partially obscuring the left-hand portion of header images. This release fixes that.
If you’re the impatient type and want to grab it from the official repo page instead, that’s an option too.

Elbee Elgee Version 1.3.4 Submitted To The Repository

I’ve fixed a little bug that cropped up in Elbee Elgee 1.3.3 and have submitted 1.3.4 for approval over at the Theme Repo (you can track the ticket here if you’d like).
The change is pretty simple, actually:

  • Version 1.3.4
    • Issues Fixed
      • Fixed CSS selector specificity oversight that caused active menu items to appear “invisible” in default ng.css styling.

Thanks to Mitka and Michael for pointing this bug out.
If you can wait, the fix should roll through in the next couple of days. If you can’t, I would advise the following:
Change line 167 in styles/ng.css from:

div.menu a:active, div.menu a:hover {


div.menu a:active, div.menu a:hover,
#menu li.current_page_item a:link, #menu li.current_page_item a:visited,
div.menu li.current_page_item a:link, div.menu li.current_page_item a:visited {

Elbee Elgee 1.3.3 Is Now Live In The Theme Repo

Just a small programming note: the latest stable version of Elbee Elgee is now live in the theme repository. The changelog is fairly sparse and goes to support WordPress 3.3. Mainly:

  • Issues Fixed
    • Switched from wp_print_styles() to wp_enqueue_scripts() to enqueue/output CSS due to changes in WordPress 3.3 (see here for details).

Go forth and download!

Elbee Elgee 1.3.2 Approved; 1.3.3 Incoming

I’ve released Elbee Elgee version 1.3.2 to the WordPress.org themes repository. The update got a clean bill of health and should be showing up in your WordPress Updates screens as soon as the Powers That Be mark it for “sync”.
This is a small update that addresses the menu issues some folks were seeing involving mutli-level menus. The quick fix was to make sure you specified a custom menu for the Primary menu location but 1.3.2 should fix it from the back-end side of things.
Additionally, I’m cobbling together a 1.3.3 release for WordPress 3.3 support (keep tabs on its status in the Theme Repository here. The change is minor — WP3.3 changed the way CSS stylesheets were included (see here and here for details) and so some of the Elbee Elgee styling has started to “bleed” over into the WP administration interface.
Ain’t that the way of things — I release a bugfix and then have to follow it up with another one, short-order? *grin*

Announcing: Elbee Elgee

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.
Then came Oenology and Ghostbird.
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.
Continue reading “Announcing: Elbee Elgee”

A Theme Tip For WordPress Theme Authors

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.

$themename = "Elbee Elgee";
$shortname = "lblg";

Continue reading “A Theme Tip For WordPress Theme Authors”


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

  1. Killing all process accessing the file
  2. Moving the -journal file
  3. Moving the .db file itself
  4. Restarting Apache
  5. 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:

echo '.dump' | sqlite3 trac.db > trac.dump; cat trac.dump | sqlite3 trac2.db

Using the sqlite3 command line tool, I verified that everything was copacetic and breathed a sigh of relief. Stupid SQLite.
I guess this seals it: when I finally move from Trac 0.9.6 to 0.10.3, I’m going to move to a real RDBMS like MySQL so this sort of stupid file locking crap doesn’t happen again.
NOTE: Apologies for the 3rd Grade-level insult inherent in this post’s title (it’s pronounced “Suck-well Lite”). Pretty much sums up my feelings, though.

Palette Swap!

I’ve had various and sundry people comment that the old default look/color scheme for my site was “too dark” so, in the interest of catering to the masses, I’ve done a bit of a turn-around, colorwise. Let me know what you think – the scheme still has some rough edges that I’m working on, but it’s pretty well tracking the development version of Elbee Elgee (the theme that Literal Barrage is currently running on).
So please, let me know what you think of the colors – what needs tweaking, what you like, what you don’t like, etc.
On the Elbee front, I’m quickly nearing a point where I feel like I could release it to the public. Beta 2 is approaching (yes, I know it says “4 months late” – that’s just about right…) and I think I’ll release it when I hit that landmark.

A Plea For A Bit Of Help From You IE-Savvy Web Developers Out There

I’m slowly working my way into making Elbee Elgee into a releasable theme and I’ve been merrily plinking away on my MacBook Pro, validating the look and feel in Opera, Safari and Firefox. However, I’ve also been trying to verify it using Internet Explorer while at work and have been driven to distraction by IE’s broken box model and hideous “float:” handling.
I’ve based my three generalized image handling CSS classes on K2‘s since I used it extensively in the past and thus have a lot of posts with “class=’alignright'”, etc., hardcoded into them. I (naively, it seems) thought that K2 had IE behavior down, which apparently is just about the furthest thing from the truth. Stock K2 looks pretty funky in IE, I have to say.
So here’s my quandary: I really, really want my .alignright, .alignleft and .center image classes to work in IE as well as they do in Opera, Safari and Firefox. When I set an image to .alignright, I expect to see the following:
In IE, the text smooshes up against the image and is visible behind the padding and border on the image.
When I set an image to .center, I expect this:
Instead, “centered” images are mashed up against the left side of the story body with the left border and padding cut off.
So all y’all web designers out there, help a fellow traveler out. My base CSS file is available here (just so you don’t have to do a “View Source…” to get it). I know the fix has to be a simple, stupid one that I’m missing, but I’ve kind of exhausted all the tricks I know.