…but the patent thing has not only taken a ton of my time, it’s sort of killed my desire to write much of anything of late. Add in some long-deferred household projects, and blog stagnation is the result.
I’m not quitting, but it may be a bit quiet around here for a while longer yet.
Note: If you’re not running a WordPress blog and using its built-in gallery feature, the following will be of no interest to you; it’s posted here mainly to make it easier for me to find in the future, when I forget it once again.
WordPress includes a simple-but-usable gallery feature. Unfortunately, posts with embedded galleries display a thumbnail for every image in each gallery—and there are no options to limit the display of thumbnails. While fine for shorter galleries, such as this one, if you’ve got a lot of images, this can make for an ugly page.
What I wanted was the ability to include an image gallery in a post, but not show a thumbnail for every picture in the gallery. Ideally, I’d just be able to use the first image from the gallery, or perhaps even a text link. After a lot of fruitless searching, I finally found the very simple answer in a post by malissas in this thread.
One of the issues with blogs is that, over time, links embedded in posts can break. Sometimes they break in graceful ways (redirecting to an acquiring company’s site), sometimes in not so graceful ways (“Site not found!”), and sometimes in downright horrid ways (a porn spammer takes over a URL).
I wanted a way to test any URL in entries I’ve posted here, so a buddy wrote the basics of a tool to query the database and extract URLs from the posts. I took his core, then did some digging on the web, and mangled together a simple PHP app that will scan all your blog posts for URLs, and test to make sure each one still connects.
The results are displayed in an ugly-but-usable table form:
The first column is the URL being tested, and the second column displays the post numbers where that URL can be found. Any highlighted rows reflect dead links; no highlighting means that the URL opened as expected. Read on for the code and a basic how-to…
After seven years, quite a lot has changed. I’ve gotten rid of all but one of the items on the original list, and found some very useful new additions that help both me and visitors
From that original list, the one leftover Plugin is Ajax Comment Preview, which implements a true click-to-view comment preview function. The others went away either because I wasn’t using them any more (weather in the sidebar, how quaint), or because WordPress’ built-in features made them redundant.
Keep reading to see what’s keeping the site ticking now…
As you can see (unless you’re using RSS, in which case, visit the site to see), there’s a new look around here. According to the datestamp on the folder, my old theme (which I named “macbar” for no obvious reason) went live in January of 2007. In internet years, that’s like 300 years ago.
The age of the theme showed, too. Graphics were heavy, textures overbearing, and (worst of all) the site was entirely fixed in size, which made for a horrid mobile experience (and it wasn’t great on big screens, either). As a reminder of the “good old times,” click the image at right for a flashback.
So say hello to “macbar2014,” if only because I’m too lazy to think up an exciting new name. The new theme is responsive down to iPhone size, and also expands to fill 1400 or so pixels of width. Beyond that, the text field stops growing, as honestly, it gets hard to read if it’s too wide. But that still gives a much wider reading area than the old theme.
With the new theme comes a renewed focus on keeping the blog up to date; it’s my plan to post here more regularly post, including more detailed looks at some of the 140 character observations that I blast out on Twitter. I’ll also link to my Macworld articles, as much for my easy future reference as anything else.
Read on if you’re at all interested in the tech details behind the site do-over… (more…)
For the last few weeks, I’ve been getting hundreds of registrations here, and given (a) there’s no reason to register except to post a comment, and (b) there aren’t very many comments posted, I figured something was up. Until yesterday, though, I didn’t know what was going on. Now, thanks to the WordPress 2.6.2 release, I do:
With open registration enabled, it is possible in WordPress versions 2.6.1 and earlier to craft a username such that it will allow resetting another user’s password to a randomly generated password. The randomly generated password is not disclosed to the attacker, so this problem by itself is annoying but not a security exploit. However, this attack coupled with a weakness in the random number seeding in mt_rand() could be used to predict the randomly generated password.
In other words, by registering often enough with specially-crafted usernames, you may eventually be able to force the admin user’s password to be reset to something random, and you may know that random password. Scary stuff. So today, I upgraded to 2.6.2, and cleaned out the vast majority of recently-created accounts.
If you’d signed up for a legit account and I zapped it, please just register again — and sorry for the inconvenience.
Today, WordPress released WordPress for iPhone. So I thought I’d try it out–given how little I post here, any excuse to write something is worth a shot!
Anyway, we bought this electric pump to inflate our kids’ pool. I found the combination of the warning and the left-hand image somewhat at odds with each other! (In case the image isn’t clear, that’s the pump being used to inflate a child’s swimming pool, which is not generally considered an “indoor household” item.)
After a mostly-painless upgrade, we’re now running WordPress 2.5. About the only hiccup is that the Addicted to Live Search plug-in (which I am addicted to) doesn’t seem to work right with anything other than the default permalink style. (Permalinks are the URLs for individual stories.)
The default permalink style is ugly and doesn’t necessarily work well with search engines, but I love the search feature so much I’m using them for now…hopefully the plug-in will be patched in the near future.
After some investigation with help from a couple of very useful people (thanks, chays, Ryan, and Donncha), we’ve determined that the files I found on my server were placed there as a result of the WordPress 2.3.2 vulnerability, even though my site had been updated to 2.3.3.
To make a long story short, if your site was affected by the 2.3.2 vulnerability, you must change your admin passwords. While the attackers can’t get the actual password, they can continue to login as admin ever after you upgrade to 2.3.3. That’s because the cookie they received when exploiting the hole in 2.3.2 will still work in 2.3.3 — unless you change your password.
In everything I read about the 2.3.2 exploit, I didn’t see anything about the passwords being exposed, so I didn’t change it when I upgraded to 2.3.3. Lesson learned…