Press Coders is now offering full service, all inclusive WordPress hosting to our theme customers.

We’ve been referring our customers to outside hosts for a while now, but we find that we answer a lot of questions about how to set everything up. Sometimes it will be weeks from the time someone buys their hosting until they actually get their site online.

If you setup hosting yourself, you have to find a hosting company you trust, purchase a plan, register a domain, connect the domain and hosting, install WordPress, install your theme, then build your site. That’s assuming you already know how to do that stuff and you don’t need help.

What a pain!

In the time it takes to go back and forth with someone helping them setup their hosting account, we could have set it up for them and saved everyone some trouble.

That stuff is easy for us, so we figured, why not just let us do all the work?

After all, we know our themes better than anyone, who better to set your site up for you?

This service isn’t for everyone, and that’s ok. This is only for our theme customers who don’t have the time or desire to mess with setting up and maintaining all the technical stuff.

To sweeten the deal, we will throw in a free theme!

Click here, everything you need to know is on this page.

We are excited to announce the release of our latest theme, FitX. It is our second fitness theme after the success of our very popular FitPro theme.

FitX is a vibrant new theme with lots of great features, you can see a demo of it here.

Some people asked what is the difference between FitPro and FitX? Well, FitX has everything FitPro has, and more. It is built a little differently, more modern features like HTML5, a new rotating testimonial feature, easily change fonts, a custom sidebar feature, and cool custom graphics.

Plus, we have a great new quick start feature included in FitX which is perfect for new sites. Upon theme activation you have the option to setup some default content including new pages (About Us, Contact Us, Blog, Sitemap), and a navigation menu etc.

Click here to check out the full FitX details!

We have just released the latest version of our fitness WordPress theme, FitPro. The new version (2.3) includes many improvements and bug fixes under the hood, but also some significant updates to existing features.

Thanks to our members who gave us feedback, many of the things you requested are in this release!

Members Page User Content

This feature (FitPro Platinum) has been requested several times and so we decided to add it for more flexibility. When a user logs in they can now edit their profile and add content to their OWN members page. This can be used to allow users to keep a journal entry of their training progress etc.

Administrators can add comments in a separate box (this edit box is not visible to the user) as before and also edit/annotate user comments directly.

E-mail Opt-in Widget

The opt-in widget (FitPro Platinum) has been significantly updated to include support for 3rd party scripts (Aweber, MailChimp etc.). If you don’t want to use a 3rd party script then you can make use of the new auto-responder.

To use the auto-responder just enter details directly in the widget settings and when a user submits the opt-in form an e-mail gets automatically sent to them. You do not need to do this manually any more!

Info Box Widget

Updated to include more icons, plus a spare one to display any icon image and link. The full list of icons now available are: Facebook, Twitter, YouTube, Flickr, Google+, Linked In, RSS, plus a custom one.

Be sure to check out the new video tutorial on the FitPro Setup page that explains how to use the new opt-in and info box widgets.

Content Templates

Now automatically adds content to post/page editor! No more copy paste (FitPro Platinum). The UI has also been revamped and made more compact too.

New Theme Options Links

We have added a couple of buttons on the theme options page to link directly to tutorial videos and the FitPro forum.

Theme Editor CSS

When editing your posts and pages you will now notice that they don’t look too dissimilar to how they display on the front end. This is because we have added a style sheet to the post editor to match the styles on the front end.

This should stop you from having to keep flipping back and forth between the post editor and the front end to see what your changes look like!

Other Updates

We have also added many bug fixes and code modifications to FitPro 2.3, and it works seamlessly with the latest version of WordPress. The file size of the theme zip file has also been significantly reduced so it uploads even quicker when updating your theme!

What’s going on with the Press Coders lately? Here’s an update…

WordPressthemes.com

David and I are excited to announce that our themes our now included on wordpressthemes.com, a directory for WordPress templates.

Community Forum

Did you know we have a community forum where you can help and get help with WordPress? Come say hi.

Curo Theme

In case you missed it, our third theme Curo was released. It’s a theme for medical and health professionals, check it out.

Our Next Theme

Our next theme will be a portfolio theme, and it’s looking pretty sweet if I do say so myself.

It will feature some awesome new functionality, but I don’t want to give away too much yet. Look for it in early 2012.

Blog

There’s some great stuff in the blog, including how to reuse the post editor in WordPress 3.3. Release candidate 1 was just released, so read up now.

We get a lot of questions about switching hosting, pointing domains to a new server, etc., so we made a video to make things clearer.

We are excited to announce that from here on out we will be donating a portion of every sale to charity: water.

They are a fantastic organization that brings clean water to impoverished villages in Africa. 100% of public donations directly fund water projects.

You are welcome to donate to our campaign, or just feel good knowing that when buying a Press Coders theme you are also contributing to a good cause.

The reason we chose charity: water is because almost 1 billion people don’t have clean water.

It is the essential building block for progress: without it you can’t have better education, better jobs, less hunger, or real development of any kind.

Check out this video, or check out our campaign page to donate.

With every release of WordPress there are so many cool new features to play with. This usually a good thing but one downside is that if you want to incorporate them straightaway into your Plugin it can break versions of WordPress that haven’t upgraded yet.

I had exactly this issue when adding some new code to my Plugin Options Starter Kit Plugin.

I added two new text areas to the Plugin options form that use the built-in WordPress editor. This is made possible by the fantastic wp_editor() function, which is only available in WordPress 3.3 (see my post on this function here). However, a lot of users who are already running this Plugin may not have upgraded to WordPress 3.3 (when it is released) by the time I post the Plugin update on WordPress.org.

So where does this leave you? How can you safeguard against Plugin incompatibility with a users version of WordPress. You could insert a simple die() function, but we can do better than that!

Check out the code below that generates the above message, safely deactivates the incompatible Plugin, and provides a convenient link back to the WordPress admin.

1
2
3
4
5
6
7
8
9
10
11
12
13

function requires_wordpress_version() {
	global $wp_version;
	$plugin = plugin_basename( __FILE__ );
	$plugin_data = get_plugin_data( __FILE__, false );
 
	if ( version_compare($wp_version, "3.3", "<" ) ) {
		if( is_plugin_active($plugin) ) {
			deactivate_plugins( $plugin );
			wp_die( "'".$plugin_data['Name']."' requires WordPress 3.3 or higher! Deactivating Plugin.<br /><br />Back to <a href='".admin_url()."'>WordPress admin</a>." );
		}
	}
}
add_action( 'admin_init', 'requires_wordpress_version' );

So, what’s going on here?

First, we grab the current version of WordPress stored in the global $wp_version variable. Next, we have two lines of code to store the plugin folder/filename, and the name of the Plugin itself.

Now for the important bit. We use version_compare() to check we are running WordPress 3.3 or higher. If you want to check for a different version just change ’3.3′ to a different value. If your installed version of WordPress is not compatible with the Plugin then we can go ahead and deactivate the Plugin, output a message, and halt the script.

Let’s check our Plugin is actually activated before we try to deactivate anything. We do this with the is_plugin_active() function. We need to pass in the Plugin folder and filename, which we stored in $plugin earlier. A value of true will be passed back if the Plugin is active.

Once we have confirmation that we can go ahead and deactivate our Plugin we just need to call the deactivate_plugins() function and pass it $plugin. This will actually deactivate the Plugin. The final step is to just call wp_die() with a suitable message. I have also added a link back to the WordPress admin for convenience.

You may be wondering why I am adding the code to a function and triggering it via the ‘admin_init’ action hook. Why not just add it outside of a function at the top of the Plugin file?

This is because of the is_plugin_active() function. If you try to call it outside of a function somewhere in your Plugin file, then it won’t have been defined by WordPress yet and a fatal ‘Call to undefined function’ error will be generated. This will also happen if you try to hook the function too early. Try replacing the ‘admin_init’ hook with ‘plugins_loaded’ instead to see what I mean. As long as you hook the function with ‘admin_init’ though everything should be fine.

The function is generic enough to be dropped into any existing Plugin and work right out of the box (neat huh?). The only thing you might need to adjust is the version of WordPress you want to test against.

I hope you find this code snippet useful. As usual let me know what you think in the comments.

If you have been following along with the development of WordPress 3.3 beta you may already be aware of the great new function wp_editor(). It really is a game changer. The WordPress core team deserve a real pat on the back for this one. So what’s all the fuss about?

The problem before WP 3.3 was that if you wanted to reuse the built-in editor, used on posts and pages, you had a real battle on your hands to get it to work. It was just too much hassle for the benefits gained.

In fact, the last time I looked into this I gave up and included the CKEditor JS library instead, as that was really easy to implement. This worked pretty well but not really ideal as the CKEditor library is quite weighty to include with your theme/Plugin.

What I REALLY wanted was be able to use the built-in editor that shipped with WordPress. And now I can! The new wp_editor() function has made the hideously difficult task of re-using the editor ridiculously easy. It’s just so easy now to throw editors at every text area in the WP admin you can shake a stick at, and it will work reliably and consistently every time. How cool is that?

In this post I’ll be creating a simple Plugin and show you how to add two separate instances of the WP editor on the Plugin options page. You will be able to grab the code for the whole Plugin at the end of the post.

But first, please bear with me whilst I go through the motions of setting up the Plugin structure. Don’t worry we’ll get to the good stuff soon enough. With this in mind I’m not going to go through every fine detail of the functions needed to set-up a Plugin. I just want to focus on the reusability of the WP editor.

First, let’s register our settings, as we will be using the WordPress Settings API to handle our Plugin options. The code for this is pretty straightforward.

1
2
3
4
5

// Init plugin options to white list our options
function wpet_init(){
	register_setting( 'wpet_plugin_options', 'wpet_options', 'wpet_validate_options' );
}
add_action('admin_init', 'wpet_init' );

Now we need an admin page for our Plugin. Again, this is standard stuff.

1
2
3
4
5

// Add menu page
function wpet_add_options_page() {
	add_options_page('WP Editor Test', 'WP Editor Test', 'manage_options', __FILE__, 'wpet_render_form');
}
add_action('admin_menu', 'wpet_add_options_page');

This will add a Plugin options page under the Settings top level menu with the title ‘WP Editor Test’. Now for the good part.
We need a function to render the form, but let’s break this down a bit. To start with, the Plugin options form uses the post method, with option.php used for the action attribute. Inside the form tags, and before any form fields are rendered let’s add two lines of code to handle all the Settings API details for us.

1
2

settings_fields('wpet_plugin_options');
$options = get_option('wpet_options');

Now we can render all our form fields safe in the knowledge that the Settings API is looking after us and giving us all the correct values and settings. We just need one Plugin option for now, a simple text area.

1

<textarea id="wpet_options[textarea_three]" name="wpet_options[textarea_three]" rows="7" cols="150" type='textarea'><?php echo $options['textarea_three']; ?></textarea>

All we need to do now is add a form submit button so all the loading/saving of the text area content will be handled for us! Sweet.

1
2
3
4
5
6
7
8
9

<p class="submit"><input type="submit" class="button-primary" value="<?php _e('Save Changes') ?>" /></p>
</p>
 
OK, so this is all fine and good for bog standard text areas but what about using the funky WP editor as a replacement? This is way easier than you might think. You’re gonna love this.
Simply replace the text area tag above with:
 
<pre lang="php" line="1">
$args = array("textarea_name" => "wpet_options[textarea_one]");
wp_editor( $options['textarea_one'], "wpet_options[textarea_one]", $args );

Basically, all you need to do is call the wp_editor() function and pass it an ID and some optional arguments. The first parameter is the actual content of the text area which we are pulling from the options db table, via the Settings API. Next we add in the ID of the text area as the second parameter. Finally, the third parameter accepts an array of settings you can use to customise the editor.

In this example we are just specifying one array parameter in $args which sets the name of the text area too. These are both the same in this case so we could have actually left this out altogether, as ‘textarea_name’ defaults to the ID name. I explicitly left it in as it’s a good idea to see what’s happening, on a first exposure.

Note: There is currently no WordPress Codex page for wp_editor() at the time of writing (November, 2011) so you will have to dig around the WordPress core to find out more about the parameters available.

Right, want more editors? You got it. We can easily add another instance of the WP editor. Check this out:

1
2

$args = array("textarea_name" => "wpet_options[textarea_two]");
wp_editor( $options['textarea_two'], "wpet_options[textarea_two]", $args );

Just make sure that you change the ID and name parameters to point to a new text area and bingo, we have two separate instances of our editor. That’s almost too easy!

You might have noticed that when we defined the register_setting() function the third parameter was specified as the ‘wpet_validate_options’ callback function. This is a validation function that you can pass your text area content through as it is saved. The callback is defined in the Plugin as:

1
2
3
4
5
6

function wpet_validate_options($input) {
	// Sanitize textarea input (strip html tags, and escape characters)
	//$input['textarea_one'] = wp_filter_nohtml_kses($input['textarea_one']);
	//$input['textarea_two'] = wp_filter_nohtml_kses($input['textarea_two']);
	return $input;
}

I have commented out the lines to validate and strip HTML tags as I want to keep the formatting. This validation function is really useful when you DO want to remove tags from text areas.

The full Plugin code is shown below. Copy it into a text file, save it as wp-editor-test.php, and add to your ‘/wp-content/plugins/’ folder. Just activate it, and visit the Plugin options page under the Settings menu.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

<?php
/*
Plugin Name: WP Editor Test
Plugin URI: http://www.presscoders.com/
Description: Test Plugin to get the WP editor working on a Plugin admin page.
Version: 0.1
Author: David Gwyer
Author URI: http://www.presscoders.com
*/
 
// Init plugin options to white list our options
function wpet_init(){
	register_setting( 'wpet_plugin_options', 'wpet_options', 'wpet_validate_options' );
}
add_action('admin_init', 'wpet_init' );
 
// Add menu page
function wpet_add_options_page() {
	add_options_page('WP Editor Test', 'WP Editor Test', 'manage_options', __FILE__, 'wpet_render_form');
}
add_action('admin_menu', 'wpet_add_options_page');
 
// Render the Plugin options form
function wpet_render_form() {
	?>
	<div class="wrap">
		<div class="icon32" id="icon-options-general"><br></div>
		<h2>WP Editor Test</h2>
		<form method="post" action="options.php">
			<?php settings_fields('wpet_plugin_options'); ?>
			<?php $options = get_option('wpet_options'); ?>
 
			<table class="form-table">
				<tr>
					<td>
						<h3>TinyMCE - Editor 1</h3>
						<?php
							$args = array("textarea_name" => "wpet_options[textarea_one]");
							wp_editor( $options['textarea_one'], "wpet_options[textarea_one]", $args );
						?>
					</td>
				</tr>
				<tr>
					<td>
						<h3>TinyMCE - Editor 2</h3>
						<?php
							$args = array("textarea_name" => "wpet_options[textarea_two]");
							wp_editor( $options['textarea_two'], "wpet_options[textarea_two]", $args );
						?>
					</td>
				</tr>
				<tr>
					<td>
						<h3>Textarea - Editor 3</h3>
						<textarea id="wpet_options[textarea_three]" name="wpet_options[textarea_three]" rows="7" cols="150" type='textarea'><?php echo $options['textarea_three']; ?></textarea>
					</td>
				</tr>
			</table>
			<p class="submit">
			<input type="submit" class="button-primary" value="<?php _e('Save Changes') ?>" />
			</p>
		</form>
	</div>
	<?php	
}
 
// Sanitize and validate input. Accepts an array, return a sanitized array.
function wpet_validate_options($input) {
	// Sanitize textarea input (strip html tags, and escape characters)
	//$input['textarea_one'] = wp_filter_nohtml_kses($input['textarea_one']);
	//$input['textarea_two'] = wp_filter_nohtml_kses($input['textarea_two']);
	//$input['textarea_three'] = wp_filter_nohtml_kses($input['textarea_three']);
	return $input;
}

Note: The code in this post applies to WordPress 3.3 beta 2 which may see some tweaks to the way wp_editor() works before final release. So if you implement any code from this post in your own Plugins then make sure it still works in WP 3.3 final.

Ever wondered how website domains and hosting work? Do you need to change your DNS? Do you have your domain in one place and your hosting in another?

This video explains how it all works.

If you have ever uploaded many images/videos etc. via the WordPress media uploader you will now that it can be pretty tedious to have to manually edit the title for new media items.

‘Format Media Titles’ is a new Plugin to automatically format the media title for new uploads. It works by replacing characters such as hyphens, and underscores, with spaces. The title can then be capitalized by a method of your choice.

See the image below for a before and after view of the same image uploaded with and without the Plugin activated.

Here at Press Coders we are never happy with making do with the same old functionality. We constantly re-evaluate the way we do things and always look to improve on user experience. So, what have we been up to?

Well, one thing that bugs us is that when activating a theme for the first time your site can typically look less than amazing. That is until you create some content and complete some initial configuration including:

• Posts
• Pages (About Us, Contact Us, Sitemap etc.)
• Navigation Menu (and setting the Theme Location)
• Widgets and adding them to widget areas

Wouldn’t it be cool to be able to (optionally) install this content automatically when activating a theme on a new site?

Yes, we thought so too, and that’s why we added it to our theme framework!

The actual code of creating the default content will be left to another post. In this post we want to focus on what happens on the theme activation side, and demonstrate how our framework makes it a snap to change this behavior when activating the theme.

Let’s see what a bog standard theme activation looks like.

OK, so here we have added an extra admin notice to show we have activated a theme, and even thrown in a link to the theme options page for good measure. But it still isn’t great.

For one thing, the default activation message feels a little outdated. I mean, what theme doesn’t support widgets these days? So let’s start by removing this default activation message. We are safe to do this because we know that all our current and future themes will ALWAYS support widgets.

How do we do this exactly? Well, we need to make sure our code runs when a theme is activated. There is no built-in WordPress hook for this (seriously) but we can use the following to achieve the same thing.

1
2
3
4
5

global $pagenow;
if ( is_admin() && isset($_GET['activated']) && $pagenow == "themes.php" ) {
	 /* Show theme activation message, and setup them option defaults. */
	add_action( 'admin_notices', array( &$this, 'theme_activated' ) );
}

We can add code to the ‘theme_activated’ callback function that will be executed every time a theme is activated. You may have noticed that this callback is referenced via class method syntax. This is because we are using classes rather than standard functions, thus the callback references need to be modified slightly.

Inside our callback function we have a line of jQuery code to remove the standard WordPress theme activation notice.

1
2
3
4
5
6
7

?>
<script type="text/javascript">
	jQuery(document).ready(function($) {
		$('#message2').css('display', 'none');
	});
</script>
<?php

Now that is gone we can add our own message when the theme is activated.

This is getting a little better now. We have a more relevant message with some buttons to go to the site home page, or theme options page.

But what about the default content mentioned earlier? Well, in the functions.php file we have two constants (INSTALL_DEFAULT_CONTENT, and INSTALL_CONTENT_PROMPT) that we can alter to change the activation message/behavior.

When INSTALL_DEFAULT_CONTENT is set to FALSE (the default setting) the above theme activation message is shown. But when it is set to TRUE we see a new activation message.

You can decide whether to install the default content or just go straight to the theme options page (or any other page you want to). To prevent accidental installation of default content the is an alert box that pops up to make sure you want to go ahead.

And if you do choose to install the default content, you get a confirmation message after completion.

The second constant, INSTALL_CONTENT_PROMPT, is only relevant if INSTALL_DEFAULT_CONTENT is set to TRUE. It is used to decide whether the default content to be installed should be installed automatically or prompt the user first.

We have already seen the effect of having INSTALL_CONTENT_PROMPT set to TRUE above where the default content is ONLY installed if the user specifies. If set to FALSE then the default content is installed silently in the background.

In this case the activation message is the same as before (see screenshot below) when INSTALL_DEFAULT_CONTENT was initially set to FALSE.

Why bother to install default content in the background without giving the user a choice? Well this option is pretty useful in situations where you ALWAYS want to make sure default content is installed every time a theme is activated. We already have one clear use in mind for this feature, for a proposed theme test area. Users will be able to sign up for an account and get full admin access to a blog where they can try out any of our themes.

In this scenario, it suddenly becomes clear that being able auto-install default content upon theme activation is pretty useful. This is a great way to show off a theme to its full potential right from the start, without the user having to do any initial configuration.

The theme activation feature discussed in this post is really still a work in progress, and the final implementation will almost certainly change before we use this in a production theme. But, we were pretty excited by this new addition to our theme framework, and wanted to share our development progress!

So let us know what you think in the comments. Would you find this feature useful?