WordPress includes a well-defined workflow for running a blog with multiple contributors in various roles. It works great; But what if you are using WordPress to run a 1,000 page hierarchical site? Well… the workflows available are a bit limited without getting under the hood. For example, WordPress does not define fine-grained capabilities for controlling who can edit published content. As a result, users have to be granted full editing permissions, which increases the chance that a less-experienced user will make an ill-advised change. Drawing from our experience running large Multisite installations, Boston University has developed a couple of plugins to address some of the limitations. And for the first time, we are planning to release our plugins to the broader WordPress community under the GPL.
This talk will include an overview of the role/capability system presented from both a user and developer perspective as well as overviews of the BU Versions and BU Section Editing plugins. Along the way, various insights will be shared that provide a window into how BU has built an effective content management system on top of WordPress.
5. A range of offerings:
1. Fully custom
2. Quick setup
3. DIY tools
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19. How many plugins does it take?
Main Main Integrated
Third-Party BU-specific w/ BU apps
Gravity Forms BU Navigation BU Calendar
WP SuperCache Access Control List BU Maps
(w/ Single Sign-on)
Akismet Google Search
User Management Appliance
Networks for (w/ Single Sign-on)
WordPress Course Feeds
Content Banner
Yet Another Related Training Manager
Posts Plugin Post Details
Emergency Alert
Advanced Tiny MCE
Site Manager
....
20. What makes large sites so difficult?
Lack of vision Search
Lack of Performance &
consistency Scaling
Lack of clear Complex
accountability workflows
Team dynamics Politics
and skill
21. What makes large sites so difficult?
Lack of vision Search
Lack of Performance &
consistency Scaling
Lack of clear Complex
accountability workflows
Team dynamics Politics
and skill
23. Design Goals»
+ Blend naturally into the existing WordPress
admin UI
+ Simple to use
+ Manage permissions with a full view of all post
content
+ Perform well on sites with more than 2,000
pages
+ Support custom post types
33. The history of a page
t ed e d
ea d lo
n te es
cr e c na rit
e ge lish e er rw al
p ag pa ub pag lt e n
a v i
p o rig
o
te
a d
rn ite
te ed
al
34. Roadmap»
+ Compare changes with original
+ Support cloning of meta data and the meta boxes
used to manage the data
+ Simple notifications
+ Support custom statuses
+ Preview all alternate versions as once (tricky)
45. Now accepting pull requests...
+ BU Versions
https://github.com/bu-ist/bu-versions
+ BU Section Editing
https://github.com/bu-ist/bu-section-editing
46. Contributors:
+ Mike Burns, developer
+ Sam Roach, UX designer
+ Scott Dasse, designer
+ Mike Waecker, project manager
+ Alex Haas, quality assurance analyst
49. Default Roles»
+ Administrator - Somebody who has access to all
the administration features
+ Editor - Somebody who can publish and manage
posts and pages as well as manage other users'
posts, etc.
+ Author - Somebody who can publish and manage
their own posts
+ Contributor - Somebody who can write and
manage their posts but not publish them
+ Subscriber - Somebody who can only manage
their profile
60. Limitations»
+ Capabilities are not stored separate from roles
+ Capabilities do not have labels or descriptions
+ No API exists for setting a capability to false;
remove_cap() deletes the capabilities making it
difficult to determine whether a capability was
removed or just was never added
Roles +
Capabilities
61. The value of open source
core
developer community
developer
62. "The foundation of open source projects is
rough consensus and working code"
—Jacob Kaplan-Moss
