Simplr Registration Form Plugin

Installation Instructions:

Download and unzip the package. Upload the simplr_reg_page folder into your wp-content/plugins directory. Go to your plugins dashboard and click “Activate”.

Usage Instructions:

To use this plugin simply employ the shortcode [Register] on any WordPress post or page. The default role is “subscriber”. To apply another role to the registration simply use the the role parameter, for instance: [Register role="editor"]. If you have created custom roles you may use them as well.

You can also use shortcode so specify a custom confirmation message for each form:

[Register role="teacher" message="Thank you for registering for my site. If you would like to encourage your students to register, please direct them to http://www.domain.com/students"]

Finally, you can specify emails to be notified when a new user is registered. By default site admins will receive notice but to notify others simply use the notify parameter:

[Register role="teacher" message="Thank you for registering for my site. If you would like to encourage your students to register, please direct them to http://www.domain.com/students" notify="email1@email.com,email2@email.com"]

Plugin Options:

Please feel free to suggest future options for this plugin in the comments. The current options are:

• Admin Email: Specify the FROM email you would like to use for the registration confirmation message.
• Confirmation Message: Customize the message you would like to appear in the confimation email.
• Style: Overrides the default stylesheet included with the plugin.

WordPress Custom Post Type UI

Developer: WebDevStudios | Download Link

This was likely the first WordPress 3.0-specific plugin posted on WordPress.org. It creates an easy-to-use interface for creating and managing your custom post types. You can also use it to manage taxonomies.

While I always recommend people try to learn as much about the code as possible so as not to be overly reliant on plugins. This is a good one to keep around. It will make your life easier and keep you functions.php file from getting too crowded.

Post Type Switcher

Post Type Switcher

Developer: John James Jacoby | Download Link

I love this simple little plugin. It adds a post type switcher to your “Publish” meta-box that allows you to easily change a page or a post to a custom post type. Though, I wish he’d find a way to work this into the bulk editing functionality so you could switch multiple posts at once.

WP Easy Post Types

Developer: NewSignature | Download Link

This plugin takes the custom post type user interface to another level. Not only can you create and manage new post types but you can create and manage custom fields and meta boxes associated with a particular post type. It comes with a built-in date picker field to help with post types that are date-specific. Another key feature giving this plugin loads of potential is that it allows you manage the admin display of your created post types. For instance, if you wanted a custom field to show up in the posts list screen, you can do that.

Relations Post Types

Download Link

From a developer POV, the Relations Post Type plugin is the most interesting one I’ve seen because it satisfies the need to easily related data between post types. Say you have an Events post type and you want to associate each Event with a speaker. You can do this by creating a custom taxonomy for “speaker”, but you would be limiting the amount of info you could assign to the term “speaker”. So what if you create another post type for “Speaker” then assigned a speaker to the Event using a custom meta box. You can do that but there will be some serious custom programming involved. That’s what this plugin does.

But before you run off thinking the Relations Post Types plugin is going to save your wordpress dev project,  it still has a long way to go. For one thing, the documentation is non-existent. It comes with an easy to deploy sidebar widget, but to do anything more you’ll need to dig into the code.

Also, the plugin sets up an additional table for storing the relationships, which means you’ll have to do a little SQL to retrieve the info, unless the developers decide to create a special query class. Some might question why the relationships couldn’t be stored as a custom field instead of in a new table. The answer, at least in my estimate, is that a relationship table will allow you to perform more complex and more efficient queries on the data.

So, while this plugin looks awesome in theory. There’s some time before it will be mature enough for non-expert devs to use.

Convert Post Types

Developer: Stephanie Leary | Download Link

Ah hah! Here’s the one I’ve been waiting for. Need to convert all those old events-category posts to you new Events post type? This will do it for you in one click saving you the trouble of performing any DB operations via phpmyadmin. Whoo hoo!

Are there any I forgot? If so, let me know and I’m happy to look at them.

At any rate, for anyone who’s running a pods installation and having trouble getting SEO friendly titles on your pod pages, this plugin creates a template tag <?php pods_seo_title(); ?> that you can use to override wordpress default behavior. The plugins check to see if the page is a pod page, and if so calls the title of the respective pod. If not, it checks to see if the page is singular and returns the TITLE | SITENAME format if it is. Otherwise it returns the SITENAME | SITE DESCRIPTION form.

Download: Pods SEO Titles

The Issue: You’re working on a site designed long before Custom Post Types were an itch in Matt’s cerebellum. But now that the functionality is there and you want to incorporate it into your theme. Previously you used conditional code to theme your single.php file.

<?php if(in_category('foo')) { ?>
   Do something.
<?php } elseif(in_category('bar')) { ?>
   Do something else.
<?php } else { ?>
   Do yet another thing.
<?php } ?>

The thought of adding yet another layer of conditionals makes you sick to your stomach. Custom Post Types need to be treated completely different. They have different categories, taxonomies, and even different sidbars. Arg!

Solution: One simple function. Call it whatever you want, but here’s what it looks like. When I say simple … I mean simple.

function get_post_in_context() {
   global $post;
   $type = $post->post_type;
   include(TEMPLATEPATH .'/layouts/single-'.$type .'-content.php');
}

Now just create a directory in your theme called “layouts”. Then copy and paste all the markup in your single.php file between the get_header() tag and the get_sidebar() tag to a file named single-post-content.php and save the file to your layouts folder.

Now place a the get_post_in_context() tag into your single.php  where you want the markup from single-post-content.php to show up.

<?php get_header(); ?>
<?php get_post_in_context(); ?>
 <?php get_sidebar(); ?>
<?php get_footer(); ?>

The beauty of this is that you can now create a new single-POSTTYPE-content.php (example:single-events-content.php) file for any of your custom post types and it will automagically get called instead of the single-post-content.php without any more changes to the single.php file.

I can’t take total credit for the idea. Some theme frameworks already employ a version of this strategy. But I need to adapt an existing theme rather than start from a framework. This function above will allow you to scale your existing theme to accomodate new post types without having to redesign your whole site.

http://tinyurl.com/3y7ev4c

WordPress founder Ma.tt Mullenweg explains how WordPress is like jazz.

Taking only the simple definition under consideration, WordPress users are likely to get the impression that, all things being equal, you should use a framework. After all, who wouldn’t want the added benefit and “flexibility” of being able to have “child” themes. Sounds cool.

But once you unpack a framework theme and start futzing with it, you quickly realize all is not perfect in the land of “frameworks”. So here’s my stab at a more useful definition. A WordPress Theme Framework is a theme that has additional code built into it making selected tasks easier for theme developers to manage. The emphasis on developers is mine and is very important.

Over the last several months I’ve built sites using several different frameworks and found that there is little advantage consistent across all frameworks, though each framework has specific advantages. The only consistency is that to really benefit from frameworks you need to have a deeper understanding of WordPress, its syntax, functions, plugins, etc.

If all you want to do is customize a theme, frameworks are likely to drive you crazy.

In Theory

In theory, frameworks are a very powerful thing. The idea is that you can take certain standard needs of theme developers and abstract them into new functions that allow the theme developer to execute customizations without messing with the theme core. With many theme frameworks, if you know what you’re doing, you can perform most theme modifications by editing only the style.css and the function.php files.

By way of an example, the Thematic Theme Framework has a hook called thematic_above_indexloop();. If I wanted to add a feature ad banner above the index loop of a regular theme, I would have to go into the the index.php, find the loop, and ad the code. But in the framework I simply have to go to the function.php file and add the following:

function feature_ad_banner() {
echo 'my feature ad banner';
}
add_action('thematic_above_indexloop','feature_ad_banner');

This code just tells the theme to pull in my custom function when it triggers this action. This gives me a ton of power as a developer because I can easily build an awesome site without worrying about building the “guts” of the theme. Or, to put it simply, I can focus on the cool stuff while ignoring the mundane details.

It’s all about the HOOKS

The drawback is that each theme framework has its own peculiarities and learning the appropriate hooks and filters can take time. If you’re a developer, this time is justified because it saves time on future projects. But if you just understand the basics of WordPress themes and are simply trying to customize one for your own use …especially if you aren’t all that comfortable with PHP … this extra level of abstraction can be a royal pain in your ass. If you’ve modified a loop before, you’ll find modifying a loop in a framework isn’t nearly as simple as you remembered. You have to create your own function and then track down the right hook to apply it to. A mod that used to take you 15 minutes, now takes you an hour.

Again, there are rewards to learning a framework, but make sure you understand the time investment required and how that squares with the benefits you expect to receive in return.

In short, WordPress Theme Frameworks are great for those serious about development. But hobbyist might want stick with an old fashioned WordPress Themes. In future articles I will look a few different frameworks and when you mind be inclined to use them.

There are several plugins that make working with custom fields a little easier. Custom Fields Template,  Flutter , and More Fields are the popular examples. These plugins provide the ability to set up custom “write panels” with new fields added for inputting custom fields.

In the latest versions of WordPress there is support for “post types” which should make it even easier to customize the post entry screen depending on the type of content you are inputting.

The alternative to this approach is Pods CMS. Pods is a WordPress equivalent to the Content Construction Kit available to Drupal developers. Pods does not use custom fields, rather it creates new tables and completely new data types.

There are advantages and disadvantages to both approaches to WordPress as a CMS. And if you are serious about building a WordPress site you need to understand those advantages.

Custom Fields

Pros:

• Native to WordPress. Does not require plugin installation to function and all posts are immediately connected to other WordPress plugins and functions
• All fields are text formatted, which means once you know how to output one custom field, you can output them all.
• Most plugins are already compatible with Custom Fields.

Cons:

• Queries with custom fields can be complex and convoluted. Sometimes you will need a “Custom Select Query” in order to accomplish your task.
• All fields are in LONGTEXT format, which means the database will be larger than it needs to be and this could put limits on the scalability of your site. (More on Custom Fields Scalability).
• End User support is still limited. The WordPress Dashboard, even with the mentioned plugins, is not fully customizable.

Pods CMS

Pros

• Fully customizable backend. You can specify exactly what fields the end user sees for any given content type.
• Public form support makes setting up forms for adding content on the front end relatively easy. Though the form options are limited and can be buggy.
• Field formats are customizable, which means your database is only going to be as big as it needs to be. This also means your site will be more scalable.
• Fields are relate-able. This is the biggest benefit to Pods. In future posts we will see exactly what this means.

Cons:

• Not supported by WordPress development team. This is truly a plugin and WordPress is hesitant to support it and would rather CMS developers use Custom Fields and Custom Taxonomies. This means if the plugin developers get tired of working on it, then your site could be toast. The good news is the Pods user base is growing rapidly and the bigger it gets, the less we will have to worry about this.
• Pods content is not added to WordPress posts table by default which means it is not available to native WordPress functions, like comments and Akismet, and is inaccessible to many plugins, like WP-PostViews (Note: there is a patch that will allow integration, but not seamless integration).
• Because of the complicated relational database, SQL queries are more difficult than with custom fields. Though you can do more with Pods not using SQL than you can with custom fields using SQL.

Choosing between Pods and Custom Field based development is a big decision and there isn’t a universal answer. Much will depend on the site you are building and what your goals are. But here are some questions you should ask yourself before making the decision:

• Are your custom content types generally “post-like”? If so, consider sticking with Custom Fields.
• Do you need to fully customize your Dashboard interface for the end-user? If so, Pods may be your best bet.
• Do you need to rely on other available WordPress plugins/functions? If so you’ll either need to patch your Pods install, or you should stick with Custom Fields.
• Do you need complex and relatable content types? An example would be an online journal where you need Volume, Issue, and article, each with particular information but also related to each other.
• Are you building a very large site with tens of thousands of entries? You may need to be concerned about scalability. Look at pods.

In most cases you will find your answers will be mixed. Your content is “post-like” but needs to be relatable. Or you are building a large site, but you need to integrate with other plugins. In most of my sites, I use a combination, deploying custom fields for basic post-like content, but Pods for more specialized content types like event listings.

As WordPress develops as a CMS I expect these two solutions will come together. WordPress cannot truly be considered a CMS with an easier way to (a) relate content and (b) customize content entry pages. Pods enables both.