Introducing NC State Protected Content

Suppose you have a page in your WordPress website that should be publicly available, but whose contents should only be read by a particular campus audience—say, you have something that should be available for faculty and staff at NC State but not students or the general public.

Out of the box, there’s not an easy way to do this. The content visibility functionality built into WordPress allows for private publishing, but doesn’t distinguish between groups of users. And while many access management plugins exist, asking site owners to maintain redundant user lists is burdensome, especially when the university already maintains those lists.

So we wrote our own plugin: NC State Protected Content. I completed the first effort when we relaunched the OIT website in WordPress. Looking ahead to the soon-to-relaunch Software Licensing website and their needs, my colleague Chris Deaton rewrote the plugin this summer to make it more fully-featured and adaptable. We’re now ready to release it to the rest of campus.


We use the NC State Multiauth plugin with auto-account creation enabled.
We use the NC State Multiauth plugin with auto-account creation enabled.

NC State Protected Content assumes your website is using Shibboleth authentication, and that your users have accounts to log into WordPress. When a user logs in to view a password-protected page, the plugin’s first step is to check against their Shibboleth credentials.

In the OIT site, we use the NC State Multiauth plugin built by our friends in ITECS configured with NC State Account Auto-Creation enabled. The default role for every new user is Subscriber.


When NC State Protected Content is activated, a “Protect Content” metabox is added to every page in WordPress. Check the “Enabled?” checkbox to turn on password protection for the page you’re working on, and you’re prompted with two fields: “Show content to…” and “Unity IDs.”

Animated screenshot of the Protected Content metabox

Show content to… gives you a Select2 select box to choose from the following options:

  • Basic – Shibboleth user affiliations member (anyone with a Unity ID and password), studentfaculty, and staff
  • WordPress Role – Default WordPress user roles
    • Note that we have made these WordPress roles inheritable. That is, if you want to provide access for AuthorEditor, and Administrator users, it’s not necessary to select all three roles. Selecting Author will provide access to higher-level roles as well.
  • Employee Type – User data in the employeeType field of the campus LDAP database

If you are password-protecting a page for some subset of users that isn’t captured with these options, the Unity IDs field accepts a comma-separated list of usernames.

If any one of the options you select is present for the user logging in, or if the user’s Unity ID is in your comma-separated list of IDs, then the page content is displayed for that user. If the user logging in doesn’t match any of these criteria, a “not authorized” message is displayed.

Child Pages

Child pages automatically inherit the protected content settings of their topmost ancestor, eg.

top level page (set to editor only)
-- child (editor only)
-- child (editor only)
---- child (editor only)

This can be overridden on a per-page basis.


Clients of OIT Design who are interested in using the NC State Protected Content plugin on their websites should contact us, and we will take care of the rest.

For anyone else on campus interested in using it, we recommend installing it via GitHub Updater rather than downloading it from the Protected Content GitHub repository. As we continue to develop the plugin, this will ensure you are notified of updates in WordPress. (Since we use GitHub Updater for all of our projects, we have more detailed instructions for new users.)

Contributing to This Project

We invite any campus web developers interested in helping build out additional features or troubleshoot bugs to make contributions to the plugin’s GitHub repository. And if you find any unexpected behavior, be sure to post an issue in GitHub as well.

Long-term, we have aspirations of protecting content by membership of a Google Group (eg. members of group-oitdesign would be able to view a page). I think we have a rough sketch of what that might involve, but it would be a bigger project than we’re ready to take on at this time. So your contributions are welcome and encouraged!