What are the WordPress customizations for WikiTribune?

Ha! So I’d completely forgotten about WikiTribune, and reading an article there today, I was impressed by how “wiki-fied” they made WordPress.

Unfortunately, I can’t find any sources for the configuration or plugins used. It would be super helpful! So here are things they do I like, and speculation on how it works:

  • Multiple contributors for content - could be done with Co-Authors Plus, though maybe they created a new system.
  • History view - I believe these are just embedded WordPress revisions, which is clever. I’ve always like revisions, though the near ubiquitous advice is to disable them, or purge them regularly. I personally like having a history for a piece of content.
  • “Talk page” - I think they are just comments, but embedded rather than output in post. I’ve considered using Edit Flow editorial comments in this way, though a wiki site doesn’t really need to hide anything.
  • Post status - Speaking of editorial, the guide for adding/editing stories indicates the use of standard or custom post statuses.
  • Merging changes - I’ve seen this functionality in a variety of plugins and systems, but nothing approaching the flow seen in dedicated wiki software. A notable example is VersionPress. I don’t really know the best in class for this feature.

I’ll update this as I notice other things. I’d love to get a list of changes, and any plugins they use, so if someone know the folks building these components, let me know!


Oh yeah, all the embedded feeds, like revisions and comments, I would store them in Elasticsearch. That way you build an index that performs really well, without clogging up the main database with operations, while stile having decent caching and purging.

I’d love to know this too. I haven’t been able to find any info on the site eg at https://www.wikitribune.com/project/feedback-on-everything-please/ or 5 easy ways you can help WikiTribune – WikiTribune or the obvious question answered when asked eg reddit: the front page of the internet

One company that built some of their tools said they’ll be open sourcing plugins “in the near future”.

Development of editorial tools for a collaborative news platform:

WikiTribune is a WordPress website, and much of the CMS’s designed functionality had to be changed extensively to make WikiTribune’s editorial features possible.

For example, by default, WordPress locks Posts so that only one user can edit at a time (precisely in order to avoid edit conflicts); it has a revision and diff system, but taxonomy, featured images and custom metafields aren’t managed by the system; its diff tool normally only shows code, not the end result (making it inefficient for non-coding editors, and masking some visual-only issues that risk going live unchecked); it has a “draft > published” workflow, but once content has been published, all subsequent updates (by any user) go live, without editorial approval.

The editorial WordPress plugins we developed for WikiTribune will be made open-source in the near future.

1 Like

Two of the WikiTRIBUNE WordPress plug-ins were since released on Github.

Details: Arming WordPress for a post-truth era

1 Like

Thanks for the heads up, @jetatomic!

They actually extended the revision system!

WordPress plugin that enables updates to published content to be held in a draft state, or to be submitted for moderation and approval before they go live. It makes WP’s native Revisions more accountable by extending the system’s tracking of changes to taxonomy items and featured images, and improves the ‘Compare Revisions’ interface.

Because WordPress performance always has a strong caching element, the taboo against using revisions will hopefully lift. The one thing I wonder about is for a site like WikiTribune, they must get an inordinate amount of revisions, as it is the default editorial model. That means they should be bumping into some limits with their database, but who knows if it will ever really matter? When I host WordPress sites, regular visitors are never interacting with the database, everything is optimized to be served as fast as possible, including search.

My point is, maybe we ought to start keeping all revisions in WordPress, and exposing that data in more interesting and useful ways for site visitors. I encourage this even as I know it won’t be widely adopted, because it isn’t a matter of technology, it’s marketing. Folks don’t want others to see their mistakes, or that they keep regurgitating the same content year after year. Revisions get no love!

This was the first item on my speculation list as it was the most interesting to me: how do you get multiple folks editing at the same time?

Plugin to make WordPress more Wiki-like by allowing more than one person to edit the same Post, Page, or Custom Post Type at the same time. When there are conflicting edits, it helps users to view, compare, and merge changes before saving.

There is so much to check out about this plugin! First, note this important note:

FCE’s collaborative editing model is not Google Docs -like; users do not see what each other are typing in real time, but can work and concentrate independently. This also allows for a greater scale of collaboration. Furthermore, each users saved edits create Post Revisions, which makes editing more accountable and less subject to error or misuse.

So it is like MediaWiki, and I gotta say, that’s pretty awesome! And it wasn’t a small feat, if you look at their “features and functionality” list, they make use of the heartbeat API, transients API, and revisions, while adding a lot of functionality to make it a seamless experience for users. Well, presumably; I have a couple of project to finish up before I’ll get to play around with these.

Being able to edit content in that way, I think a lot of my collaborators would love that functionality, but have always been aware it wasn’t something baked into WordPress. So instead: Google Docs. Except again, no one is using it for that real-time editing experience, it is merely because you get edit-locked in WP.

Given that all this stuff is front-end editor stuff, I would hope there is now a niche for more collaborative editor experiences. Now we just need to figure out how it works with Gutenberg