Category Archives: Tutorial

Change Taxonomies Permalink header

How To Change Your WordPress Category, Tag, or Post Format Permalink Structure

By | Tutorial | 3 Comments

There are five default WordPress taxonomies: category, post_tag, post_format, nav_menu, and link_category – but nav_menu and link_category are off in a world of their own so let’s pretend they don’t exist for now. All of the settings for these taxonomies are preset by the fine folks at WordPress, and hard-coded into WordPress core, so if you want to make any changes, you have to do a little work.

The category, post_tag, and post_format default slugs, or permalinks, are simple. Categories are preceded by the slug ‘category’, post tags are preceded by the slug ‘tag’, and post formats are preceded by the slug ‘type’. In other words…

But what if you wanted to change the slug to something else? Or get rid of it altogether?

Changing the Slug

Changing the category/tag slug is pretty simple. The base for the slugs are stored as options so all you have to do is hook into the ‘pre_option_{option name}’ filter that’s applied when options are retrieved, allowing you to change the value that’s returned. The category slug’s option name is ‘category_base’ and the tag slug’s option name is ‘tag_base’ so the filters are ‘pre_option_category_base’ and ‘pre_option_tag_base’.

Changing the post format slug is a little different. The base is not stored as a option but it does have a filter: ‘post_format_rewrite_base’.

The following code will, most likely, go in your functions.php file. Remember that filters must always return a value. Learn more about filters.

add_filter( 'pre_option_category_base', 'mysite_change_category_base' );
function mysite_change_category_base( $value ) {
   
   // let's change our category slug to rantings
   // this will change the permalink to http://wpdreamer.com/rantings/wordpress/
   return 'rantings';

}

add_filter( 'pre_option_tag_base', 'mysite_change_tag_base' );
function mysite_change_tag_base( $value ) {
   
   // let's change our tag slug to ravings
   // this will change the permalink to http://wpdreamer.com/ravings/custom-post-types/
   return 'ravings';

}
add_filter( 'post_format_rewrite_base', 'mysite_change_post_format_base' );
function mysite_change_post_format_base( $value ) {
	
   // let's change our tag slug to fanciness
   // this will change the permalink to http://wpdreamer.com/fanciness/video/
   return 'fanciness';

}

Removing The Slug

Removing the slug altogether requires a different workaround, but it’s still pretty simple.

When WordPress registers these default taxonomies, the register_taxonomy() function adds a permastruct for each taxonomy that registers its permalink structure. All you need to do is overwrite the permastruct with your own.

These taxonomies and permastructs are registered during the ‘init’ action on priority level 0 (highest priority) so we’ll add our own hook into the ‘init’ action, but give it a lower priority so it’s executed after WordPress does its thing.

The following code will, most likely, go in your functions.php file. Learn more about actions.

Heads up: I don’t recommend removing the slug from categories, tags AND post formats. In fact, I wouldn’t recommend removing the slug from more than one of these taxonomies because then WordPress would have a very difficult time figuring out your URLs. The code for removing all three is only shown together so you can pick which set you need.

If you still want to remove multiple slugs, or if you’re having issues with your changes, I recommend installing the Rewrite Rules Inspector plugin. It shows you all of your rewrites and allows you to filter out which rewrites match a specific URL.


// make sure our action's priority is lower than 0,
// which is the highest priority, so basically any
// number greater than 0 will do. let's go with 1.
add_action( 'init', 'mysite_change_taxonomy_permalinks', 1 );
function mysite_change_taxonomy_permalinks() {

   // changing the category permastruct
   $taxonomy = 'category';
		
   // change the settings at will but make sure 'slug' is set to NULL
   $category_rewrite = array(
      'hierarchical' => true, // categories are defaulty hierarchical
      'slug' => NULL, // we don't want no slug!
      'with_front' => false, // this is up to you
      'ep_mask' => EP_CATEGORIES // this is a constant set by WordPress we'll use
      );
			
   // overwrites default category permastruct
   add_permastruct( $taxonomy, "%$taxonomy%", $category_rewrite );
		
   // ----------------------------------
		
   // changing the post_tag permastruct
   $taxonomy = 'post_tag';
		
   // change the settings at will but make sure 'slug' is set to NULL
   $post_tag_rewrite = array(
      'slug' => NULL, // we don't want no slug!
      'with_front' => false, // this is up to you
      'ep_mask' => EP_TAGS // this is a constant set by WordPress we'll use
      );
			
   // overwrites default post_tag permastruct
   add_permastruct( $taxonomy, "%$taxonomy%", $post_tag_rewrite );
			
   // ----------------------------------
		
   // changing the post_format permastruct
   $taxonomy = 'post_format';
		
   // change the settings at will but make sure 'slug' is set to NULL
   $post_format_rewrite = array(
      'slug' => NULL, // we don't want no slug!
      );
			
   // overwrites default post_format permastruct
   add_permastruct( $taxonomy, "%$taxonomy%", $post_format_rewrite );

}

Heads up: Sometimes messing with permalink settings requires you flush your system’s rewrite rules in order for the changes to take place. But they only need to be flushed once, each time you make a change, and not every time a page loads. To flush your rules, go to Settings -> Permalinks and click “Save Changes”.

Subdomain Multisite header

How to Setup a Localhost WordPress (Sub-domain Multisite) Environment

By | Tutorial, WordPress | 20 Comments

Heads up that I work on a Mac so, therefore, this tutorial is for Mac OS. However, I’m sure the majority of this process can easily be applied to Windows.

So you want a localhost WordPress sub-domain multisite network for testing? Great! But, per WordPress Settings Requirements, “You cannot choose Sub-domain Install (for a domain-based network) if the WordPress address (URL) is localhost or 127.0.0.1.” Eh. No worries. The requirements also point out that “you can create a domain-based network on your local machine by using your hosts file to map another hostname [to your local IP address], so that you never have to use the hostname localhost.”

In other words, unlike http://localhost, your localhost URL needs to have a domain name, e.g. http://localhost.com, so you’ll have to tell your local machine to use http://localhost.com instead.

This is a pretty extensive tutorial that, in the end, will have walked you through the entire process of creating a localhost WordPress sub-domain multisite environment. However, if you don’t need multisite, or don’t need sub-domain multisite, just skip sections 3 and 5.

  1. Setup Your Local Server
  2. Place The WordPress Files
  3. Change Localhost To Localhost.com – required if you want a sub-domain multisite environment
  4. Install WordPress
  5. Create A WordPress Multisite Network – required if you want a multisite environment

Prerequisites

Make sure you have the following setup, and downloaded, before moving forward.

  • The latest version of WordPress
    • It’s kind of important.
  • MAMP or WAMP
    • Allows you to install a local server environment on your Macintosh or Windows system.
    • Stands for Macintosh or Windows, Apache, MySQL, and PHP.
    • A server with Apache, MySQL, and PHP are all required in order to run WordPress. MAMP/WAMP allows you to run such a server on your computer!
    • At publication, I am running version 2.1.3, which is the most up-to-date version.
  • A code editor or text editor
    • I use Coda 2. It’s pretty nice. Anything from Panic is pretty nice.
    • There are a lot of free options. TextWrangler being one.
    • If you still don’t know, Google is your best friend.

1. Setup Your Local Server

Per WordPress requirements, in order to run WordPress you need a server running PHP and MySQL. MAMP, which stands for Macintosh, Apache, MySQL, and PHP, allows you to install such a server on your local system.

Configure MAMP

  1. Open MAMP.
  2. Click “Preferences” – I’ve included screenshots of my preferences below.
    • Start/Stop – These are really personal preferences. I like to check “Start Servers when Starting MAMP” and uncheck everything else.
      • I’m starting MAMP usually because I want to start the servers so why not automatically start the engines.
      • Not stopping the servers when you quit MAMP means you don’t have to keep MAMP open.
      • Not checking for MAMP PRO means I don’t get an annoying message every time I open MAMP.
      • My start page url is set to “/MAMP/”.
    • Ports – In order to have a sub-domain multisite environment, you must click “Set to default Apache and MySQL ports”. This will set the Apache port to 80 and the MySQL port to 3306.
    • PHP – I recommend selecting the most recent PHP version. My PHP extension is set to “XCache”.
    • Apache – Select a directory that will serve as your document root, i.e. the location where you will keep your WordPress files.
      • My preference? The “Sites” folder which, for Mac, is usually located in your Users folder. Mine is located at “/Users/rachelcarden/Sites”. But it really doesn’t matter. Just try to keep it simple and yet choose what you deem an important location. This could potentially hold a lot of important files.
  3. Click “OK” – to save and close your preferences.
  4. Click “Start Servers” – you might need to enter your administrator password.
  5. If you didn’t check “Stop Servers when quitting MAMP”, you can quit MAMP now. If not, you have to keep MAMP open for the servers to run.

Create Your Localhost WordPress Database

There’s just one more step to setting up your server. Your local machine is now running MySQL but you’ll need to create a a database for WordPress to use.

Create a database in phpMyAdmin

Create a database in phpMyAdmin

Create a database in Sequel Pro

Create a database in Sequel Pro

If you have a MySQL database management program, now’s the time to open that baby up. I use Sequel Pro. It’s pretty good and it’s free. If not, no worries. MAMP comes with phpMyAdmin, which is a web interface for MySQL management. All you have to do is open your MAMP start page, which should be http://localhost/MAMP/, and click on, you guessed it, “phpMyAdmin” in the top menu. Another way to open the start page? Open MAMP -> Click “Open start page”. Now just a few simple steps:

If Using phpMyAdmin

  1. Click the “Databases” tab.
  2. Enter the database name into the blank field. I’m gonna call mine WPDEV.
  3. Click “Create”.

If Using Sequel Pro

  1. Connect to your localhost server.
    • Name: Localhost
    • Host: 127.0.0.1
    • Username: root
    • Password: root
  2. Select “Database” from the top menu and click “Add Database…”.
  3. Enter the database name into the blank field. I’m gonna call mine WPDEV.
  4. Click “Add”.

2. Place The WordPress Files

Remember the document root you just selected in your MAMP preferences? Place the WordPress files in your document root directory. Mine is my “Sites” folder, located at “/Users/rachelcarden/Sites”.

3. Change Localhost To Localhost.com
required if you want a sub-domain multisite environment

Opening my hosts file in the terminal

Opening my hosts file in the terminal

What my hosts file looks like

What my hosts file looks like

As I pointed out at the beginning, per WordPress Settings Requirements, “You cannot choose Sub-domain Install (for a domain-based network) if the WordPress address (URL) is localhost or 127.0.0.1.” You can, however, “create a domain-based network on your local machine by using your hosts file to map another hostname [to your local IP address], so that you never have to use the hostname localhost.”

In other words, unlike http://localhost, your localhost URL needs to have a domain name, e.g. http://localhost.com. It’s now time to map http://localhost.com to our IP address so it can be used for our network domain.

Now, don’t freak out but the hosts file is locked so you’re going to have to use the Terminal. It’s really not that difficult. I promise. Just follow this nice, simple tutorial and, when you get to the part that says “simply append your new mappings”, append the following:

127.0.0.1            localhost.com

Note: Unfortunately, you cannot cover ALL of your sub-domains with the above line which means you will have to repeat this process for each site on your sub-domain multisite network. If you already know of a sub-domain you wish to use, I recommend you go ahead and add it to the list. For example, I will use http://cptonomies.localhost.com so I will also append the following:

127.0.0.1            cptonomies.localhost.com

Once you’ve finished the tutorial, you should now be able to visit http://localhost.com/. Do you see a WordPress Error screen that says “There doesn’t seem to be a wp-config.php file. I need this before we can get started.”? You do? Awesome! This means everything worked so click “Create A Configuration File” and let’s get configuring!

4. Install WordPress

A word to the wise going forward for sub-domain multisite setups: Make sure you’re on http://localhost.com, and not just http://localhost, while you’re installing WordPress because WordPress will save your domain in its settings.

With the server set up, and the WordPress files in place, you are now ready to visit http://localhost.com, which should initiate the WordPress installation script. WordPress provides a very helpful walkthrough to help you get everything setup properly.

Enter Your WordPress Database Connection Data

My WordPress database connection data

My WordPress database connection data

The first screen you’ll come across, that requires data, will be for the database connection. Enter the following information:

  • Database Name: the name of the database you just created – I used WPDEV
  • User Name: root
  • Password: root
  • Database Host: localhost
  • Table Prefix: wp_

Submit your information, finish the “famous five minute WordPress installation process”, and login to your WordPress admin/dashboard.

5. Create A WordPress Multisite Network
required if you want a multisite environment

Create a multisite network

Create a multisite network

The WordPress Create A Network codex page makes the process look pretty complicated so let me break it down for you:

  1. Allow for Multisite – follow step 2 on the Create A Network codex page.
  2. Go to your Admin. Click Tools -> Network Setup.
  3. Select “Sub-domains”. Enter network details. Click “Submit”.
  4. Don’t worry about the “Warning! Wildcard DNS may not be configured correctly!” warning.
  5. Follow the instructions on the page and click “Log In” at the bottom of the screen.
  6. Log back in to your admin.

Congratulations! You are now running a localhost WordPress Multisite! Now it’s time to add a second site.

Add a site to your WordPress network

Add a site to your WordPress network

Create A New Multisite Site

  1. Click “My Sites” at the top left (in your admin bar) and click “Network Admin”.
  2. Click “Sites”. You should now see that the only site listed is your primary site “localhost.com”.
  3. Click the “Add New” link at the top, fill out the form, and click the “Add Site” button.

Now, remember how I mentioned back when we were editing the hosts file that the hosts file has to list ALL of your sub-domains? Well now’s the time to make sure your new sub-domain is listed in your hosts file because, otherwise, you will not be able to view your new site.

If you’re able to view your site then your multisite setup is complete!!! Hooray!!! Time for a happy dance! I hope this tutorial was helpful. If you have any questions or issues, and a quick Google search didn’t help you out, feel free to comment and I’ll try to help you out as soon as possible.

If you want to take your local testing environment a step further, then be on the lookout for my next tutorial: “How To Turn Your Localhost WordPress Environment Into A SVN Repository”.

admin_bar_featured

How to Hide the WordPress Admin Bar

By | Tutorial, WordPress | One Comment

The WordPress admin bar, or toolbar, can be really helpful but sometimes it gets in my way, especially when I’m trying a new design and having difficulty imagining what it looks like without a dark gray bar running across the top.

For most people, with a single WordPress install, the solution is simply a matter of going into your profile and unchecking “Show Toolbar when viewing site”. But what if you’re running WordPress multisite? Unchecking that box removes the toolbar across your entire network when you only wanted to hide the toolbar on the new site you’re designing.

Sometimes I require a password for front-end content but there’s no need to grant access to the admin/dashboard, or frankly for them to even know it exists, so I’d rather not confuse them with a pointless toolbar.

Thankfully, as with most functionality in WordPress, there’s a pretty easy way to tell the admin bar to go away.

  1. Write a function which hooks into the “after_setup_theme” action.
    • Hooking into this action is important because it allows us to also remove the styles and scripts that WordPress enqueues for the admin bar. If they are not removed, then there will still be a space at the top of your page for the bar and that’s not very helpful.
  2. Inside your function, call the WordPress function, show_admin_bar() and pass just one parameter: false

There’s obviously a wide variety of scenarios for when and where to hide your admin bar, but hopefully the following examples will give you a good groundwork. This code will, most likely, go in your functions.php file.

Always Hide The Admin Bar

If you want to hide the admin bar for good, no matter who’s looking at the site, the code is pretty simple.

add_action( 'after_setup_theme', 'my_website_remove_admin_bar' );
function my_website_remove_admin_bar() {
   show_admin_bar( false );
}

Hide the Admin Bar If The User Doesn’t Have Access To The Admin/Dashboard

If you want to hide the admin bar from users who don’t have access to the admin/dashboard, then check their user capabilities. The capability to “read” is what allows access to the administration panel.

add_action( 'after_setup_theme', 'my_website_remove_admin_bar' );
function my_website_remove_admin_bar() {
   
   // if the user cannot "read", then they cannot access the admin/dashboard
   if ( ! current_user_can( 'read' ) )
      show_admin_bar( false );

}

Hide The Admin Bar on Specific Multisite Sites

If you want to hide the admin bar on specific sites on your multisite network, use the global $blog_id variable in your logic. The global $blog_id variable contains the ID of which site is currently being viewed.

add_action( 'after_setup_theme', 'my_website_remove_admin_bar' );
function my_website_remove_admin_bar() {
   
   // access the global variable
   global $blog_id;

   // remove the admin bar for one site
   if ( 3 == $blog_id )
      show_admin_bar( false );

   // remove the admin bar from multiple sites
   if ( in_array( $blog_id, array( 3, 5, 8, 10 ) ) )
      show_admin_bar( false );

}

Hide The Admin Bar on Specific Pages

Using WordPress conditional tags allows you to easily hide the admin bar on specific sections, or pages, of your site.

add_action( 'after_setup_theme', 'my_website_remove_admin_bar' );
function my_website_remove_admin_bar() {

   // hide the admin bar on your main page
   if ( is_home() )
      show_admin_bar( false );

   // hide the admin bar on your page with the title of 'About Me'
   if ( is_page( 'About Me' )
      show_admin_bar( false );

   // hide the admin bar on any taxonomy archive page
   if ( is_tax() )
      show_admin_bar( false );

}

How to Define Reserve Slugs for WordPress Posts and Pages

By | Tutorial, WordPress | No Comments

This post was inspired by an answer I posted in the WordPress Stack Exchange.

This is an interesting WordPress problem that could span several scenarios. But let’s say you have a custom post type named ‘songs’ and you defined its slug as ‘songs’ so its archive page URL is http://www.mysite.com/songs.

This is fine and all but a slug used for a custom post type archive page, i.e. ‘songs’, is not saved in the database and is, therefore, not available when you’re creating/editing posts to tell WordPress “NO! The slug ‘songs’ is taken!”. With that said, a user could come along and create a post (or page) with the slug ‘songs’ which would therefore have the same URL as your custom post type archive page: http://www.mysite.com/songs.

So how do you keep users on your site from creating posts with particular slugs, a.k.a. reserve slugs?

It’s pretty simple, actually. Use one, or both, of the following two filters. They hook into WordPress when it’s checking a post’s slug, allowing you to return “true” which tells WordPress that the post slug is bad. If you return “true”, WordPress adds on a suffix, just like it would do if you were trying to use a slug that is already taken.

The first filter, ‘wp_unique_post_slug_is_bad_hierarchical_slug’, is for hierarchical posts and the second filter, ‘wp_unique_post_slug_is_bad_flat_slug’, is for non-hierarchical posts. While both filters provide the post’s $slug and $post_type, the hierarchical filter also provides the ID for the post parent so if the $post_parent is 0, you know this is a “base” post.

add_filter( 'wp_unique_post_slug_is_bad_hierarchical_slug', 'rachel_carden_is_bad_hierarchical_slug', 10, 4 );
function rachel_carden_is_bad_hierarchical_slug( $is_bad_hierarchical_slug, $slug, $post_type, $post_parent ) {
   // This post has no parent and is a "base" post
   if ( !$post_parent && $slug == 'songs' )
      return true;
   return $is_bad_hierarchical_slug;
}

add_filter( 'wp_unique_post_slug_is_bad_flat_slug', 'rachel_carden_is_bad_flat_slug', 10, 3 );
function rachel_carden_is_bad_flat_slug( $is_bad_flat_slug, $slug, $post_type ) {
   if ( $slug == 'songs' )
      return true;
   return $is_bad_flat_slug;
}

These filters can be found in the WordPress function wp_unique_post_slug() in the wp-includes/post.php file.

Want to give a little love and support my work? Donate