Changing the WordPress table prefix

This may be of use to people experiencing the dreaded “You do not have sufficient permissions to access this page.” message when trying to reach WordPress’ admin page, even when logging in as a proper administrator. WordPress embeds the table prefix in 4 different locations:

  • The wp-config.php file
  • The name of the tables
  • The name of user metadata keys
  • The name of blog options

Thus if you want to change the prefix, you have to:

  1. Edit wp-config.php to change the prefix
  2. Rename your tables
  3. Rename your user metadata
  4. Rename your site options

Missing steps 1 or 2 will cause WordPress to not find the tables, and it will go through the initial install process again.

Missing step 3 will cause the account to lose its roles, and thus not be authorized to do much besides read public posts.

Missing step 4 is more insidious, as it destroys the option wp_user_roles, the link between roles and capabilities, and thus even if your account is an administrator, it is no longer authorized for anything.

It feels quite clunky to embed the database prefix in column values, not just tables, just like WordPress’ insistence on converting relative links to absolute links. The former makes moving tables around (e.g. when consolidating multiple blogs on a single MySQL database) harder than necessary. The latter makes moving a blog around in a site’s URL hierarchy break internal links. I suppose there are security reasons underlying Automattic’s design choice, but security by obscurity of the WordPress table prefix is hardly a foolproof measure.

If you are renaming the tables, say, from the default prefix wp_ to foo_, the MySQL commands necessary for steps 2–4 would be the following:

UPDATE wp_usermeta SET meta_key=REPLACE(meta_key, 'wp_', 'foo_')
WHERE meta_key LIKE 'wp_%';
UPDATE wp_options SET option_name=REPLACE(option_name, 'wp_', 'foo_')
WHERE option_name LIKE 'wp_%';
ALTER TABLE wp_commentmeta RENAME TO foo_commentmeta;
ALTER TABLE wp_comments RENAME TO foo_comments;
ALTER TABLE wp_links RENAME TO foo_links;
ALTER TABLE wp_options RENAME TO foo_options;
ALTER TABLE wp_postmeta RENAME TO foo_postmeta;
ALTER TABLE wp_posts RENAME TO foo_posts;
ALTER TABLE wp_redirection_groups RENAME TO foo_redirection_groups;
ALTER TABLE wp_redirection_items RENAME TO foo_redirection_items;
ALTER TABLE wp_redirection_logs RENAME TO foo_redirection_logs;
ALTER TABLE wp_redirection_modules RENAME TO foo_redirection_modules;
ALTER TABLE wp_term_relationships RENAME TO foo_term_relationships;
ALTER TABLE wp_term_taxonomy RENAME TO foo_term_taxonomy;
ALTER TABLE wp_terms RENAME TO foo_terms;
ALTER TABLE wp_usermeta RENAME TO foo_usermeta;
ALTER TABLE wp_users RENAME TO foo_users;

Strange X11 behavior in Snow Leopard 10.6.3

After updating OS X on my work iMac, I noticed XEmacs and DDD take about 30 seconds to launch, behavior I did not see before the upgrade, and do not see at home either. The 30 seconds are suspiciously similar to a name lookup timeout—I am dependent on whatever lame excuse for a DNS caching server is used in my landlord’s 2WIRE router, whereas I run unbound at home.

Sure enough, running a packet trace shows strange DNS lookups:

tellann:src root# tcpdump udp port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:18:51.819226 IP tellann.58811 > home.domain: 5470+ A? (43)
13:18:51.840258 IP home.domain > tellann.58811: 5470* 1/1/1 A (150)
13:18:51.841196 IP tellann.58057 > home.domain: 18746+ A? /tmp/launch-4UITkL/ (60)
13:18:51.870233 IP home.domain > tellann.58057: 18746 Refused*- 0/0/0 (512)
13:18:52.842654 IP tellann.58057 > home.domain: 18746+ A? /tmp/launch-4UITkL/ (60)
13:18:52.865696 IP home.domain > tellann.58057: 18746 Refused*- 0/0/0 (512)

The code>DISPLAY environment variable has changed to:

tellann ~>echo $DISPLAY

Before 10.6.3, it did not have the org.x bit. This whole approach of using a DISPLAY set to point to a UNIX domain socket was set up by Apple to allow launching on demand when a X client is run, but obviously many clients make the incorrect assumption that the part before the :0 display number is a hostname if it has a dot in it, and this is biting us.

The solution is simple: just set DISPLAY to :0 prior to launching XEmacs or DDD, and presto—no more delays, e.g:

env DISPLAY=:0 xemacs&

Put whiny computers to work

I have noticed a trend lately of computers making an annoying whining sound when they are running at low utilization. This happens with my Dual G5 PowerMac, the Dells I ordered 18 months ago for my staff (before we ditched Dell for HP due to the former’s refusal to sell desktops powered with AMD64 chips instead of the inferior Intel parts), and I am starting to notice it with my MacBook Pro when in a really quiet room.

These machines emit an incredibly annoying high-pitched whine when idling, one that disappears when you increase the CPU load (I usually run openssl speed on the Macs). Probably the fan falls in some oscillating pattern because no hysteresis was put into the speed control firmware. It looks like these machines were tested under full load, but not under light load, which just happens to be the most common situation for computers. The short-term work-around is to generate artificial load by running openssl in an infinite loop, or to use a distributed computing program like Folding@Home.

Load-testing is a good thing, but idle-testing is a good idea as well…