by Jeff Eaton on March 18, 2013 // Short URL

Module Monday: Custom Publishing Options

All Drupal content types inherit a few basic flags that can be used to control their behavior. Is this piece of content published? Is it promoted to the front page? Is it 'sticky,' and bumped at the top of lists it appears in? Those are all useful, but complex sites inevitably need more (or different) flags to control the behavior of content in complex designs and workflows. Fortunately, the Custom Publishing Options module can fill the gap.

Screenshot of administration screen

As one might guess from the name, site builders can use the module to add custom publishing options to any content type. These options are simple boolean flags (like 'breaking news' or 'not for syndication') that appear alongside Drupal's default publishing options on node edit forms. These flags can then be used to filter and sort content in custom Views, and the setup information can be captured in exported Feature module configuration collections for easier reuse and deployment.

Screenshot of resulting change to site

In theory, site builders can duplicate this functionality using boolean FieldAPI fields. That approach requires additional tweaking to avoid the displaying the flags as part of the node's actual content, however, and can be tricky to layer on top of already-existing content types in a Feature. Custom Publishing Options also takes the unorthodox step of adding its flags to the standard node table in the database, rather than a separate side table. While tweaking the node table directly is rarely a good idea, this module does it the "right" way, implementing the hook_schema_alter() function to ensure that all other Drupal modules are aware of its modifications. If you're looking to add simple flags to your content and want to ensure that they're stored and treated just like the "core" publishing options, check out Custom Publishing Options.

Jeff Eaton

Senior Digital Strategist

Want Jeff Eaton to speak at your event? Contact us with the details and we’ll be in touch soon.


Sinan Erdem

Which table?

I didnt have time to analyze or use the module yet, but if this module creates additional columns in the "node" table and keeps those flags in there (like the "published" or "sticky" flags), then it has a huge performance advantage over adding FieldAPI fields, because FieldAPI keeps the values in a new table. To use those field values in a view, for example, there should be made a JOIN operation, which is costly.



A topic of some debate...

That's a good point, and I've tweaked the article to highlight that fact. While modifying existing core tables is frowned upon, Drupal does provide an explicit API to manage such additions. As long as site builders are aware of the issue, it can provide some speed advantages over storing things in a separate table.



A topic of some upgrade

What is the likelyhood of such an altered node table ever upgrading to D8 smoothly? Smoothly here meaning, without me hacking into the database or writing custom sql.

Because those would be the main 'topic of debate' for me.

And of breaking another module of course.



D8 upgrades?

The likelihood is very high. The altered table wouldn't interfere with the D8 updates unless an actual column name collision occurs. Since D8 doesn't radically alter the structure of the node table itself, this should upgrade smoothly. Mind you, the Custom Publishing Options module would need to be upgraded to D8 in order to continue using the information stored in the custom columns, but that's true with any solution.


Kevin Quillen

D8 Upgrades

Hi all!

While at a glance it does appear that the module adds and removes its tables from the node table, it is doing so via the hook_schema_alter() function, along with db_add and db_drop when appropriate so it goes in and is removed cleanly. Last thing we'd want to do is muck up the node system. As the original commenter noted, it is highly performant over Fields, since it adds a field to the node table, instead of two new tables to the database for a Field, requiring a join.

As far as major version upgrade, hopefully by that point the Migrate framework will have a D8 release - which is how I do upgrades or migrations into Drupal as I have found it far easier than any other way. And along the way, a D8 release for CPO needs to happen, too.



Cleans up the node form

One thing I like about this module is that these flags appear on the same "Publishing Options" vertical tab as "front page" and "sticky" checkboxes, making a cleaner, more logical interface (since these things go together). If you add custom flags, by default they appear in their own "Flags" tab; getting them onto the "Publishing Options" checkboxes requires some significant code gymnastics.