I completed the changes to this site that I started yesterday but didn’t finish because of some last-minute bugs (glad to have found them before uploading).  The main issue keeping me from updating the site was that the featured posts functionality of Cornerstone was not working properly.  Featured posts in Cornerstone are similar to WordPress’ own sticky posts functionality in that it lets you place specific posts in front of the normal chronologically-sorted posts, which is useful when you want to highlight certain content.  Featured posts in Cornerstone differs from WordPress’ sticky posts in that it offers somewhat more customizability and control over how/when featured posts are displayed.

However, due to some changes last night, the featured posts weren’t being retrieved for output on the site.  To be quite honest, I wasn’t sure what I could have changed yesterday that could have broken the featured posts functionality, so I had no idea what to expect when I started investigating it this morning.  Thankfully the issue was relatively minor and was causing the wrong section ID to be used when attempting to retrieve featured posts for a specific section of the site.  I tightened up a couple conditional statements to make sure the section ID is properly retrieved and featured posts were once again working!

With that out of the way, I proceeded to prepare for deploying all updates to the production server.  Since everything had been updated to work with WordPress 3.0+, the first order of business was upgrading the production server to WordPress 3.0.1.  After that, I updated Cornerstone and the site’s theme files.  I cleared my cache, hit refresh, and held my breath.  The site loaded up fine and everything is working great on the production server!  The final step was changing the Dump section to Know, which basically entailed adjusting the section’s title, slug, and icon.

It took longer than expected for such a small change (all I originally intended to do was change the name of a section), but in the end the site is much better and more stable for the work that went into it.

Lessons learned

As with any situations that require troubleshooting, there are always lessons to be learned.  Here are some I lessons learned or reaffirmed today:

• Test, Test, Test – before any update big or small, I always follow the same workflow:
  1. Develop and test the code on my computer
  2. Upload updates to the offsite staging server (basically a private mirror of the public production server) to test for issues not found while testing locally
  3. Upload updates to the production server (the public site) and run through tests to confirm no issues exist

  The goal is of course to avoid any downtime on the public site and this basic workflow has saved me many headaches on all of my projects.  I should note that prior to each step I also backup all relevant files and databases so that I can revert to a working version very quickly and start fresh if things get too messy while I troubleshoot an issue.

• Exercise caution when manipulating WordPress’ post queries – Cornerstone hooks into the post query process in several modules (permalink rewriting, content types, featured posts, etc.) and I feel rather comfortable manipulating the query variables to retrieve the posts that I want, but it is also very easy to invalidate the query with just a small change.  Vigilance is key when manipulating post query objects.

I enjoy troubleshooting because I like the challenge of finding elegant solutions to problems.  Nonetheless, I am glad that I was able to work out the issues rather quickly today because it feels good to have my production site running the latest version of WordPress.

Next

I’m about to start working on 2 small WordPress plugins that I have been thinking about recently (one of them since this morning).  One is intended to improve privacy and the other will make it easier to customize a site’s favicon from within WordPress.  I’m looking forward to it.

What you should know now is that Dump is now Know was originally published on Archetyped on August 5, 2010 04:40pm

Well that didn’t take as long as I expected it to. While I still have some tests to run through, all work has been completed to make Cornerstone compatible with WordPress 3.0!  I was expecting this to take at least 2-3 days due to the amount of code I had to check, but after finishing what I had scheduled for today, I decided to just keep chugging along and ended up finishing everything on my list without much delay.

Here’s a rundown of what I did today:

Structure

Permalink Structure

The first thing on the list was adjusting the permalink structure for posts with custom post types.  By default, the structure for posts with custom post types is /post-type/post-name/, which doesn’t cut it when posts can now be added to a specific section regardless of their post type.  What we want is for all posts to use /section-name/post-name/ as their permalink structure.  I didn’t think this would be too difficult to rectify, and thankfully it wasn’t.  A quick look at get_permalink() (which Cornerstone hooks into to filter a post’s permalink) revealed that posts with custom post types were processed separately from standard posts:

elseif ( in_array($post->post_type, get_post_types( array('_builtin' => false) ) ) )
	return get_post_permalink($post, $leavename, $sample);

So in addition to hooking into post_link for standard posts, we also need to hook into post_type_link (which is called in get_post_permalink()). Thankfully, both filter hooks pass the default permalink along with the current post’s data (except that post_link supplies the entire post object while post_type_link only supplies the post’s ID) so the same handler can be used for both:

add_filter('post_link', $this->m('post_link'), 10, 2); //Standard posts
add_filter('post_type_link', $this->m('post_link'), 10, 2);  //Custom post types

With this additional hook added, posts with custom post types now have /section-name/post-name/ as their permalink structure.

Post Sections

Next on my list was providing the UI on the edit forms for custom post types to select the section the post should be saved to.  Prior to WordPress 3.0, I added the section selector to the edit form sidebar by hooking into the do_meta_boxes action. This works exactly as it should on the edit form for custom post types in WordPress 3.0, save for one difference– the action hook now passes the post type of the post currently being edited (as opposed to being hardcoded as “post” in earlier versions of WordPress). Since we only wanted the section selector to be added to the sidebar of the post edit form, that’s exactly what the handler looked for before adding the section selector meta box:

if ( 'post' == $type && 'side' == $context )
	add_meta_box($this->add_prefix('section'), 'Section', $this->m('admin_post_sidebar_section'), 'post', 'side', 'high');

Since the post type can now be variable, the condition for adding a the section selector meta box needed to be expanded a bit:

$child_types = get_post_types(array('show_ui' => true, '_builtin' => false));
$child_types[] = 'post';
$side_context = 'side';
$priority = 'high';
if ( in_array($type, $child_types) && $side_context == $context )
	add_meta_box($this->add_prefix('section'), __('Section'), $this->m('admin_post_sidebar_section'), $type, $context, $priority);

Basically, all custom post types that would have an edit form are retrieved, the “post” post type is added to the array of possible post types, and a check is performed to see if the current post type is included in this array. If so, the meta box is added and the section selector is displayed on edit form’s sidebar. I also took this opportunity to move some of the values in the add_meta_box call out into separate variables to further simplify future maintenance.

Taxonomies

I honestly thought it would take longer than it did to go through and fix the compatibility issues with permalinks and section selection so that was really all I had intended to work on today.  After finishing them so quickly, I decided that I would work on getting the rest of the edit form for custom post types to work properly.  The first thing was adding access to the standard post taxonomies (specifically, categories and post tags) on custom post type edit forms.

Once again, I thought I was in for some digging through WordPress’ code, and once again, it turned out to be incredibly simple.  WordPress provides the register_taxonomy_for_object_type() function that makes it very simple to connect a previously-registered taxonomy to a post type.  I could have used this, but WordPress also provides the ability to automatically register a taxonomy with a post type at the same time the post type itself is registered.  This is accomplished by adding a single item to the arguments array passed to register_post_type() when registering a new post type:

//...additional arguments for the post type being registered
'taxonomies' => get_object_taxonomies('post')

By using get_object_taxonomies('post'), we can be sure that any taxonomies registered to the standard “post” post type is also registered to our custom content types. In the future, I may add functionality to enable more control over which custom content types will inherit the taxonomies from WordPress’ built-in post type, but for now this makes the edit form for custom content types functional and useful for those wanting to use the same basic taxonomies with all content types.

Content Type Fields

The final thing that remained to make Cornerstone compatible with WordPress 3.0 was displaying a content type’s predefined fields on the edit form.  The implementation prior to WordPress 3.0 employed multiple hooks to make it all work (since custom post type functionality was not as fully fleshed out as it is in 3.0), but now all I needed was one hook:

add_action('do_meta_boxes', $this->m('admin_do_meta_boxes'), 10, 3);
//Build UI on post edit form

The handler is also very simple. Once it confirms that the context is appropriate for building the fields for a content type, the processing is handed off to an instance object of the content type definition which has a method to build the fields in meta boxes for output on the edit form:

function admin_do_meta_boxes($type, $context, $post) {
	//Validate $type. Should be 'post', 'page', or a custom post type for our purposes
	if ( in_array($type, array_merge(array_keys($this->get_types()), array('post', 'page'))) ) {
		//Get content type definition
		$ct =& $this->get_type($post);
		//Pass processing to content type instance
		$ct->admin_do_meta_boxes($type, $context, $post);
	}
}

Coming up next

With the compatibility work on Cornerstone out of the way, I can now continue where I left off before upgrading to WordPress 3.0 and start developing additional features and functionality for Cornerstone.  Here’s my basic plan:

1. Complete compatibility testing, fixing any small issues I missed
2. Develop UI for managing custom content types and their fields

The content type/field management UI will be heavy with “drag and drop” functionality to make adding and customizing content types very quick and simple.  This is one of the last major milestones I’m working towards before Cornerstone enters the public beta phase, so I am pretty excited to get started on this.

At the same time, I have a few other ideas for projects that have been dancing around in my head for the past few days and I’ve been itching to explore some of them.  I don’t intend to stay away from Cornerstone development for too long, but several of these projects will actually be using Cornerstone as the foundation of their functionality so I’ll still be working on Cornerstone as I explore these other projects.

Cornerstone: We have compatibility! was originally published on Archetyped on August 2, 2010 11:01pm

My main goal today was including all content items (regardless of post type) for display on the front end.  This would return content type functionality to what it was prior to WordPress 3.0.  Custom post types are now 1st-class citizens in WordPress, each with their own place in the post_type column of the wp_posts table.  They’ve been promoted to the big show and are no longer relagated to the wp_postmeta table with all the other secondary post data.

For my purposes, custom content types (Cornerstone’s extension of WordPress’ own post types) should generally not interfere with the retrieval of content, but serve primarily to indicate the types of metadata a content item can/should contain.  Since I’ve decided to synchronize custom content types with WordPress’ custom post types for better compatibility, we now have a small issue since the default posts query (e.g. used on the home page, etc.) only retrieves content items with “post” as the post type, so items with other content types are left in the dust and not retrieved.  Isn’t that just how it always is?  You get a leg up in the world, only to be pushed back down.  I say equality for all content types!

To rectify this and allow all content items regardless of content type to be retrieved in default post queries, I’ve hooked into the pre_get_posts action to modify the query before any posts are retrieved.

add_action('pre_get_posts', $this->m('pre_get_posts'), 20);
//Calls internal method

When the pre_get_posts action is fired, Cornerstone’s pre_get_posts method:

• Checks to make sure the query is a standard post query
• Retrieves all custom content types and adds them to the post_type query variable

/**
 * Modifies query parameters to include custom content types
 * @param WP_Query $q Reference to WP_Query object being used to perform posts query
 * @see WP_Query for reference
 */
function pre_get_posts($q) {
	$qv =& $q->query_vars;
	$pt =& $qv['post_type'];

	/* Do not continue processing if:
	 * > In admin section
	 * > Single object requested
	 * > More than one post type is already specified
	 * > Post type other than 'post' is supplied
	 */
	if ( is_admin()
	|| is_singular()
	|| ( is_array($pt)
		&& ( count($pt) > 1
			|| 'post' != $pt[0] )
		)
	|| !in_array($pt, array('post', null))
	) {
		return false;
	}
	$default_types = $this->get_default_post_types();
	$custom_types = array_diff(array_keys($this->get_types()), $default_types);
	if ( !count($custom_types) )
		return false;
	//Wrap post type in array
	if ( empty($pt) || is_null($pt) )
		$pt = array('post');
	if ( !is_array($pt) )
		$pt = array($pt);
	//Add custom types to query
	foreach ( $custom_types as $type ) {
		$pt[] = $type;
	}
}

With the additional content types added to the query, all content items are now retrieved in standard post queries (ultimately, each custom content type will have the option to define whether it is included in standard queries or not).  All is now right with the world and I can sleep soundly knowing that custom content types are getting a fair shake.

Next

Work on content types continues as permalinks for content with custom post types need to have the ability use the section-name/post-name permalink structure enabled by Cornstone (by default it’s post-type/post-name).  Once that’s sorted, I’m heading back to the admin section to work on the edit form for items with custom post types.

Cornerstone: All Content Types Aboard! was originally published on Archetyped on July 30, 2010 08:36pm

Today I began working on making Cornerstone compatible with WordPress 3.0.  Content types (whose primary role is to allow creation of additional metadata fields for post types) was first on the list.

Prior to 3.0, I had developed my own implementation for creating, editing, and managing different post types from the admin menu.  Now that WordPress’ own custom post type functionality was ready for these tasks, my first task was migrating the functionality of my custom implementation to use WordPress’ implementation.  I considered my implementation a stopgap since I knew WordPress would have custom post type management sooner or later, so it wasn’t an unexpected task.  Nonetheless, I wasn’t exactly looking forward to it.  In the end, it wasn’t all that bad.

Registering Custom Content Types

The first thing I had to do was integrate my custom content type definitions with WordPress’ own custom post type array.  While they are fairly similar at the base level, Cornerstone’s content types contain somewhat more data and functionality than WordPress’ custom post type objects (mostly because Cornerstone’s content types also contain metadata field definitions for the custom content type), so I couldn’t just use WordPress’ post type implementation.  In the end, it was a simple matter of calling the register_post_type() function during the registration of each custom content type in Cornerstone.  This way, custom post types are registered for each custom content type defined by Cornerstone and some of the work is handed off to WordPress.

Administration Menus

One of the main changes to WordPress’ custom post type functionality in 3.0 is that management functionality can now be automatically setup for each custom post type.  Simply put, each custom post type now has a section in the admin menu with functionality to manage, edit, and add new items of the custom post type.  Registering each content type with WordPress (using the same register_post_type() call as above) handled this, and I was able to offload a bunch of custom functionality in Cornerstone onto WordPress itself.

Content Item Management

WordPress now handles listing all custom post type items, so displaying all items with a custom post type was fairly straightforward (it mostly consisted of me removing my custom handlers for this functionality).

In my custom implementation, all content items (e.g. posts) with custom content types were still identified as posts in the database as WordPress’ custom post type functionality had not been completely integrated into the core prior to 3.0.  Instead, the custom type of a content item was saved as post metadata, which I felt was safer since I wasn’t sure how things would be changed in later revisions of the custom post type functionality.

Tomorrow

1. Including items with custom content types in default post query

   In 3.0, items with custom post types are not retrieved in standard post queries, meaning that they would not be displayed inline with other posts when content items chronologically (e.g. as in a blog).  The primary purpose of custom content types in Cornerstone is to allow different content items to contain specific metadata fields based on their content type.  This means that they should also have the option to be included in the standard post listing on a blog, so I’ll probably have to hook into the queries to make sure items with custom post types are included in the default post query.

2. Global edit form functionality

   Also, since all content items were basically still defined as posts as far as WordPress was concerned pre-3.0, it was easily possible to assign new functionality to the post edit form that would show up when creating/editing items regardless of content type.  I will have to look into this a bit to determine what best way to add functionality (e.g. extra meta boxes) to the edit form for all items regardless of content type.

Cornerstone: Content Types in WordPress 3.0 was originally published on Archetyped on July 28, 2010 10:42pm

Cornerstone transforms WordPress into a full-fledged Content Management System.  Say adios to the hacks and tricks used to shoehorn your posts into something that resembles a non-blog site and say hello to content management simplified.

Key Features

Structure

Using categories as pseudo sections to organize your posts?  No longer!  Pages are WordPress’ rightful sections and adding a post to a section is now as simple as selecting a page from a drop-down list while editing a post.

Benefits

• Canonical & logical permalinks – Posts are in a single section, and that’s how it should be.  WordPress ensures that every piece of content on the site has a canonical URI (a single URI for the content).  Cornerstone makes this URI logical so that you can tell where in the site’s structure (i.e. the section) the post is located at a glance, not what category it’s in or what year it was written in.
• “Hackable” site structure – the URI for a piece of content should represent the location of the content in the site’s structure.  For example, given the following URI:

  http://mysite.com/awesome/content-item

  With only a glance at the URI, we know that content-item is in the awesome section of the mysite.com website.  In the same way, this URI is “hackable” in that we can effectively navigate through the site’s structure by removing parts of the URI.  For example, to navigate up to the parent section, we just remove content-item from the URI and load the new URI to navigate to the awesome section.

Enhanced Content Metadata

Add preset form fields to enter metadata based on post type.  Manually creating and editing custom fields for each post is a thing of the past!  Easily enter and manage additional metadata for a rich content website (e.g. CRM, real estate listings, etc.)

Benefits

• Optimized productivity – Drag and drop creation of metadata fields for different post types.  Add fields once and they will be accessible whenever creating/editing a post.
• Customizable – Create new fields composed of multiple sub-fields (e.g. Address field contains sub-fields for Street Address, City, State, and Zipcode).  Customize the layout of fields on the edit form and how their data is used in themes.

RSS Everywhere

Allow users to subscribe to your site’s content with more flexibility.  In addition to WordPress’ standard RSS feeds, visitors can now also subscribe to updates in the following ways:

• Content in a section
• Content in a section by tag
• Content in a section by category

Site Customization

Various options and features to let you customize and personalize your site.

Examples:

• Enhanced Page Title – Automatically format title based on page type (home, archive, search, etc.)
• Featured Content – Select a category that will be used to define featured content to be displayed prominently on your site

Cornerstone was originally published on Archetyped on July 27, 2010 06:26pm

I spent some time yesterday working out the specifics of storing connections between content types and connections between different items (posts) and I’m pretty happy with the result.

An example of how connections can be useful:

Say you have 2 content types:

1. Recipes
2. Ingredients

Of course, all recipes must contain ingredients, so we need to tell the CMS that these two content types are connected. We can also define the type of connection between these items (“One to One” or “One to Many”).

• One to One: One item of one content type can connect to one item of another content type
• One to Many: One item of one content type can connect to several items of another content type

Will a recipe need to connect to just one ingredient, or will it need to connect to several? In this case, we would want to be able to connect a recipe to several ingredients, so we’re going to create a One to Many relationship between Recipes and Ingredients.

Now, when I’m adding a new recipe, thanks to the connection between these two content types, a list of ingredients will be displayed in the form to select ingredients that the recipe uses. Since this is a One to Many relationship, each ingredient has a checkbox next to it so that I can select multiple ingredients from the list. If it were a One to One relationship, the ingredients would be displayed as a drop-down list, which would only allow for one ingredient to be selected.

I really like the possibilities of this feature, but I think the goal now is to make it usable. In my opinion, it’s quite powerful as a feature, but it’s also somewhat abstract. So I’ve got to find a way to make it instantly clear how this feature could be useful to a user.

WordPress as CMS – Making the Connection was originally published on Archetyped on February 3, 2007 11:03am

The idea is simple: Select a content type, and the additional form fields for that content type appear below the main form.

Today, I built a working example of just that. Most of the work now will go into making this functionality more robust and flexible.

WordPress as CMS – Dynamic Forms was originally published on Archetyped on January 23, 2007 11:51pm

At the moment, I’m working on determining the best way to define a Content Type and its options in the database. Some types of content will use data from wp_posts along with data from other tables (joins), while others will be totally separate, so it’s important that the definition format is robust enough to handle all sorts of types. From there, the next step is to implement that format so that I can easily (and efficiently) pull all data (including custom metadata from other tables) for a post (or group of posts).

WordPress as CMS – Content Types was originally published on Archetyped on January 19, 2007 02:35pm

• Media files generally need to be uploaded to the server
• They can be embedded in other content (posts)
• They require specific markup to be displayed

It is because of these special characteristics that content types classified as media are not treated the same as other content types. For the most part, media will be added when adding another content type (an mp3 for a podcast, a thumbnail image for an article, etc.). Nonetheless, they are still treated as a separate content item (which means that they may be selected and embedded in any other content item as well).

Some differences regarding how media items are handled:

• Upload Capability – Media files may be uploaded
• File Organization – Media files are saved into directories based on file type
• Embed Media in a Post – Media can be easily added to a post by clicking an “Insert Media” button, viewing a gallery of media items (sortable and filterable), and selecting the media item(s) to insert.
• Automatic Media Viewers – When a media item is displayed, it is automatically wrapped in a the proper markup to allowing viewing. For example:
  • Images (gif, jpg, png) are wrapped in <img> tags
  • Flash Videos (flv) are wrapped in a flash video player
  • Mp3 files are wrapped in a flash-based audio player

  The nice thing is that these viewers are simply the default templates defined for each of the content types. This means that:

  1. Viewers can be easily modified
  2. Default viewers can be easily overridden via a template for further customization

Adding new media types is as simple as adding any other content types (define the characteristics of the media type, create default viewer template, and you’re done).

Personally, I like the automatic viewers for displaying media the most. This relieves template creators from having to do this task, and all they have to do is add a simple template tag (show_media(), for example).

WordPress as CMS – New Features Part 2: Media Management was originally published on Archetyped on November 26, 2006 04:37pm

There are several little enhancements and optimizations all over, but there are two new features that I believe have the most impact:

Content Types

Different types of content have different attributes. While most content types share some attributes (i.e. title, main content text, categories, etc.), they often diverge from each other in their “supporting” attributes (aka metadata). In the case of Cinema Paradise, a film would have a certain set of metadata (director, length, country, etc.), while an event would have completely different set of metadata (time/date, location, etc.).

For a site needing to manage several different content types, there are two important questions:

• How is the metadata added to a post (and how is it stored)?
• How is the metadata displayed?

Adding metadata to a post

Generally, additional metadata is added to a post via custom fields and stored in the wp_postmeta table. When you write a new post, simply fill in the appropriate custom fields (or add new ones), and you’re good to go. This is fine for blog sites (where blog posts are the only content type), but for a content-heavy site where several different types of content are added regularly (articles, blog posts, etc.), this just isn’t acceptable. Not only would a large list of custom fields be disorganized and hard to manage, but on a site with multiple users (each of whom may only need to work with certain content types), there is a good chance that mistakes will be made (e.g. typing metadata into the wrong custom field, etc.).

To make the creation and management of different content types simple and effective, the following functionality was (or will be) introduced into the plugin:

• Add new content types

Users are able to create new content types and define its attributes. For each attribute, users may define the different characteristics such as data type, default values, etc. Some examples of data type are:

• Date
• Address
• Phone Number
• Database Lookup – (Creates a drop-down list of values fetched from the DB. Used mostly to create relationships with other content types)
• File Upload – (image/video uploads, etc.)

The order and layout of the content type’s attributes can also be set.
As an example, three content types from the Cinema Paradise site were “Director”, “Film”, and “Event”. Here is a breakdown of each content type:

Director

• Name – Plain Text
• Country – DB Lookup (List of Countries)

Film

• Title – Post Title
• Description – Post Content
• Country – DB Lookup (List of Countries)
• Director – DB Lookup (Items matching “Director” content type)
• Genre(s) – Post Categories

Event

• Event Title – Post Title
• Event Description – Post Content
• Start Time – Date
• End Time – Date
• Location – DB Lookup (Items matching “Location” content type)
• Select content type for a post

Once a content type has been created, it may be selected from a drop-down list in the Write Post form when creating or editing a post. When a content type is selected, a form containing a field for each of the content type’s attributes will appear below the post content text box. The user can then fill in this form with the appropriate metadata.

Each field in the form is not just a simple text box either. A specially formatted form field will be displayed depending on the data type for each attribute. For instance, a date field will have a field where a date (month/day/year) may be entered, along with a popup calendar for quick and easy date selection, and an address data type will have text fields for Street, City, State, Zipcode, and Country data to be entered.

This makes it simple to enter metadata for different content types, and because only the form fields necessary for that content type are displayed, the likelihood of user-error is greatly minimized.

A note on metadata storage

For the first implementation of this feature on Cinema Paradise’s site, a new table is created for each content type. Since there were a finite amount of different content types to manage, I felt this was the best solution (faster/more specific queries, etc.). However, I am currently reevaluating the implementation of how metadata is stored to best accommodate the creation of an unlimited number of different content types.

Displaying metadata for a post

Template Hierarchy

Once a post has been assigned a content type, the focus now moves onto how to display this extra data. First, when creating a new content type, a default template may be defined. This template will be used if no templates have been set for a content type in the template directory. If a template for a content type has been defined in the template directory, it will override the default template. Currently, content type templates are defined by creating a file with the same name as the content type (this may change in the future to better differentiate content type template files from other template files). Furthermore, content type templates may be defined on a per-section basis. This means that content of a specific type (e.g. an article or an event) can be made to look different from one section to another. Again, if a section-specific content type template is present, it will override both the global content type template file and the default content type template (only for posts in that section, of course).

Custom Template Tags (Conceptual)

Currently, metadata may be displayed simply by inserting $post->attribute-name into a template. This works and is quite simple, but I would like to align the display of a post’s metadata with the main data of a post which can be displayed using template tags such as the_title(), the_content(), etc. So for an event, a user could create template tags such as event_location(), event_start(), and event_end().

Honestly, I don’t know whether this is practical to implement, or if it is even possible. I need to look into this more.

WordPress as CMS – New Features Part 1: Content Types was originally published on Archetyped on November 26, 2006 02:52pm