Tag Archives: post types

John Blackbourn 4:49 pm on September 15, 2015
Tags: , , post types   

Enforcing the show_ui argument for post types

Since [34177], the show_ui argument for post types is now enforced to correct unexpected behaviour whereby the post type listing screen and post editing screen for post types with show_ui set to false were still accessible via a manually entered URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org.

There’s a small chance this may have an effect on your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or website if it’s relying on the fact that these screens were accessible. If this is the case, you should correct the arguments for your post type by setting show_ui to true, and then setting show_in_menu, show_in_nav_menus, and show_in_admin_bar to false, as appropriate.

#4-4, #dev-notes, #post-types

Mel Choyce-Dwan 8:35 pm on July 6, 2015
Tags: , , , post types   

Comments are now turned off on pages by default

In [33041] and [33054] for #31168, we’ve turned comments off on new pages by default.

I know many of you have done the “make a bunch of pages, fill them out, realize comments are turned on, go back into the adminadmin (and super admin), turn off comments” dance. Now when you make a page, you won’t have to manually turn off comments — it’ll match the expected behavior of being off by default.

In addition to pages, this functionality has been extended to all custom post types. Post registrations that don’t explicitly add support for comments will now default to comments being off on new posts of that type (before, they defaulted to on). Up until now, post type support for comments has only affected admin UIUI User interface; a developer could omit comment support on registration but still allow comments to be posted. This is a change in behavior, and we will be closely monitoring its effects during betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.. Moving to explicit support will allow coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. behavior to be more predictable and robust in the future, but we will always consider real-world usage.

In trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., you’ll notice two new things: the get_default_comment_status() function, which accepts the post type and comment type as arguments (both optional), and within it a get_default_comment_status filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., which receives the status, post type, and comment type as arguments. If you’ve been directly checking options such as with get_option( 'default_comment_status' ), you will likely want to replace those calls with get_default_comment_status(). We recommend explicit registration of post type support for comments, but as an example of using the filter, you can restore current behavior using the following:

/**
 * Filter whether comments are open for a given post type.
 *
 * @param string $status       Default status for the given post type,
 *                             either 'open' or 'closed'.
 * @param string $post_type    Post type. Default is `post`.
 * @param string $comment_type Type of comment. Default is `comment`.
 * @return string (Maybe) filtered default status for the given post type.
 */
function wpdocs_open_comments_for_myposttype( $status, $post_type, $comment_type ) {
    if ( 'myposttype' !== $post_type ) {
        return $status;
    }

    // You could be more specific here for different comment types if desired
    return 'open';
}
add_filter( 'get_default_comment_status', 'wpdocs_open_comments_for_myposttype', 10, 3 );

#4-3, #comments, #dev-notes, #post-types

Andrew Nacin 2:26 am on July 28, 2013
Tags: post types, ,   

Potential roadmap for taxonomy meta and post relationships

In the days before the WordPress Community Summit in October, a number of contributing developers huddled together to discuss a number of long-term architecture ideas. Among them were taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. and post relationships. (Ah, I see I now have your attention!) This post is more or less a proposed roadmap. It’s an ambitious plan that is designed to take place over perhaps five or more releases.

(During WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. San Francisco’s keynote, @matt talked a little about a new aim to build teams of contributors and reviewers around individual coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. components. There will be a lot more on that in the coming days and weeks. For now, here’s a post that covers two components, post types and taxonomy.)

The discussion included all core committers at the time — @ryan, @markjaquith, @westi, @azaozz, @nacin, @dd32, @koopersmith, and @duck_ — and a number of contributing developers, including @aaroncampbell, @dh-shredder, @helen, and @scribu.

At the moment, terms are represented in WordPress using two different IDs: a term ID, and a term taxonomy ID. A term ID (and name and slug) can actually appear in multiple taxonomies, so to identify a particular term, you must have either the term ID and the corresponding taxonomy, or just the term taxonomy ID. This dates back to the original taxonomy schema in WordPress 2.3. At the time, the concept of “shared terms” seemed like it could be an important abstraction. Hindsight is 20/20, and shared terms are the bane of taxonomies in WordPress.

So when we talk about term meta, we’re actually talking about term taxonomy meta — meta associated with a term taxonomy ID, not a term ID. The problem is, the public ID used in the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. and elsewhere is the term ID (and, by necessity, a taxonomy is also passed). This confusion — and the need for there to be only one object identifier in our metadata API (term taxonomy ID, not two, as in term ID and taxonomy) — has long forced us to table the discussion of term metadata.

(There are separate conceptual issues here — at what point does a term with metadata simply become a post-like object that can relate to other posts? And given post relationships, could terms and posts actually converge in their underlying schema? I’m not actually going to answer those questions in this post. Purely talking schema and architecture at this point.)

At WordCamp San Francisco last year, four of us — me, Gary Pendergast (@pento), @scribu, and @koopersmith — came up with a rather crazy way to make major changes to our table schema while still being backwards compatible. In fact, we came up with two ways to do it. This was the plan everyone heard and discussed at the summit.

It was clear that shared terms had to go. The first step is removing a UNIQUE index on the slug field in the wp_terms table. (This is dependent on #17689.) Then, we stop creating new shared terms. Step three, on an upgrade routine, we actively look for any existing shared terms and split them.

These three initial steps must happen over two to three major releases, as we’re talking about a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fix, a schema change, an API change, and an upgrade routine — in that order.

Then comes the fun part, in yet another major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.. With shared terms split, term ID and term taxonomy ID will be identical  on every install.  If we moved the slug and name fields from wp_terms to wp_term_taxonomy, we could actually drop wp_terms.

How can we remove an entire table but still be backwards compatible? We came up with two solutions:

  1. Because all fields in wp_terms will exist in wp_term_taxonomy, wp_terms can be recreated as a MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. view to be a read-only mirror of term data, thus being compatible with all existing queries.
  2. Because all fields in wp_terms will exist in wp_term_taxonomy, and because table aliases like `t`and `tt` are always used when joining these two tables, $wpdb->terms can simply be set to $wpdb->term_taxonomy. A query that previously joined wp_terms with wp_term_taxonomy would just join itself.

In all: Using the second approach (yes, it works), it took about 20 lines of codeLines of Code Lines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses. to make WordPress run without a wp_terms table. Wow, right?

So by this point, we would finally have a sane taxonomy schema. Less joins, a cleaner API (probably helped by a new WP_Term object to model WP_Post and WP_User), no more shared terms headaches, and a single, sane ID for a single taxonomy’s term.

Once that is all finished, we can finally have term meta. Maybe. (Kidding. (Kind of.))

Where do post relationships come in? The existing Posts 2 Posts pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party by @scribu is fantastic and serves the niche well. But we’re not really comfortable making any architecture or API changes along these lines while our taxonomy schema is still in a far from ideal state.

The post relationships plugin supports posts to posts, and posts to users. Core taxonomy relationships supports posts to terms, but it can also be rigged to relate users to terms. (It also supported links to terms, yet another object type.) We didn’t fully iron out this idea yet, but one idea is to convert the current wp_term_relationships table to a more generic object relationships table, which can support posts to posts, posts to users, terms to users, and of course posts to terms (and, really, any arbitrary relationship).

A disclaimer: This post doesn’t promise anything. Do not rely on the contents of this post for future projects.  It will take us some time to lay out the proper groundwork and make sure we get this right. Do not expect this to happen in WordPress 3.7, or even 3.8. (Actually, do not expect this to happen at all.)

That said, I’m really glad to get this information out there and I’m excited to hear any feedback you may have. We are always thinking toward the future, and a lot of contributing developers have mile-long roadmaps in their heads — it’s long past time to get those on paper.

#post-types, #roadmaps, #taxonomy

Andrew Nacin 5:40 pm on September 13, 2010
Tags: post types   

CPT enhancements

I’m trying to put together a small but well-defined set of enhancements that custom post types deserve consideration in 3.1.

What I have so far is this:

  • Opt-in archive/index pages for custom post types
  • Opt-in default metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. capability handling for custom post types
  • Improve the custom post status APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., and make them type-specific

Beyond that, I’m also thinking about opt-in ways to get more than the default post types displayed on other views. As it is now, we currently also allow searching for pages for example, so we would more or less be extending that. You may want to allow a post type to show up on the categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. or tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) pages, for example. The API ideally wouldn’t be more complicated than, say, register_taxonomy_for_object_type.

What are your thoughts? Let me know your pet bugs, peeves, and workarounds. (Just keep in mind we’re aiming for small, defined scope here. KISS.)

#post-types