Posted in WordPress

BuddyPress links going to the wrong places?

I scratched my head a little while this morning trying to troubleshoot the behaviour of some of my BuddyPress admin bar links.

Clicking the “Activity” link redirected me to a page showing the entire membership’s BuddyPress activity (the link itself appeared to point to the right URL, yet when clicked it went elsewhere). Then the default profile page was going to the site’s Support page. My username on the site I was fiddling with is “support”, so obviously something was going on with WordPress trying to predict the URLs.

And thus began my education in WordPress’s canonical URL redirects.

This is functionality that can be useful if you’ve just slightly mistyped a URL, because it’ll get you there in the end anyway.

But somewhere in WordPress, the memo seems to have gotten missed that BuddyPress’s URLs are all internally-generated and not needing correction.

The fix: (added to the functions file or as a plugin)

function my_redirect_canonical($redirect_url, $requested_url) {
 // If on a BuddyPress page, just go to the requested URL: no redirects!
 if ( bp_is_members_component() || bp_is_user() ) {
   return $requested_url;
 } else {
   return $redirect_url;
 }
}
add_filter('redirect_canonical', 'my_redirect_canonical', 10, 2);

I’d love to know what’s causing this, and if something’s been set up improperly or incompletely. This problem didn’t always exist on this site, no caching plugins are installed on it, no redirects are listed in the htaccess file…. My little Wednesday mystery! But working now, anyway. 🙂

Posted in WordPress

Anti-spam plugin for WordPress

I was having a spam problem on a website I look after recently and thought I’d try an alternative to Akismet, since the latter now needs to be paid for on commercial websites. I installed Anti-spam, which uses a honeypot style trap to catch bots, and left on the core WordPress setting where problem comments are emailed to you, so as to keep an eye on things.

Well, the spam comments came in: all the usual rot, just now largely getting rejected (though notifications are sent to me by email) rather than marked as spam but still requiring me or my client to sort through them and delete them. I’m satisfied enough to switch the email option off and let it do its thing silently from here.

The honeypot technique won’t stop manual spammers (though there’s a paid version that claims to be able to ward off 70% of them) but it’s taken care of a good chunk of the problem. If it ramps up again, the paid version at $14 might be worth a stab.

Posted in WordPress

Definition of a WordPress hook

Hooks.

The term confused me for ages when I first started looking into WordPress plugin development. Anything I’ve learned about them I feel like I’ve done despite rather than because of the tutorials I consulted about them. Feeling like you’ve missed something can really undermine the learning process and chip away at the satisfaction you feel about doing things right.

So it’s nice to read an article whose author notes specifically that the term is often used incorrectly and confusingly to refer to two different things:

Just as in pop-music, the term “hook” is sometimes ambiguous—different people use the term to refer to different things. Technically, the term “hook” should refer to a WordPress event, such as get_header or the_content, but sometimes it is used generally to refer to the add_action() or add_filter() functions which reference the hook. Pay attention to the context, and it should be clear which meaning was intended. The most important thing to understand here is that you determine when your functions execute by attaching them to a WordPress event by using the add_action() or add_filter() functions. Remember: hooks are events.

From Anatomy of a WordPress Plugin, which incidentally is all quite well-explained.

Posted in WordPress

The WordPress mu-plugins folder

A side-effect of WordPress’s “multisite” mode – via which you can create a network of sites all running off the same WordPress installation – is the ability for developers to create a wp-content/mu-plugins directory and in it upload “must-use” functionality that’s “on by default”.

As per name of the directory, wp-content/mu-plugins provides a home for plugins; but unlike plugins you install via the WP admin, plugins placed in wp-content/mu-plugins are activated automatically.

And unlike code added to a theme’s functions file, functions added to a plugin installed in the mu-plugins folder remains available whatever theme is used — making mu-plugins a good spot to stick non-theme-related functionality which you want to remain present if the theme is changed.

More conventionally it’s used to stick plugins that aren’t to show up in the plugins page of the WordPress admin, thereby providing the site admin control over these that other site users don’t have.

The feature was created to enable autoloading plugins across multisite installations of WP: all sites running off a single installation of WP would automatically have this set of plugins installed.

But its availability on non-multisite installations, too, means you can take advantage of it on any WordPress site you build to house “must-use” functionality you want included.

Innerestin’ tidbit gleaned from Justin Tadlock, here. Read more about it in the WordPress Codex.

Posted in WordPress

Adding an admin user to WordPress via SQL

Cutting and pasting the following into the MySQL terminal will add a user called “support”, with the password “support”, and with admin privileges.

Log in with it and change the password (or replace it with something else before running the first query).

INSERT INTO `databasename`.`wp_users` (`ID`, `user_login`, `user_pass`, `user_nicename`, `user_email`, `user_url`, `user_registered`, `user_activation_key`, `user_status`, `display_name`) VALUES ('4444', 'support', MD5('support'), 'Support', 'your@email.com', 'http://your.homepage.com/', '2011-06-07 00:00:00', '', '0', 'Support');
INSERT INTO `databasename`.`wp_usermeta` (`umeta_id`, `user_id`, `meta_key`, `meta_value`) VALUES (NULL, '4444', 'wp_capabilities', 'a:1:{s:13:"administrator";s:1:"1";}');
INSERT INTO `databasename`.`wp_usermeta` (`umeta_id`, `user_id`, `meta_key`, `meta_value`) VALUES (NULL, '4444', 'wp_user_level', '10');