XAMPP

Welcome WordPress 2.7

Send to Kindle

I just upgraded to WordPress 2.7. It was super simple, no glitches whatsoever.

Earlier in the day, I noticed that there was an updated version of the Simple Tags plugin that I use, clearly stating that it worked with 2.7. I upgraded that while still running 2.6.5.

Then I upgraded WordPress to 2.7 on my laptop, running XAMPP. The only complaint I got was about Simple Tags, which I hadn’t upgraded on the laptop (and I updated it then). All other plugins just worked, and the new theme, PrimePress just worked as well.

I hadn’t installed any betas or release candidates before, so this is my first real look at the new admin interface. I’ve seen screen shots, and it’s crisp, clean and reasonably intuitive.

I’m officially a fan, even though I clearly haven’t exercised it in any meaningful way yet. 🙂

P.S. First glitch, the Preview link gave me a 404, so something isn’t being put where it should be. Can’t find an obvious cause, so I’m punting for now, and just publishing. I’ll track down my preview problem over the weekend…

Update: I just did a test of Preview on the laptop, and it worked fine. So, there isn’t anything wrong at the WP level. I am now quessing that something about the URL scheme for Previews changed slightly, and my own rules at the NginX level are failing (the equivalent of Apache rewrite rules). When I’m sure, I’ll update again…

Solution: This morning, I discovered that if I override the permalink in the preview URL and use the old-style ?p=NNN format, the preview worked. That allowed me to search with more detail. That turned up the following patch. Ironically, the patch was just posted yesterday, so I wouldn’t have found it on Friday anyway. I don’t know if it works (because I haven’t made a new post since I applied the patch), but at least I can preview by using the old-style URL if need be…

Firefox DOM Inspector

Send to Kindle

Yesterday, I raved about XAMPP in this post. In there, I made the following statement:

The other major thing that I don’t like (but which I suspect is easily fixable with a CSS tweak) is that the Sociable plugin formats the icons in a list (one per line) rather than as an inline string of icons, which other themes are doing correctly…

So, today I spent quite a bit of time playing. I enjoyed it, and it was instructive as well. I was able to easily change a bunch of things that I didn’t like about my previous theme. That said, I really like a lot of the Aspire (current) theme, other than the dark image background (which I can live with) and the note above about the sociable list not being inlined.

I decided to experiment in my new sandbox with the Aspire theme. I couldn’t find an easy way to see what css was controlling what element. A quick search said that the built-in DOM Inspector in Firefox could help resolve this. It wasn’t in my Tools menu. It turns out it isn’t installed by default on Windows. I reinstalled Firefox, selected custom, and voila, I had the DOM Inspector.

Once I inspected a page, it became obvious what the problem was. The Aspire theme defines an ID main. Then, in addition to default definitions of ul and il (unordered list, and list element), it also defines #main ul and #main il (specifically, an unordered list which appears in the main block, and the same for a list element in the main block).

The DOM Inspector showed me that the sociable.css was correctly being loaded, but that the way more specific #main selector was being applied after the sociable.css was parsed. As annoying as it is/was, there’s some logic to it. If a node can be defined ultra-specifically, and there is a css definition associated with that, then perhaps, you really want that to apply.

Unfortunately, the specific definition had display: block instead of the desired display: inline.

I’ll spare you the stupid gymnastics I performed, trying to over-ride that behavior. Suffice it to say that along the way, I tried doing something like this:

#main.sociable ul

ul#main.sociable

among other utterly useless attempts to get even more specific.

I broke down and sent a message to the current maintainer of the sociable plugin. Then, two minutes after sending him the message, while browsing formal docs for css, I stumbled on something.

In some of the attributes in the sociable.css file, he added !important to the end of the definition, in others, he didn’t. In the docs, I saw that normally, !important is used to signal to the browser that this particular attribute is important, and should be respected over a defaulted value. It’s primary use is to allow users to have stylesheets which over-ride authors stylesheets.

So, I thought, let’s experiment and add !important to the few attributes that weren’t already tagged as such (specifically, the display: inline one!). Voila! Now, even though the browser sees that #main ul comes after .sociable ul, it also knows that .sociable ul said that display: inline was !important, so it retains it!

There may be a better way to solve this problem (after all, this required me to edit the author’s version of sociable.css, which would get wiped out the next time I upgrade the plugin), but, without my sandbox (courtesy of XAMPP), I wouldn’t have found this one. In addition to XAMPP, I now also need to thank the Firefox DOM Inspector. 🙂

Updated Theme and XAMPP

Send to Kindle

For a while now, I’ve been both relatively happy with my theme, as well as marginally frustrated by it. I don’t need to bore you with exactly what I didn’t like, so I’ll bore you instead with what I’ve done about it. 😉

I have never bothered in the past to dig too deeply into the inner-workings of WordPress. Also, while I understand CSS, and have played with it a while ago, I certainly haven’t looked at anything relating to how themes interact with CSS. Before you call me an idiot, I realize that the themes define selectors, and that the style.css file in the theme applies the style, but what I don’t know (because I haven’t bothered to look!) is how defined the selector names are by WordPress, or whether every theme designer just does whatever they want.

Anyway, every once in a while, I download a new theme that looks like it might meet my needs a little better. I use a plugin called User Level Themes by Double Black Design. It’s very cool. I then set the Admin User only, to see the new theme that I downloaded. I can now test the new theme, on the live site, without affecting how the normal (anonymous) reader sees the site. If I like it, I can change the theme for the anonymous user as well.

So far so good, and I’ve been pleased enough with that level of testing. Even so, I haven’t switched my theme for months (well, not totally true, as I updated to a tweaked version that another user modified from the original author of my theme). One of the reasons is that when I see a new theme that has elements that I prefer, there’s usually at least one element that I can’t stand, so switching seems silly.

The straw that broke the camel’s back for me the other day was that I downloaded a theme that hard-coded some tag cloud layout. That meant that since I am using the Simple Tags plugin by Amaury Balmer, which uses it’s own tag cloud widget, I was getting two tag clouds. It made me realize that to really test these things, I might have to make changes that would affect the anonymous user (like redefining the sidebar widgets) even though the theme didn’t change.

Ugh…

I realized that to get what I want, I will likely need to dive in a bit, and tweak the theme that comes closest to what I want. That might involve some PHP (which I can read, but have never written), some understanding of WordPress, but really hopefully not much more than CSS tweaks.

To do that properly, I really wanted a segregated playground, where I could make changes willy nilly, even breaking the site completely (I’m very much a trial and error kind of guy). That led me down a long path of thinking about the easiest ways to set that up, in a manner where I could easily tear it down and start again, etc.

That led to thoughts of a cheap hosting provider with something like cPanel, where I could just reload the environment if I wanted. Then I thought of putting up a server at home for this, and running VMWare or Xen, etc., to be able to reload an environment quickly. Then I thought of just using the VMWare Player on my laptop.

Finally, while searching for the lightest weight Linux server distro that would support that (in order to tax my laptop the least), I accidentally stumbled across XAMPP. It comes in multiple flavors, including Windows. Then I noticed that they also had a lite version, which was all I needed. Apache (recent release), MySQL (relatively recent) and PHP (recent release).

I chose the ultra-small 7-zip auto-extractor version (18MB download). It doesn’t touch the Windows Registry at all. When you’re done playing, you can just blow away the directory structure, and you’re done. They give you a controlling application (not needed, but a nice touch), to start and stop individual components. You can do it all on the command line as well, or you can set them to be true Windows Services and they will auto start with the machine.

I tar’ed up my WordPress directory, dumped my MySQL database, copied them over to the laptop, and everything almost worked on the first shot! The only problem (the manifestation was large, but the solution was trivial) was that my blog URL stored as an option in the database pointed back to opticality.com. So, when I tried to log in to the admin UI, it redirected me to the real site, which was not what I wanted.

I updated that option in the local MySQL database, and it all started working. All of my posts were here locally, and my plugins were working too. Extremely cool!

I quickly realized that I should deactivate a number of SEO oriented plugins (e.g., Google Analytics, WordPress Blog Stats, etc.).

Now I had a playground. Based upon just a few minutes, I made some decisions (which should be obvious on the live blog at the moment). Until I decide to make any changes to a theme myself, I have done the following:

  1. Changed the theme to Aspire (credits are in the footer)
  2. Removed the Advanced Search Lite plugin
  3. Added a POLL to get feedback on the theme change

I like the way Aspire lays out the post better than my last theme. I don’t like that it’s hard to read unless I keep my monitor on a bright setting (I typically lower the brightness of my monitor way down). Unfortunately, the background (which is darker) is controlled by an image, not a CSS selector, so this is one of things I don’t like about this theme. The other major thing that I don’t like (but which I suspect is easily fixable with a CSS tweak) is that the Sociable plugin formats the icons in a list (one per line) rather than as an inline string of icons, which other themes are doing correctly…

I actually like all of the choices that the Advanced Search Lite plugin provided. That said, there are a number of reasons why I removed it.

  1. It took up a lot of screen real-estate
  2. I doubt it was used much
  3. If it was used, I doubt people selected options
  4. Now that my comments are on Disqus, that feature wasn’t as interesting

Feel free to vote on the Poll. In addition, please feel free to comment here, in particular if you have had the same kind of tweaking needs/desires that I have, and have a solution/theme that you really like as a result!

To summarize, all I’ve done for now is switch the theme to Aspire. I haven’t touched it in any way. But, at my convenience, I can now play to my heart’s content on the laptop. For that, I have the folks behind the XAMPP effort to thank, so here goes:

Thanks XAMPP guys!