Luckily, there’s a sweet hook, registration_errors you can get into. It accepts 3 parameters: $errors, which is the WP_Error object; $login, which is the user_login entered during registration; and $email, which is the user_email entered during registration.

Here’s the code:

add_action('registration_errors', 'sizeable_restrict_domains', 10, 3);
function sizeable_restrict_domains( $errors, $login, $email ) {
	$whitelist = array('sizeableinteractive.com', 'theandystratton.com');
	if ( is_email($email) ) {
		$parts = explode('@', $email);
		$domain = $parts[count($parts)-1];
		if ( !in_array(strtolower($domain), $whitelist) ) {
			$errors->add('email_domain', __('ERROR: You may only register with an approved email address.'));
		}
	}
	return $errors;
}

Remember to specify some kind of priority AND how many parameters your callback function will accept when adding actions. I always forget to specify them when coding quickly from scratch and wonder why I’m getting weird values in my callback functions parameters.

Happy WP’ing.

• I work locally with a MAMP setup
• I create virtual hosts per project
• Each virtual host corresponds to a host name I add to my /etc/hosts file
• Sometimes I mirror this to a staging server/domain for the client to prime content before launch
• When launching, I take the staging database in a SQL export and import it into the production database and run a query to update the domains

Many times, the last item is a query like this (assuming default database prefix):

UPDATE wp_options
SET option_value = REPLACE(option_value, 'http://dev.mycoolwebsite.com', 'http://www.mycoolwebsite.com');

This typically did the trick. I rarely had issues, until one day, I migrated that had a widgetized sidebar from my local machine, let’s say the hostname was localhost and the production domain was www.mycoolsite.com.

Everything worked as planned, but I lost all my widgets.

¿Por Que, Widgets?

Here’s what I figured: WordPress uses a serialized PHP array to store widget settings in the database. This array also contains the site’s domain, an abbreviated example would be:

a:2:{s:3:"url";s:17:"http://localhost/";s:4:"meta";s:17:"some kind of meta";}

a:2 represents an array with 2 elements; s:3 says this is a string that’s 3 characters long and so forth. When I run my replace SQL, it changes http://localhost/ to http://www.mycoolsite.com/ but never updates the string’s length from s:17 to what it should be, which is s:26.

This simple inconsistency will invalidate that serialized array, returning false when it is unserialized — meaning no widgets or settings.

Any Solution?

Two solutions I use, short of some make-shiv helper script:

1. Use a development/staging hostname that’s the same length so you can do a global replace (e.g. dev.mycoolsite.com, stg.mycoolsite.com, etc.)
2. Run a more target query

Target Your Query, Hit the Widgets Page

Now, the following steps have worked for me and seem to be easier for me to be lazy with my organization up front. I recommend option 1 to be safe, but you can try this too:

UPDATE wp_options
SET option_value = REPLACE(option_value, 'http://localhost', 'http://www.mycoolwebsite.com')
WHERE option_value LIKE 'http://%';

This will restrict the query only to WordPress option records that <strong>start</strong> with the http:// protocol, thus ignoring serialized arrays. Once this runs, hit your widgets settings page and re-save things, and if you’re as lucky as me, everything is kosher.

Yet Another Option

This may actually be simpler. Go into your dev/staging/etc. site’s options and change the domain. You’ll get logged out. Go make your database dump and use that. You’ll probably need to do the previous steps to fix your dev/staging database though.

Hope this helps a few of you if you’re in a frustrated panic.

I want to issue a huge thank you to Michael Torbert, Steve Mortiboy and the Semper Fi Web Design team for making this happen, and making it happen well.

The Slides

You can download the PDF or view the presentation on SlideShare.

I think that the WordCamp Raleigh website will also be posting slides and video(s).

Thanks to all who attended, see you at the next WordCamp!

So, I wrote a quick plugin that I thought was a more elegant (and that did not affect expected, core WordPress behaviors).

Raw HTML Snippets

This plugin allows you to create a library of raw HTML snippets you need to embed within post/page content, then uses the native shortcode API to embed them without them being auto-formatted by wpautop or wptexturize.

It may not be as convenient as pasting directly into the HTML tab of the WYSIWYG editor, but it’s a solution that’s reusable, clean and does not interfere with the core functionality of WordPress or other possible plugins/shortcodes/content filters.

Raw HTML Snippets | Download

Give it a whirl, and let me know what you think!

Now, the easiest way to limit the reliance on the theme for the functionality I am building is to use shortcodes that output conditional content based on whether a user is logged in, based on user meta data, etc.

Shortcode Autoformatting Has Helped Doubled My Time

I have spent twice the amount of estimated time on this project, and at least 50% of that bloat has been this mysterious issue of my shortcode output being mysteriously auto-formatted with paragraph tags (<p>) and line-breaks (<br />).

I’ve spent days ripping out the tiny hairs on my head trying to figure out why I’m such a moron when it comes to WP’s shortcode API and core content filters (things I’ve been working with for YEARS).

I Do Something I Should Do More Often.

My e-friend Carl Hancock of Rocket Genius, the company behind the awesomeness of functionality and user-experience that is GravityForms, helped shed some light on this problem.

I figured he’d be the prefect person to reach out to, since the core of displaying a Gravity Form relies on WordPress’ Shortcode API.

As we are direct messaging on Twitter, I remember his comments about fixing MANY ThemeForest theme issues for clients using Gravity Forms due to terrible coding standards and overriding core functionality that affect both Gravity Forms and other plugins.

I hunt through some of the 100+ files embedded in this pre-built theme framework and fine this, well, poor code:

//Disable Automatic formatting in WordPress posts
function my_formatter($content) {
	$new_content = '';
	$pattern_full = '{(\[raw\].*?\[/raw\])}is';
	$pattern_contents = '{\[raw\](.*?)\[/raw\]}is';
	$pieces = preg_split($pattern_full, $content, -1, PREG_SPLIT_DELIM_CAPTURE);

	foreach ($pieces as $piece) {
		if (preg_match($pattern_contents, $piece, $matches)) {
			$new_content .= $matches[1];
		} else {
			$new_content .= wptexturize(wpautop($piece));
		}
	}
	return $new_content;
}

remove_filter('the_content', 'wpautop');
remove_filter('the_content', 'wptexturize');

add_filter('the_content', 'my_formatter', 99);

No sooner than I see this code, I get a DM from Carl with a link to a WP Recipe article with the exact same code.

I’m not sure WHO this code started with, but I know who used it.

Why is this a problem?

It’s globally removing two very important core content filters that WP has built-in for very good reasons. It is typically assumed by most themes and plugins that these filters are running. I don’t have a problem turning them off conditionally (i.e. specific post ID’s, specific page templates in a theme, etc.). Better yet, set this as a setting in a custom field, per page/post, and have it on by default. Give me the option to disable it and even know it exists if I’m walking into the theme from a distance.

This makes this theme work perfectly and negatively affects ANY and ALL plugins that have shortcodes or possibly filter content after the assumed priority of wpautop and wptexturize.

This is not a solution. It’s more of a hack that may or may not have cause the earthquake in Haiti, the tsunami in Japan and the tornados in the southern U.S…

How the hell do I fix this?

Don’t use a theme that poor code in it. That’s the optimal solution. Don’t expect a $36 purchase from a virtual Wal-mart to be stable, secure or provide you with a strong solution for communicating and interacting with your clients.

Okay, so realistically how do I fix this?

1. You can comment these lines of code out, including the remove_filter() calls, so that WP behaves as expected.
2. You can remove this filter in your shortcodes, which is what I did since my client is going to continue to use this theme:

   add_shortcode('andy_shortcode', 'andy_shortcode');
   function andy_shortcode( $atts, $content = '' ) {
   	remove_filter('the_content', 'my_formatter', 99);
   	extract(shortcode_atts(array(), $atts));
   	$output = '<div class="my_formatter_violated_my_output">';
   	$output .= 'Thanks for using the my theme framework.</div>';
   	return $output;
   }

   Remeber you MUST enter their priority value of 99 (or whatever it is set to in your theme, chances are you’re using a theme from the same authors, or authors of the same mentality).

3. You can stop using shortcodes or pray that it doesn’t affect you.

Final Thoughts

I understand what the intention of this functionality is. In fact, I think it’s a good idea, just a poor implementation.

Ultimately, I’d move away from these themes and check out some stronger theme directories with dedicate WP experts coding, not a hodge-podge marketplace. Being that I’m kind of against purchasing pre-built themes from both a designer and developer standpoint, I can’t recommend a good site, but I’m sure I can keep recommending sites NOT to use.

Good luck and God Speed.

I Can’t See My Custom Fields

I used custom fields a lot. Sometimes I create custom meta boxes for them, sometimes I have clients use the custom fields meta box directly. When we upgraded one of my client’s sites, my original administrator account still saw everything but the other accounts only saw the Publish, Page Attributes and title/editor panes in the Add/Edit Page screen.

Not cool. I was freaked. Then I realized (thanks to a support post at WordPress.org) that there are screen options there. They could’ve been there before and I just never paid attention, but now I know:

Hopefully that helps you out.

Killing the WordPress 3.1 Update Admin Bar

Don’t get me wrong. I get it. I like it. But I have some installs where we are leveraging WP accounts but don’t want to advertise to the user that we’re on WP. I’ve used it for some very interesting applications and customized some installs heavily (not core, of course) and some clients just freaked about it.

My preferred method, thanks to Joost de Valk, is to just to turn it off completely:

add_filter('show_admin_bar', '__return_false');

Remember, if you just want to hide it for yourself you can edit your user profile in the admin screens. Check out Joost’s article for more options. Happy double-you-peeing.

We thought this was a weird environment issue at first, but then I found this post that showed me it’s a common issue that’s been reported to their development team.

I continued searching for a solution and got some direction from a solution by @foralien on the BuddyPress forums. Her solution did not work for, but I created my own version and had success.

What was happening?

Our BuddyPress installation was trying to get avatars from /blogs.dir/1/files/avatars/{$user_id}/{$filename} – which did not eve exist, this was referencing a files directory for the root blog and it didn’t even exist.

As per @foralien’s solution, I created 2 filters (one for the avatar path, the other for the avatar public URL):

Download the Code

// Custom filters to clean up issues in WP 3.0 with avatar paths.
// Written by @theandystratton
function sizeable_bp_core_avatar_folder_dir( $path ) {
	$items = explode('/', $path);
	$path = ABSPATH . 'wp-content/uploads/avatars/' . end($items);
	return $path;
}
add_filter('bp_core_avatar_folder_dir', 'sizeable_bp_core_avatar_folder_dir');
function sizeable_bp_core_avatar_folder_url( $url ) {
	$items = explode('/', $url);
	$url = 'http://' . $items[2] . '/wp-content/uploads/avatars/' . end($items);
	return $url;
}
add_filter('bp_core_avatar_folder_url', 'sizeable_bp_core_avatar_folder_url');

What it’s doing

We’re filtering the path and the url for avatars to ensure it’s using the WP 3.0 location, which is the upload_path for the root site followed by /avatars/{$user_id}. This is not a forever fix. I’d use it as duct tape until they release a BuddyPress update for WP 3.0 fixing the issue.

Hope this helps you guys and saves you some time and frustration.

So I’ve had some reports that the shared hosting hack fix that I wrote as a quick bridge to a real solution left some people with PHP documents that contained a bit of leading whitespace, which can really b0rk up your WordPress install or any PHP application if it’s in the right file the wrong way.

So, I give you the cleaner (special thanks to Michael Safovich for requesting and testing).

What’s it do

It recursively looks through it’s current directory (and subdirectories) for PHP files (by default it’s looking for php, php4, php5 and phtml extensions, but this is customizable) and killing any whitespace in the beginning of the file, turning:

   
   
   
<?php include_once './wp-blog-header.php'; ?>

into this:

<?php include_once './wp-blog-header.php'; ?>

Make sense? Good, here’s the download link.

Tips & Customization

BACK UP YOUR FILES. You agree to take responsibility for running this, because I sure don’t (though I think you’ll be fine).

To run on custom file types, edit the $fileTypes array to include the types you want to strip leading whitespace from.

The script will run for the current directory. You will need to set the $directory variable to contain the path you’d like to recursively clean, in most cases you’d drop the cleaner.php file in your document root and hit it in the browser.

It will run immediately and output a log. Hope it helps. ¡Hasta luego!

*UPDATE* Reports of leading whitespace being left in the files after the fix script has been ran led me to build the cleaner, a script to, well clean up that leading whitespace.

I have also updated the download of the fix on this page to strip leading white space.

So GoDaddy wasn’t the only host attacked by this malware PHP hack. I’ve found traces on client’s BlueHost shared Linux hosting as well. Apparently some other hosts, including Network Solutions.

One host I use (along with multiple clients) who I haven’t seen or heard about being affected is HostGator. My dedicated box(es) have not been affected either.

This is NOT an issue exclusive to WordPress installs. Tons of WordPress installations have been affected but WordPress is currently the most-installed PHP/MySQL web application on the web today, especially in these shared Linux hosting environments. I’ve seen this same attack affect sites with basic PHP files using only include statements as well as other PHP/MySQL applications such as Joomla (*shudder*).

What the attack seems to be doing

• Adding a line of base64 encrypted PHP to be evaluated before most PHP scripts run
• Common strings in hacked files include:
  • <?php eval(base64_decode(
  • <?php eval(gzinflate(base64_decode(
• Some of this code is injecting content into your page’s output for search engines, some redirecting users
• I’ve found some sites commonly have the file ./wp-includes/js/tinymce/plugins/inlinepopups/skins/clearlooks2/img/style.css.php which is a lot of eval() wrapped base64 encoded strings (it’s been recursively encrypted and after 15 iterations I needed to get back to client work)
• I also found some files without extensions in the ./wp-includes/js/tinymce/plugins/inlinepopups/skins/clearlooks2/img/ directory (t (looks to be a template), lb (links, link back perhaps?) and kwd (keywords) — there was also a file named cnf which looked to be encrypted configuration for the hack as well as another file called csi which contained an IP and Unix timestamp.

Updated Fix for the Hosting Hack

Please note: this is not an all comprehensive fix. This can help clear out some code very quickly but you should still take some drastic efforts (see below) to clean up your site and protect yourself.

Download Shared Hosting Attack Fix »

Instructions:

1. Make time this week to figure out and implement a plan for backing up your site and database, either via your hosting provider, your own shell scripts, or VaultPress.com is looking very good right now if you’re on WordPress.
2. Back up your site files. Even if they are hacked, get a copy of everything locally just in case.
3. Download shared-hosting-fix.php.txt and rename it shared-hosting-fix.php
4. Place the file somewhere in your document root and visit it in a browser to review what files are infected. If you’re not seeing affected files here, make sure the contents of the $hack_str variable on line 30 is the same as the beginning of the hack’s code. Some have been different by a space here and there, which will affect this clean up script.
5. If you have infected files, you can press the “Fix Files” button at the bottom of the page to start the automated task of removing the first line of malicious code
6. Confirm that you want to make the changes on the popups and you will see a simple log display when all is said and done
7. Back up your clean(er) files and take more steps to audit your files and database to try to avoid recurrence

Do More to Clean Up and Protect Yourself (WordPress)

Just a few notes about other things you can (and should) do:

• Make regular backups — Lazy? Checkout VaultPress
• Clear any and all cache files on your server. I’d literally de-activate the caching plugins, remove them and their associated directories and then download and re-install them
• Back up your wp-config.php file and wp-content directory then completely remove all of your WordPress files and directories, then re-upload from a fresh and up-to-date WordPress install. Audit your wp-content directories and wp-config.php file before re-uploading.
• Use some WP Security plugins:
  • WP Security Scan
  • WordPress File Monitor
  • WordPress Exploit Scanner
• Check your database, specifically the wp_options table for suspicious code (see Chris Pearson’s post below, How to Diagnose and Remove the WordPress Pharma Hack

WordPress Security Reference Links

Thanks to some friends at Automattic and in the WordPress community, here are some links for your reference:

• WordPress Security Presentation
  A great WP security presentation by Brad Williams of WebDevStudios
• Securing wp-admin
• Securing wp-config.php
• Moving wp-content
• Installing WP with Clean SVN Repositories
• If you’re a busy, well-to-do, business person who just doesn’t have the time, you could contact and hire a outstanding WordPress and PHP developer and occasional blogger… </shamless_self_promotion>

Some Reference Posts For Reading:

• CONTINUING STORY – Dangerous Malware Alert – Self-Hosted Sites Hack Update – Go Daddy Responds! | WPSecurityLock
• Simple cleanup solution for the latest WordPress hack
• http://smackdown.blogsblogsblogs.com/2010/05/13/hosting-with-godaddy-might-want-to-rethink-that-decision/
• How to Diagnose and Remove the WordPress Pharma Hack
• How to cure your GoDaddy WordPress hacked blog

This can prove to be a pain during the development or migration process. It can also make it annoying if you happen to change your permalink structure and have tons of posts.

Introducing dynamically inserted WordPress permalinks with The Permalinker

The Permalinker will allow you to use WordPress short codes to dynamically insert permalinks and permalink URLs into your posts via the content editor.

How it works:

When editing content, simply use the the short code to insert a link:

[permalink]This is a link to the current post

Linking to a different post:

You can set the id attribute in the short code to point to a specific page/post:

A link to post 23

Supported anchor attributes:

Currently, the following attributes are supported in the short code and will be added to the resulting anchor element: class, rel, and target.

[permalink id=23 class="my_class" rel="self" target="_blank"]Open post 23 in a new window

Want more control over your markup?

Using a non-terminating or empty http://theandystratton.com/2009/the-permalinker-wordpress-plugin-dynamic-permalinks short code will simply output the permalink URL:

<a href="http://theandystratton.com/2009/9-revision-3" class="thickbox" id="link_23">Another link to page/post 23</a>

There’s more: Dynamically grab your template directory

As a request from fellow WordPress designers and developers, I’ve included a http://theandystratton.com/wp-content/themes/theandystratton short code as well, allowing you to quickly and dynamically get the full URL to your active template directory from the content editor:

<img src="http://theandystratton.com/wp-content/themes/theandystratton/photos/yoda.gif" alt="A picture of Yoda!" />

Download Permalinker

You can learn more and download The Permalinker from the WordPress plugin repository.

Happy coding ;]