Configuration

With WPM installed you’re ready to begin configuring your theme with Post Types and Taxonomies.

WordPress' native data types are Posts and Pages. WPM's defaults when creating a Post Types allow you to create new data types based around hierarchy (like pages) or chronology (like blog posts). While this may seem simplistic at first, most data falls within these two categories with various types of ordering applied. WPM defaults to creating Post Types like posts.

With WPM, creating post types is really easy. The most bare-bones Post Type creation is made in this way:

// create a member post type
wpm('wp.post_type')->create([
    'name'      => 'Member'
]);

Here we've created a "Member" Post Type. To make this very simple, WPM makes a few decisions for you:

• If the plural name is not defined, it will become the "name" value with an "s" tacked on
• The slug for this Post Type will be the lowercase form of the "name" value
• This Post Type will be based on the "post" Post Type (has archive, chronological, etc)
• All labels will be automatically generated for this Post Type
• Fields not generated by WPM will take on WordPress' defaults.

Now let's create a FAQ like the "page" Post Type and News like the "post" Post Type

// faq post type
wpm('wp.post_type')->create([
    'name'        => 'FAQ',
    'plural_name' => 'FAQ',                      // overrides default of "faqs"
    'like'        => 'page',                     // like pages so we can order and nest
    'icon'        => 'dashicons-editor-help',    // dress up the cms
    'supports'    => [                           // change supported attributes
        'title', 'editor', 'excerpt'
    ]
]);

// news post type
wpm('wp.post_type')->create([
    'name'        => 'News',
    'plural_name' => 'News',                 // overrides default of "newss"
    'slug'        => 'news',                 // manually set
    'like'        => 'post',                 // like post (chronologically ordering)
    'icon'        => 'dashicons-admin-page'  // dress up the cms
]);

Any argument allowed when registering a custom post type can be passed in via the array to override WPM's defaults.

When setting the "like" key to "page," the "has_archive" default is set to "false" and the "hierarchical" default is set to true. Also, "supports" is set to:
['title', 'editor', 'author', 'excerpt', 'custom-fields', 'page-attributes']

When setting the "like" key to "post," the "has_archive" default is set to "true," "hierarchical" is set to "false", and "menu_position" is set to "null." Also, "supports" is set to:
['title', 'editor', 'author', 'excerpt', 'custom-fields', 'comments']

Taxonomy is a fancy word for Category. With Taxonomies you can setup different ways to categorize a Post Type. Using our "member" post type, we can begin adding taxonomies to help us associate this member to others in helpful ways. The simplest Taxonomy creation will look like the following:

wpm('wp.taxonomy')->create([
    'name'       => 'Role',
    'post_type'  => 'member'
]);

As with Post Types, WPM will make some decisions here for you:

• If the plural name is not defined, it will become the "name" value with an "s" tacked on
• The slug for this Post Type will be the lowercase form of the "name" value if not defined

Here is an example using all of WPM's shorthand

wpm('wp.taxonomy')->create([
    'name'        => 'Education',        // singlular form
    'plural_name' => 'Education',        // plural form
    'slug'        => 'education',        // slug for url
    'post_type'   => 'member'            // post type slug to assign taxonomy
]);

Beyond this shorthand, any argument that can be passed to WordPress' register_taxonomy function can be added to the arguments array.

One thing lacking in WordPress is the ability to Drag and Drop sort posts within a Post Type. WordPress' menu system is great for one off menus but do not apply when you'd like to show the children of a the current page in order. Updating a number field is kinda silly. Instead, use the wpm Sort feature like so:

wpm('sort')->add(['page', 'faq']); // add Post Type slugs to the array

With this, you'll get an additional page under each Post Type in the CMS titled "Sort." On this page you can now drag and drop sort and next post type. There is also a helpful Taxonomy selector at the top of the sorting list to help if necessary.

There are plenty of ways to add and modify actions but they aren't so clean in WordPress. So many different functions! Gross. Here they are collected into a neat wp.action interface.

->add()

When adding adding an action, the first parameter is the action and the second is either a string of the function name or a closure.

// pass the string of a function name
wpm('wp.action')->add('get_footer', 'update_site_stats');

// use a closure
wpm('wp.action')->add('get_footer', function() {
    update_site_stats();
    load_popups();
});

->remove()

Remove allows you to prevent an action from taking place if its function name was provided.

wpm('wp.action')->remove('get_footer', 'load_all_popups');

->removeAll()

Instead of just removing a specific action, you can remove all actions from a hook.

wpm('wp.action')->removeAll('get_footer');

->has()

With Has, you can check if a given hook has been assigned an action.

if(wpm('wp.action')->has('get_footer', 'do_stuff')) {
    echo 'Yup, I can do that!';
}

->run()

For the impatient, run will allow you to do all actions that are set on a given hook.

wpm('wp.action')->run('get_footer');

It is also possible to run actions on a hook while sending in an array.

wpm('wp.action')->run('get_footer', ['name', 'time', 'place']);

->running()

Check if hook of actions are currently running.

if(wpm('wp.action')->running('save_post')) {
    // the post is saving!
}

->ran()

Check the number of times an action was ran. A result of 1 or greater would mean it was called.

if(wpm('wp.action')->ran('save_post')) {
    // the post was saved
}

As with Actions, there are plenty of ways to add and modify Filters with a jumbled mess of functions. Here they are collected into a neat wp.filter interface.

->add()

When adding an filter, the first parameter is the action and the second is either a string of the function name or a closure.

// pass the string of a function name
wpm('wp.filter')->add('the_title', 'make_bold');

// use a closure
wpm('wp.filter')->add('the_title', function($title) {
    return '<strong>' . $title . '</strong>';
});

->remove()

remove allows you to prevent an filter from taking place if its function name was provided.

wpm('wp.filter')->remove('the_title', 'makeBold');

->removeAll()

Instead of just removing a specific filter, you can remove all filters from a hook.

wpm('wp.filter')->removeAll('the_title');

->has()

With has, you can check if a given hook has been assigned a filter.

if(wpm('wp.filter')->has('the_title', 'makeBold')) {
    // the_title will be filtered with the makeBold function
}

->run()

Filters are used to manipulate content in some way. With run, you can run a hook's filters on any given value.

echo wpm('wp.filter')->run('the_content', $meta_value);

It is also possible to apply filters on a hook while sending in an array of arguments. If you're in to that sort of thing.

wpm('wp.filter')->run('the_content', [$meta_value]);

->running()

Check if filters are currently being ran on a hook.

if(wpm('wp.filter')->running('the_title')) {
    // the title is being filtered
}