Skip to content

dknauss/authorship

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

775 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Authorship (Fork)

License CI Latest Tag Security Policy Docs

A modern approach to author attribution in WordPress.

This repository (dknauss/authorship) is the active fork of humanmade/authorship and is operated with a fork-first workflow.

Stable tag: 0.3.0-alpha

Project Status

  • Canonical integration branch: develop (branch protection enabled)
  • Active release channel: Git tags + GitHub Releases from this fork
  • Upstream PRs (humanmade/authorship): minimized and optional
  • Upstream (humanmade/authorship): original source, not actively maintained
  • Requires PHP: 7.2+ (upstream baseline; fork CI gates on 7.4–8.4)
  • Tested up to: WordPress 6.6

For canonical branch/release policy, see docs/fork-first-policy.md.

Fork-First Policy

Nothing goes back to upstream (humanmade/authorship) by default. Upstream contributions are cherry-picked bug fixes and enhancements that can be backported to the original testing, standards, and PHP requirements. All development targets the fork first.

Mandatory rules:

  • All new work lands on fork develop via PRs with passing CI.
  • Upstream PRs are optional adoption paths — never delivery gates.
  • Do not open one upstream PR per incremental build slice.
  • Upstream submissions happen only at explicit packaging checkpoints.
  • Cherry-picked upstream PRs must be independently mergeable against upstream CI and standards.
  • Fork-local artifacts (.planning/, docs/audit/) are excluded from all upstream branches.

Canonical policy: docs/fork-first-policy.md

Description

Authorship supports attributing posts to multiple authors and to guest authors, provides a great UI, and treats API access to author data as a first-class citizen.

Authorship is currently geared toward developers who are implementing custom solutions on WordPress. For example, it doesn't provide an option to automatically display author profiles at the bottom of a post. In the future it will include wider support for existing themes and useful features for implementors and site builders.



Changelog

Fork development history is tracked in CHANGELOG.md.

Current Status

Alpha upstream product status. The fork has completed Phase 04 test-depth and ratcheting work and has now planned Phase 05 interoperability/compatibility hardening:

  • Phase 01 and Phase 02 are complete fork-locally.
  • Phase 03 Build-12 execution is complete fork-locally: VoiceOver add/remove/reorder pass is recorded; optional NVDA transcript capture is now tracked as backlog evidence (not a delivery gate).
  • Phase 04 is complete fork-locally across Builds 01-08: multisite coverage, hook/filter contracts, deterministic batching, PPA migration hardening, query semantics, user-deletion sync, coverage ratcheting, and attribution lifecycle observability hooks are all delivered.
  • Phase 05 is planned as the next execution lane: primary-author compatibility / post_author synchronization first, then HTML structured author metadata and implementation guidance.

Features

  • Multiple authors per post
  • Guest authors (that can be created in place on the post editing screen)
  • A convenient and user-friendly UI that feels like a part of WordPress
  • Works with the block editor
  • Works with the classic editor
  • Full CRUD support in the REST API and WP-CLI
  • Full support in RSS feeds
  • Full support in Atom feeds
  • Fine-grained user permission controls

Features without a checkmark are still work in progress.

Installation

For normal use

Clone or download from this fork:

git clone https://github.com/dknauss/authorship.git wp-content/plugins/authorship

Or, if your project uses Composer with a VCS repository:

composer require dknauss/authorship

For development use

  • Clone this fork into your plugins directory
  • Ensure you have Composer v2 and Node v20 installed
  • Install the dependencies: composer install && npm install
  • If you run integration tests, set credentials in tests/.env (copy tests/.env.dist first if needed)
  • For repo-owned local browser/manual environments (wp-env single-site, wp-env multisite, and Playground), see docs/testing-environments.md
  • Start the dev server: npm run start

Fork Development Workflow

The fork develops on develop and uses short-lived branch slices (for example codex/phase-03-build-*) for phased execution and review.

Recommended workflow in this fork:

  • Branch from develop.
  • Keep scope narrow and test-backed.
  • Open pull requests against fork develop.
  • Follow docs/fork-first-policy.md for upstream submission constraints and PR hygiene.

Quality Gates

Fork-local quality gates currently used before handoff:

  • composer test:integration
  • WP_MULTISITE=1 composer test:integration
  • composer analyse:phpstan
  • composer analyse:psalm
  • composer lint
  • npm run lint:js
  • npm run test:js -- --ci
  • npm run build

Coverage gates used in build slices that change thresholds or coverage policy:

  • composer test:coverage
  • npm run test:js:coverage

Design Decisions

Why another multi-author plugin? What about Co-Authors Plus or Bylines or PublishPress Authors?

Firstly, those plugins are great and have served us well over the years, however they all suffer from similar problems:

  • API: Lack of support for writing and reading author data via the REST API and WP-CLI
  • UI: Limited or custom UI that doesn't feel like a part of WordPress
  • Users: An unnecessary distinction between guest authors and actual WordPress users

Let's look at these points in detail and explain how Authorship addresses them:

API design decisions

There's a lot more to a modern WordPress site than just its theme. Data gets written to and read from its APIs, so these need to be treated as first-class citizens when working with the attributed authors of posts.

Authorship provides:

  • Ability to read and write attributed authors via an authorship field on the wp/v2/posts REST API endpoints
  • Ability to create guest authors via the authorship/v1/users REST API endpoint
  • Read-only access to users who can be attributed to a post via the authorship/v1/users REST API endpoint
  • Ability to specify attributed authors when creating or updating posts via WP-CLI with the --authorship flag

UI design decisions

We'd love it if you activated Authorship and then forgot that its features are provided by a plugin. The UI provides convenient functionality without looking out of place in the block editor.

User design decisions

Existing plugins that provide guest author functionality make a distinction between a guest author and a real WordPress user. A guest author exists only as a taxonomy term, which complicates the UX and creates inconsistencies and duplication in the data.

Authorship creates a real WordPress user account for each guest author, which provides several advantages:

  • No custom administration screens for managing guest authors separately from regular users
  • Plugins that customise user profiles work for guest authors too
  • Consistent data structure - you only ever deal with WP_User objects
  • No need to keep data in sync between a user and their "author" profile
  • Promoting a guest author to a functional user is done just by changing their user role

Template Functions

The following template functions are available for use in your theme to fetch the attributed author(s) of a post:

  • \Authorship\get_author_names( $post )
    • Returns a comma-separated list of the names of the attributed author(s)
  • \Authorship\get_author_names_sentence( $post )
    • Returns a sentence stating the names of the attributed author(s), localised to the current language
  • \Authorship\get_author_names_list( $post )
    • Returns an unordered HTML list of the names of the attributed author(s)
  • \Authorship\get_authors( $post )
    • Returns a list of user objects of the attributed authors
  • \Authorship\get_author_ids( $post )
    • Returns a list of user ids of the attributed authors

REST API

The following REST API endpoints and fields are available:

authorship/v1/users endpoint

This endpoint allows:

  • Searching all users who can be attributed to content
  • Creating guest authors

Multisite cross-site lookup mode (REST-only, opt-in)

By default, user lookups for authorship/v1/users are scoped to the current site (site mode). In multisite, this keeps attribution search local unless you explicitly opt in.

To enable network-wide user lookups for this endpoint, use the authorship_cross_site_mode filter and return network:

add_filter(
	'authorship_cross_site_mode',
	static function ( $mode ) {
		unset( $mode );
		return 'network';
	}
);

Supported mode values:

  • site (default): current-site user lookup scope
  • network: network-wide lookup scope

Current scope note: this mode applies to the REST user lookup surface (authorship/v1/users) and is not applied to non-REST query surfaces.

authorship field

This field is added to the endpoint for all supported post types (by default, ones which that have post type support for author), for example wp/v2/posts. This field is readable and writable and accepts and provides an array of IDs of users attributed to the post.

In addition, user objects are embedded in the _embedded['wp:authorship'] field in the response if _embed is set and the authenticated user can list users.

WP-CLI

Authorship implements a custom flag for use with posts, and migration commands. The following WP-CLI flags are available:

  • --authorship

--authorship flag

When creating or updating posts the --authorship flag can be used to specify the IDs of users attributed to the post. The flag accepts a comma-separated list of user IDs. Examples:

  • wp post create --post_title="My New Post" --authorship=4,11
  • wp post update 220 --authorship=13

If this flag is not set:

  • When creating a new post, if the --post_author flag is set then it will be used for attributed authors
  • When updating an existing post, no change will be made to attributed authors

Migration of WordPress authors on existing posts.

If you activate Authorship on an existing site, all content already created will not have authorship data set for old content. This breaks things such as author archive pages.

This command will set the WordPress author as the authorship user for any posts with no authorship user. (Optionally you can override any existing authorship data, updating it with the WordPress post author).

wp authorship migrate wp-authors --dry-run=true

The command will perform a dry run by default, setting --dry-run=false will make changes to the database.

This command will not overwrite or update Authorship data unless the --overwrite-authors=true flag is set.

PublishPress Authors Migration

Authorship provides a command for creating Authorship data using data from PublishPress Authors. This allows a non-destructive migration path from PublishPress Authors.

With both plugins active, this command will copy PPA data into Authorship:

wp authorship migrate ppa --dry-run=true

The command will perform a dry run by default, setting --dry-run=false will make changes to the database. Guest authors that do not exist as users will be created with blank emails and random passwords.

This command will not overwrite or update Authorship data unless the --overwrite-authors=true flag is set.

Migration pacing controls

Both migration commands support --batch-pause=<seconds> (default 2). Set --batch-pause=0 to run without intentional pauses between processed batches.

Authorship also provides hook extension points for migration pacing:

  • authorship_migrate_batch_pause_seconds filter
    • Parameters: (float $pause_seconds, string $migration, array $assoc_args)
    • Return a numeric pause value in seconds.
  • authorship_migrate_batch_pause_resolved action
    • Parameters: (float $pause_seconds, string $migration, array $assoc_args, int $count)
    • Fires after pause resolution and before optional sleeping for each processed batch.
    • Does not fire for batches that process zero posts.

Email Notifications

Authorship does not send any email notifications itself, but it does instruct WordPress core to additionally send its emails to attributed authors when appropriate.

  • When a comment on a post is held for moderation, the comment moderation email also gets sent to all attributed authors who have the ability to moderate the comment and have a valid email address
  • When a comment on a post is published, the comment notification email also gets sent to all attributed authors who have a valid email address

This plugin only adjusts the list of email addresses to which these emails get sent. If you want to disable these emails entirely, see the "Email me whenever" section of the Settings -> Discussion screen in WordPress.

Accessibility

Authorship aims to conform to Web Content Accessibility Guidelines (WCAG) 2.1 at level AA but it does not yet fully achieve this. If full support for assistive technology is a requirement of your organisation then Authorship may not be a good fit in its current state.

With regard to the author selection control on the post editing screen:

  • ✅ The visual styles are inherited from WordPress core and are WCAG 2.1 AA compliant
  • ✅ The control exposes an explicit programmatic label (Authors) and usage instructions
  • ✅ Add/remove/reorder actions emit live status messages (for example Added guest author..., Moved ... to position ...)
  • ✅ Keyboard reorder is supported (Space to pick up/drop, arrow keys to move) when a selected author token has focus
  • ⚠ Keyboard reorder discoverability still depends on users understanding token focus before drag commands
  • ⚠ Additional NVDA spoken-transcript evidence is backlogged (VoiceOver path is already recorded)

The team are actively investigating either replacing the component used to render the control with a fully accessible one, or fixing the accessibility issues of the current one.

Security, Privileges, and Privacy

Great care has been taken to ensure Authorship makes no changes to the user capabilities required to edit content or view sensitive user data on your site. What it does do is:

  • Grant users who are attributed to a post the ability to edit that post if their capabilities allow it
  • Grant users the ability to create and assign guest authors to a post
  • Allow this behaviour to be changed at a granular level with custom capabilities

Assigning Attribution

The capability required to change the attribution of a post matches that which is required by WordPress core to change the post author. This means a user needs the edit_others_post capability for the post type. The result is no change in behaviour from WordPress core with regard to being able to attribute a post to another user.

  • Administrators and Editors can change the attributed authors of a post
  • Authors and Contributors cannot change the attributed authors and see a read-only list when editing a post

Authorship allows the attribution to be changed for any post type that has post type support for author, which by default is Posts and Pages.

Editing Posts

When a user is attributed to a post, that user becomes able to manage that post according to their capabilities as if they were the post author. This means:

  • A post that is attributed to a user with a role of Author can be edited, published, and deleted by that user
  • A post that is attributed to a user with a role of Contributor can be edited by that user while in draft, but cannot be not published, and cannot be edited once published

From a practical point of view this feature only affects users with a role of Author or Contributor. Administrators and Editors can edit other users' posts by default and therefore edit, publish, and delete posts regardless of whether they are attributed to it.

Searching Users

The authorship/v1/users REST API endpoint provides a means of searching users on the site in order to attribute them to a post. Access to this endpoint is granted to all users who have the capability to change the attributed authors of the given post type, which means Editors and Administrators by default. The result is no change in behaviour from WordPress core with regard to being able to search users.

In addition, this endpoint has been designed to expose minimal information about users, for example it does not expose email addresses or capabilities. This allows lower level users such as users with a role of Author to be granted the ability to attribute users to a post without unnecessarily exposing sensitive information about other users.

In multisite, this lookup is site-local by default. A network-wide lookup mode is available only through the explicit authorship_cross_site_mode filter.

Creating Guest Authors

The authorship/v1/users REST API endpoint provides a means of creating guest authors that can subsequently be attributed to a post. Access to this endpoint is granted to all users who have the ability to edit others' posts, which means Editors and Administrators by default.

More work is still to be done around the ability to subsequently edit guest authors, but it's worth noting that this is the one area where Authorship diverges from the default capabilities of WordPress core. It allows an Editor role user to create a new user account, which they usually cannot do. However it is tightly controlled:

  • An email address cannot be provided unless the user has the create_users capability, which only Administrators do
  • A user role cannot be provided, it is always set to Guest Author

Capability Customisation

The following custom user capabilities are used by Authorship. These can be granted to or denied from users or roles in order to adjust user access:

  • attribute_post_type
    • Used when attributing users to a given post type
    • Maps to the edit_others_posts capability of the post type by default
  • create_guest_authors
    • Used when creating a guest author
    • Maps to edit_others_posts by default

Complementary Security and Audit Plugins

Authorship does not aim to be a complete security or audit platform by itself.

Recommended complementary approach:

  • Use WP Sudo to add reauthentication gates for sensitive operations in WordPress admin, AJAX, REST, and other request surfaces.
  • Use Stream or WP Activity Log (WSAL) for persistent audit trails and reporting.
  • Use Authorship hook/filter extension points for integration-specific logging behavior.
  • Use the observability hook contract spec in docs/audit/authorship-observability-hook-contract.md when implementing logging integrations.

Current policy direction in this fork: keep Authorship focused on attribution behavior and interoperability hooks rather than introducing a first-party audit log datastore/dashboard.

Contributing

Code contributions, feedback, and feature suggestions are very welcome.

All contributions target this fork (dknauss/authorship):

  • Open issues and PRs against fork develop.
  • Follow CONTRIBUTING.md from this repository.
  • Fork-local CI must be green before merge.

Upstream contributions are cherry-picked, not automatic. If a bug fix or enhancement is suitable for backporting to humanmade/authorship:

  1. Land the change on fork develop first.
  2. At an explicit packaging checkpoint, cherry-pick eligible commits into a separately scoped upstream PR.
  3. Upstream PRs must be independently mergeable against upstream CI and meet upstream's PHP/WP baseline.
  4. Fork delivery is never blocked on upstream review or acceptance.

Team

Authorship was originally developed and maintained by Human Made and Altis. Its initial development was funded by Siemens.

This fork is maintained by Dan Knauss for fork-first hardening and modernization work.

Human Made Altis DXP Siemens

License

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Alternatives

If the Authorship plugin doesn't suit your needs, try these alternatives:

About

A modern approach to author attribution in WordPress.

Topics

Resources

License

Code of conduct

Contributing

Security policy

Stars

Watchers

Forks

Packages

 
 
 

Contributors

Languages

  • PHP 82.4%
  • TypeScript 12.7%
  • Mermaid 2.1%
  • Shell 1.6%
  • SCSS 1.1%
  • JavaScript 0.1%