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.

Often, I will find an old project (or inherit, or destroy) a project with subversion directories and files in it. However I get there, every few months I find myself wanting to remove subversion folders recursively and am not well-versed in shell scripting to remember how to do it.

Here’s the single line magic removal of .svn directories:

rm -rf `find . -type d -name .svn`

And here’s the script I wrote and placed in my home directory, ~/recursively-kill-svn.sh:

while true; do
	read -p "Do you want to recursively delete all .svn folders/files in the current directory (`pwd`)? (y/n)" yn
	case $yn in

		[Yy]* ) rm -rf `find . -type d -name .svn`; echo ".svn directories in `pwd` have been recursively killed!!1"; break;;

		[Nn]* ) echo "I've done absolutely nothing."; exit;;
		* ) exit;
	esac
done

With this in my home directory, I just move to a project folder, type:

~/recursively-kill-svn.sh

…and hit enter. Enjoy.

P.S. If it’s not working for you (or auto-completing when you hit tab in Terminal) make sure it has permissions to execute:

chmod +x ~/recursively-kill-svn.sh

P.P.S. You can rename the file to whatever you like.

I give you Sizeable Spaces, an 1800 square foot dedicated coworking facility in the Federal Hill district of Baltimore, MD. The space includes:

• 24/7 keyless entry
• Conference room with presentation capabilities
• 50/10Mbps business class Internet connection (wired and wifi)
• Microwave, coffee machine, water cooler and refrigerator
• 11 dedicated desks for working and a vacant private office for additional space or private phone calls
• Free residential parking
• Color laser printer (networked)
• Two outside decks…and as much more as we can add…

Check us out when you have a chance, take a tour, or even come work a free day and see how you like it. We’re having an open house on Tuesday, July 26th if you’re interested in checking it out, having some food/drinks and meeting other people like us.

I’m extremely excited to see how the community in our space grows, it’s organically grown from 4-7 members in a week. The power of community and doing.

It’s effectively missing a very simple, but critical JSON property in the root level object, named rpp (results per page, perhaps?).

Example:

<script src="http://widgets.twimg.com/j/2/widget.js"></script>
<script>
new TWTR.Widget({
  version: 2,
  type: 'search',
  search: 'rainbow',
  interval: 6000,
  rpp: 5,
  title: 'It\'s a double rainbow',
  subject: 'Across the sky',
  width: 250,
  height: 300,
  theme: {
    shell: {
      background: '#8ec1da',
      color: '#ffffff'
    },
    tweets: {
      background: '#ffffff',
      color: '#444444',
      links: '#1985b5'
    }
  },
  features: {
    scrollbar: false,
    loop: true,
    live: true,
    hashtags: true,
    timestamp: true,
    avatars: true,
    toptweets: true,
    behavior: 'default'
  }
}).render().start();
</script>

That’s it. Just add that rpp property and set it to the number you want to limit by and boom!

• 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.