Posts Tagged ‘wordpress’

Upgrade WordPress automatically

Sunday, July 7th, 2013

WordPress has a one-click upgrade feature, but it requires you to give it your FTP/SFTP credentials. If you log into SSH with keys instead of passwords, you can’t use it. I wrote a script that runs on the server (thus it needs no password or special permissions) to back up your current files, then upgrade.

Lines 6 through 10 features variables that you’ll probably want to alter before you run this script.

A few notes:

  • It only backs up the files, not the database, so if WordPress has a database update that breaks your database, hopefully you’ve got some other backup in place.
  • Sometimes after an update, WordPress will prompt you to please update the database. This script will not do that step – you still need to log in and click the button. This script will send you a reminder that an upgrade has been performed and which will allow you to both confirm that nothing was broken, and click the aforementioned button. I don’t trust myself to act on that reminder promptly, so I haven’t set this script to automatically run. Instead, I have a reminder on my phone to go run it manually.
  • A future version might delete all the old backups (both WordPress versions and websites).


#!/bin/bash
# Created Sept 1, 2012
# Last updated July 7, 2013
# Automatically update WordPress.
 
# Alter these to reflect your environment
website='~/public_html' # website and htdocs might be the same. If unsure, keep them identical.
htdocs='~/public_html/htdocs'
email='you@example.com'
sitename='My web site'
 
date=`date +%y-%m-%d`
log=wp_upgrade_${date}.txt
 
if [ -f latest.zip ]; then
rm latest.zip
echo Removed old latest.zip >> $log
fi
 
wget http://wordpress.org/latest.zip
echo Got latest version of WordPress >> $log
 
unzip latest.zip
echo Unzipped latest version of WordPress >> $log
 
# Create old/ if DNE
if [ ! -d old ]; then
mkdir old
echo Created directory for old stuff >> $log
fi
 
# Create a backup of your website before making changes
htdocs_dir=`basename $htdocs`
new_htdocs=${htdocs_dir}_{$date}
cp -Rv $htdocs old/$new_htdocs
 
echo Copied htdocs to $new_htdocs >> $log
 
# Put the files for the new WordPress version into your website.
cp wordpress/* $htdocs -Rv
 
echo Dumped new WordPress into htdocs >> $log
 
# Archive this version of WordPress. You could probably delete it, but I like to have a clean copy around in case I muck up the code.
mv wordpress/ old/wordpress_${date}
 
echo Copied pristine WordPress code into old/ >> $log
 
# Sometimes it has database upgrades and a human needs to visit the site
# to tell it to go ahead, so this e-mail serves as your reminder.
mail $email -s "Wordpress updated on $sitename - go check it out" < $log

Assuming you store this in ~/bin/upgrade_wordpress.sh, you can run this script monthly automatically with the following steps:

  1. At a prompt, type 'crontab -e'
  2. On most systems, this will open vi. Type "i" to insert text.
  3. Paste:
    0 0 1 * * ~/bin/upgrade_wordpress.sh
  4. Push the ESC key to exit insert mode.
  5. Type ":wq" to write changes then quit vi

How to never again see WordPress’ update nag – no plugin necessary

Wednesday, February 8th, 2012

One reason I like WordPress is because they come out with frequent updates. When you run a WordPress site, it checks periodically for new versions. It reminds you with a helpful little yellow bar at the top. It feels great to install a new version, be up to date, and get rid of the nag. However, because of their awesome frequent updates, it also means you’re only ever free of that annoying reminder for a couple days.

A screenshot of the annyoing yellow bar

While it’s important to keep software up to date, I do have a life beyond updating WordPress. I wanted to get rid of that yellow nag once and for all. There are a couple plugins to disable it, but I don’t see any sense in adding more code (and more plugins to update) when I can just add one line to a stylesheet. So, here is how to rid of it at the cost of 13 characters per page load*:

Open wp-admin/css/colors-fresh.css. All newlines and extraneous spaces have been stripped from the file in the interest of speedier loading (this file loads anew every time you load a page in your Dashboard). Search for: #update-nag

In my version of WordPress, it starts on line 11593 of 34572. Expanded, it looks like the following:
#update-nag, .update-nag {
    background-color: #FFFBCC;
    border-color: #E6DB55;
    color: #555555;
}

Add the following after the opening curly bracket:
    display: none;

When you refresh the admin page, the update nag will be gone forever.

However! With great power moustache CSS comes great responsibility. The WordPress developers made such a prominent prompt because keeping software up to date is important. There are often important security improvements between versions. If you turn off the nag, you still have a responsibility to yourself, your users and The Internet at large to keep WordPress reasonably up to date. Put a recurring item in your calendar to update about once a month.

*You could also eliminate all the other styling applied to the now-invisible element and end up with fewer characters than you started.

Upgrading to WordPress 3.3 – the missing “Format” box

Friday, December 16th, 2011

I recently installed WordPress 3.3 for a client, and I was very impressed. Specifically I was excited about tinkering around with the “Format” box, which allows you to post in a variety of formats, including, “Status”, “Gallery” and the regular post format “Standard”.

I wasted no time upgrading this site to WordPress 3.3, but no fun format box. I poked around at options and Googled, to no avail. Most suggestions seemed to revolve around some browser problem, but I could see it on the other site, plain as day, so my browser was obviously capable of displaying it.

For lack of a better idea, I started grepping. I used Firebug to get the id attribute (“formatdiv”), figuring there would be a finite number of instances in the code. Indeed, there was exactly one. It was in wp-admin/edit-form-advanced.php. There were two relevant lines:
if ( current_theme_supports( 'post-formats' ) && post_type_supports( $post_type, 'post-formats' ) )
    add_meta_box( 'formatdiv', _x( 'Format', 'post format' ), 'post_format_meta_box', null, 'side', 'core' );

This alerted me that it was a problem with the theme, which unsurprising considering that I’m still using a customized version of the 2009 default theme. I knew it worked in the latest theme, twentyeleven, so I went to that directory and grepped for ‘format’ and braced myself for the worst. Once I eliminated the CSS files, it was easy to hone in on line 104 of functions.php
add_theme_support( 'post-formats', array( 'aside', 'link', 'gallery', 'status', 'quote', 'image' ) );

This takes place in a function called setup. I went over to my theme and looked for a similar function in the functions.php file. It did not have one. I pasted it in toward the middle of the file and hoped for the best. The format box appeared like magic. I haven’t actually tinkered with it yet, but I wanted to write up my experiences – before I forget them – so that someone else with an old theme can bring some new magic into their WordPress experience.

Random Blogroll Category v1.5.1

Monday, June 28th, 2010

I just committed a minor revision to my WordPress plugin Random Blogroll Category. The line that was supposed to remove an extraneous HTML tag was completely wrong. The latest version will put out valid HTML.

It’s worth noting that I have no further plans for developing this plugin unless it is broken by a future WordPress update.

A little secret

Friday, November 27th, 2009

I’ll let you in on a little secret: Every once in a while I go to the page of my WordPress plugin to see how many people how downloaded it. I feel disproportionately gleeful every time the number rises. Today it went up to fifteen! And none of those were me! Maybe one day I’ll encounter it in use out in the wild, wild Internet. And when that day comes, I can assure you, I’ll giggle like a schoolgirl.

Why yes, I do make a habit of publishing secrets on my blog, why do you ask?

Last night’s research: CiviCRM, Drupal, Joomla and OpenID

Sunday, November 22nd, 2009

Yesterday morning I read an e-mail from the Pirate Party advising everyone that they were about to debut their new site using CiviCRM, and that those who were interested in helping ought to start brushing up.

CiviCRM can be based on Drupal, Joomla or OpenID. Not being sufficiently familiar with any of those, I took the opportunity to brush up on all three. While it should go without saying that after a day I’m far from an expert, I now know just enough to be dangerous. And write blog posts.

In my preliminary reading about Drupal vs Joomla, I heard that Drupal offered superior user controls, but that Joomla was better for people who aren’t especially technical. I fancy myself especially technical, but I also tend to work solo, so I didn’t anticipate benefiting from either software’s strengths.

I had limited Drupal use prior to today, and my initial impression was not favorable for entirely superficial reasons: ugly default theme, aesthetic distaste for their logo, and the feeling that it was bloated by trying to offer too many features. However, the install went smootly and quickly, as all installs should, and I was up and running in no time.

The Joomla download was several times larger than Drupal’s and its install was somewhat more problematic, leading to an overall bad first impression. It’s pretty common to find software with a file named something like config.default.php that you’re expected to rename config.php. Joomla’s default configuration file is called configuration.php-dist. Since I’m way too cool to RTFM, I created a copy named configuration.php and went about installing. I ran into problems on about the forth step, apparently because the install process expects configuration.php to be a blank file. I made the change and the installation proceeded smoothly.

While installing, Joomla offers to install sample data, so that way if you’re a n00b testing the waters, you don’t have to put in a bunch of fake data to get started. I was really pleased with this feature, but once I had complete the install I just found myself annoyed with the fact that all the sample data was advertisements for Joomla and set about removing it. I chalk that up to my own fickleness more than any wrong on Joomla’s part. I was unimpressed with how difficult it was to wade through all the options. I’d pick out a specific target that I wanted to change, and look through all three or four menu options labeled “[thing] manager”, but I wasn’t able to make heads or tails of them at a glance. Perhaps if I’d been more dedicated to reading documentation before I got started, my user experience would have been better.

Switching back to Drupal, I found the administration much simpler. Like Drupal, you can create a box to appear on the main page, and roughly where in the overall layout it ought to appear. From my brief perusal, it looked like all of these boxes were created with the same form, which basically offered you a text box into which you dump your HTML (and PHP?). As a coder I found this much more agreeable than having to traipse all around several different menu options and have to try and divine WTF the labels on the form inputs mean. However, if I were setting up a web site to be maintained by many members of an organization, this would be a liability, not an asset. While I had previously objected on the grounds that it felt heavy, next to Joomla it seemed positively sparse, which is how I like it.

Finally, I came to OpenID. I installed the WordPress plugin on this blog, but I ran into so many problems that I gave up. What I had envisioned was that I’d be able to comment on other OpenID-accepting forums using my URL here, and that others with OpenID users could comment here without sitting in the moderation queue. It seems that the login page now offers a OpenID option, so if a random surfer wants to comment on a post using their OpenID, they have to find their way to the login page, log in, then presumably navigate back to the post they wanted to comment on.

Even more frustrating, I couldn’t actually get it to work. The details are running together a little, but if memory serves, I tried to log in to this blog with my OpenID at this blog, and to my relief it failed. Unfortunately, it didn’t give me any error messages, so I don’t know if it failed because of user error or because allowing you to log into any site simply by typing the url of that site would be extremely stupid. I’m assuming the former. I sought out the author’s sandbox, and tried logging in there. If I recall, it went through all the usual confirm screens, then just hung on one that seemed like it should be redirecting me back to the sandbox. This may have failed because NoScript wasn’t letting it execute Javascript. I hit the back button a few times and found myself still not logged in. I tried again with my LiveJournal OpenID. It got to about the same page before NoScript stopped it under the concern that it was a Cross Site Scripting attack. While I believe that was probably part of normal operation, I don’t want to cultivate a habit of ignoring NoScript’s warnings, which I would have to if I used OpenID with an regularity. I tried it again with a browser that allows Javascript willy-nilly, but I was still unable to log in to either blog with either OpenID. I’d still like to get OpenID working, I think it’s a great idea whose time is overdue, but for tonight I’m throwing in the towel.

In the end, my decision was sort of a cop out: Because I suspect the Pirate Party will be installing their copy of CiviCRM over an existing Drupal install, I downloaded the Drupal-based version.

On today’s agenda: tinkering with CiviCRM.

Random Blogroll Category added to the WordPress plugin directory

Friday, November 20th, 2009

My plugin was accepted in the WordPress plugin directory. You can see its page here. I just rated it five stars because I’ve got a huge ego.

I also updated it to make it possible to show the entire blogroll, or to show multiple random categories in a single call to this plugin. I didn’t upload the first version to the directory because its usage was very different, and I didn’t want to cause confusion.

WordPress plugin: Random Blogroll Category

Monday, November 16th, 2009

During my recent trip to Portland I finished my first WordPress plugin, Random Blogroll Category. Because of my limited Internet connectivity, I wasn’t able to implement it here or submit it to the official WordPress plugin repository until today. WordPress reviews every plugin, so you can’t see it there yet, but you can see it in action here: check the right sidebar: there should be two headings under the search bar: Non-profit orgs and one other one and a random blogroll category. Refresh the page a couple times to see other categories.

In the next version, I hope to include the ability to show the whole blogroll, but because this plugin alters the behavior of the function that retrieves the blogroll, that’s not easily done. A workaround is explicitly listing each category as a separate call, but nobody likes workarounds.

The great irony is that I created this because I was annoyed by how much space the blogroll was hogging on the right sidebar, but now I’m annoyed by the amount of whitespace. I still think it’s better this way: it’s exciting to have the space to implement new ideas.

How to add rel=”nofollow” to just one link in your blogroll

Tuesday, October 20th, 2009

I link to a site that, while I appreciate its hilarity, I really don’t want to positively influence their Page Rank. Page Rank is the assessment that Google has made about the quality of a site; more non-spam links usually correlates to higher Page Rank. You can use a link’s rel attribute – created to describe relationships between documents – to tell search engines that you’re not endorsing a it.

In WordPress, there’s a handy field for setting the rel attribute of a link, except they’ve got some Javascript wizardry in place to prevent you from just typing “nofollow”. A little research revealed lots of plugins to alter all your links in some way, but I didn’t want that. I found a site that allegedly showed how to alter the WordPress code, but that site’s layout had such serious defects that I couldn’t make heads or tales of what it was trying to tell me.

Then I had an idea that was so smart it made me feel stupid: alter the database. Most web software, including WordPress, is essentially a fancy interface to get information into and out of a database1. Bypass the gatekeeper by going straight to MySQL’s command line.

First, find the id of the link you want with the following command:
select link_id, link_name, link_rel from links where link_name like '%Clearingho%'

I searched for links containing the term Clearingho; you should change it to the name of the link you’re looking for.

The first column is link_id, the bit of information you’re looking for. The second is the link name, which I included to confirm that I really am grabbing the right id. Third is the existing rel value; I wanted to make sure I wasn’t about to clobber any existing data.

The link_id in this case was 18 and the existing link_rel value was blank, so it’s a simple update:
update links set link_rel="nofollow" where link_id=18

If you wanted to retain the existing rel information, you could run the following query instead:
update links set link_rel=CONCAT(link_rel, " nofollow") where link_id=18

Refresh your blog and see the new rel=”nofollow” on your suspect link. Congratulate yourself and do a silly dance.

1 Just in case it’s not already obvious, I’d like to clarify that this is not in any way a slur against WordPress or any other database-driven2 software.
2 This buzzword is so 2003.3
3 Yo dawg, I heard you like footnotes, so we put a footnote on your footnote so you can foot while you note.

Fixing WordPress’ “Incoming Links” after server migration

Friday, October 2nd, 2009

I recently put this blog public, which means moving it from the address where I accessed it on localhost (127.0.0.1) on my dev box to it’s publicly visible address (kjcoop.com).

Most of the move was straightforward, but I noticed tonight that the “Incoming Links” box was still excitedly giving me the buzz about 127.0.0.1

The options table has a long string of what I believe to be Javascript in the option_value column for the row with option_name dashboard_widget_option. Rather than retype all 841 characters, MySQL’s good ol’ replace function will just update the relevant string:
update options set option_value=replace(option_value, '127.0.0.1/wordpress', 'kjcoop.org') where option_id=112;

I’m noting this here both in the interest of better remembering how useful the replace function is and for the sake of other WordPress users who may experience the same problem with the “Incoming Links” box.