Mostly about my amusement

Tag: WordPress (page 7 of 13)

Moving WordPress again

I have been running my blog on the URL wp.dembowski.net for years. If you are familiar with WordPress then that’s an OK URL to use but most people are more comfortable with a generic name.

I did not want to use www.dembowski.net (already used for a place holder) and did not want to put move to a folder off of the web server. So I picked blog.dembowski.net and moved my WordPress install this morning.

It went very well.

I created a new virtual server for blog.dembowski.net on my server and enabled it in Apache 2 (a2ensite blog.dembowski.net) and copied all of my files from the old wp directory to the new blog directory.

I used my nightly backup script and produced a text file of my mysql database. I then ran this command on that text file:

$ cat wp-database.sql | sed -e 's/wp.dembowski.net/blog.dembowski.net/g' > new-database.sql
$ cat new-database.sql | mysql -D blogdbname -u blog-user -p

I did it that way on purpose so that I could always restore the old wp.dembowski.net setting if I messed this up. By hunting through and changing every instance of wp.dembowski.net to blog.dembowski.net in the database backup file, I guaranteed that even obscure plugin settings would get updated as well.

In my old directory I moved everything out and left a two line .htaccess file like so

RewriteEngine on
RewriteRule (.*) http://blog.dembowski.net/$1 [R=301,L]

That way any hits to http://wp.dembowski.net/some/thing/here/ will get 301 Permanently Moved to the same URL but on http://blog.dembowski.net/.

After a little testing everything is confirmed to be working. I am in the process of updating my stats settings in Clicky and Google Analytics but so far so good.

WordPress 2.9 is released!

I just got home from Christmas shopping and my SVN pull down of the trunk was 3.0-alpha.  Which told me 2.9 is released and I should switch to the 2.9 branch.

As always it’s just

cd wordpress-directory
svn sw http://core.svn.wordpress.org/tags/2.9/

And that’s it. I’m now on the 2.9 branch.

I’ve been using the 2.9 beta for a few weeks now and what I think will make this release a success is that it looks almost 100% identical to 2.8. Change on the back end is well recieved; change the UI and it’s an open revolt…

The WordPress user base can be a fickle group and each release brings a set of complaints.  I have not had any incompatible plugins (and I never do) but new releases always brings “issues”.

You can read up on the official notice here.

List of changed files

When ever a new release comes out, people want to know which files changed.  With every major release it’s always a lot and going from 2.8.6 to 2.9 really means do the whole thing. It’s 286 modified files that are different from 2.8.6 to 2.9.

Running this command got me the output.

$ svn diff --old=http://core.svn.wordpress.org/tags/2.8.6 --new=http://core.svn.wordpress.org/tags/2.9 | grep ^Index | sed -e's/^Index: //' > wordpress-286-29.txt
$ cat wordpress-286-29.txt | wc -l
286
$

You can view that list of changed files I created here. Also visit the codex link on 2.9, it’s a good description of what got in and what didn’t.

Beware the canary mismatch on efree monster

For traffic logs, I use Clicky Web Analytics and take a look from time to time. See that flat dark blue line? Around noon on December 3rd my blog stopped serving web pages and it was not until about 5 hours later that I noticed it. I don’t get a lot of traffic but I do like my blog to be working.

It wasn’t that my VPS went nuts, the CPU usage was fine. What was happening was that my PHP interpreter was tossing hundreds of these errors.

[Thu Dec 03 12:17:27 2009] [error] [client 66.249.71.233] ALERT - canary mismatch on efree() - heap overflow detected

Not cool and until I restarted Apache2, my blog was not serving anything. PHP just kept blowing up. This has been an ongoing problem for me that has been attributed to the Suhosin PHP security patch and I had not found the magic bullet to fix.

I’m not going to disable the hardened PHP. That’s like turning off the safety switch on an excercise treadmill. It’s juts not safe.

As a work around I have done the following: I activated the WP Super Cache plugin, removed the Xcache op cache I setup, and disabled the ssh2 PHP extension I installed.

The WP Super Cache created static HTML pages for your dynamic content.  It does cache expiration, garbage collection, etc. and limits the amount of time PHP needs to be run.

The XCache was a hold over from when I was running my blog on a Pentium II.  The VPS I use is very responsive and losing it does not hurt me.  Using the Pingdom tools I can see that I still get a good response from my web server.

Losing the ssh2 was easy; I only added it to my PHP to be able to answer a WordPress support forum questions. I never use it. I’ll look for any other PHP extensions that I added as a “what the hell” but so far so good. No more canary mismatch errors as yet.

Get your red hot WordPress 2.8.6

WordPress 2.8.6 is out and it’s a security release so update now.

I’m expecting the usual complaints on the support forum but so far it’s been pretty sedate. I’ve been using WordPress since version 1.5.2 and I’ve never had a bad upgrade. Of course, I have a good idea what I’m doing and have never used the automated upgrade process, so your mileage may vary.

As is usual, using SVN only took me a few minutes to upgrade 6 blogs on 3 different machines.

WordPress: Upgrade or DIE!!

That’s a catchy title. Keeping up with the versions of any software that you have installed is almost always a good thing. If you have any WordPress version pre-<insert-latest-version-here> then you should upgrade.

To me, open source software is best if only for one reason: vulnerabilities get discussed openly and often fixed very quickly. Open discussion is not a bad thing; people who exploit software on the Internet have their own forums too.

There is currently some hacks going on involved with older versions of WordPress. I am sure the details will come out but for now the remediation is upgrade to the latest version.

That’s not unreasonable. WordPress is not a paid software company (spare me the comments about Automattic, that’s a service company and the service they provide is the blog hosting) and there are no SLA or support contracts on a specific version of WordPress. Why should developers maintain multiple version trees of the software? That was tried with the 2.0.x release for Debian reasons but that didn’t work out.

Using software on the Internet is a game of keeping up with the Joneses and being responsible.  Your hacked server is not just hurting you, it’s making the whole neighborhood look bad and ruining it for everyone else.

So Upgrade or Die. Keep your software current.

Update: This is a fun read on the WordPress support forums. Most of the hacked/security threads turn into real name calling entertainment which in turn targets people who are trying to help them. Here’s how it works: someone gives solid practical advice, and someone else complains that their feelings were hurt. Name calling ensues.

Sad to say, but some people believe that free open source software means that the community must keep them safe from their own laziness ignorance stupidity inability to manage their own installations.

Sometimes a site gets hacked regardless of best effort. It happens and you deal with it. But these end users who don’t do what they need to? They continue to hang out in Darwin’s waiting room.

Sing those upgrade blues!

With every release of WordPress there are always people who have problems. That not unusual since change can bring unexpected issues.

Most of the WordPress forum users are just looking for help and are in above their heads. Those users I can respect, asking for help should be encouraged. Providing help can be satisfying and I refer to it as “therapy”.

Then there are those other users.  You know the ones, the pissed off users. These are the ones who seem to feel like there is an SLA that is not being honored by the “WordPress” guys.

Here is a current sample from the WordPress.ORG support forum:

“It wiped my website completely and it wiped 3 more website hosted on my server. Now really, do you test these things? And why is it still available for auto upgrade if you see what problems people have here ?”

“Who released this Fiasco?… Is this untested beta junk?”

“Who’s responsible for this crap ? Did anybody do any honest and real testing on it?”

“Thanks a lot, WordPress! I always love having my blog borked just for doing an upgrade, per the instructions. I’m in the process of rolling back to 2.71 and never upgrading again.

What idiot released 2.8?”

If I were these users, I would demand my money back. That’s no way to treat a paying customer.

Everyone should understand that the support is all volunteer driven. If you don’t provide details, if you are not willing to provide those details, and/or you come across as a petulant child, then don’t expect anyone to step up and help.

I’m a fan of WordPress software. It’s well written, mostly well documented, and the volunteer support generally is successful. If you provide some details of your problem then you’ll usually get a solution.

With version 2.7 and above, the software provides a built in auto upgrade. But it’s not fool proof and can go awry. When that happens, the blog user must become the blog system administrator. Not unusual: to properly host and appreciate WordPress you must develop some system administration skills.  This is a requirement, it’s not optional.

So before users push that upgrade button they need to have a Plan B for if it goes wrong.  That plan can be as simple as wiping out the installation and restoring the backup up made right before you tried to upgrade.

Here are some WordPress Codex URLs to keep in mind and read up on:

Upgrading WordPress
WordPress Backups
Backing Up your Database
Restoring Your Database from a Backup
Disabling Plugins when you can’t login

Version 2.8 was tested and vetted. But when you have +330,000 downloads, some of those users will have problems. It’s to be expected; the people who ran the beta code knew what they were doing. Many users just have not gotten there yet so they need more help.

So if you are using 2.8 and still have problems, take a look at this 2.8 Problems and Solutions FAQ that MichaelH quickly wrote up. From the feedback it seems like this is working well for the problem cases.