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
- 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.
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
developvia 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
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.
- Project Status
- Fork-First Policy
- Changelog
- Current Status
- Features
- Installation
- Fork Development Workflow
- Quality Gates
- Design Decisions
- Template Functions
- REST API
- WP-CLI
- Email Notifications
- Accessibility
- Security, Privileges, and Privacy
- Contributing
- Team
- License
- Alternatives
Fork development history is tracked in CHANGELOG.md.
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_authorsynchronization first, then HTML structured author metadata and implementation guidance.
- 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.
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
- 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(copytests/.env.distfirst if needed) - For repo-owned local browser/manual environments (
wp-envsingle-site,wp-envmultisite, and Playground), see docs/testing-environments.md - Start the dev server:
npm run start
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.mdfor upstream submission constraints and PR hygiene.
Fork-local quality gates currently used before handoff:
composer test:integrationWP_MULTISITE=1 composer test:integrationcomposer analyse:phpstancomposer analyse:psalmcomposer lintnpm run lint:jsnpm run test:js -- --cinpm run build
Coverage gates used in build slices that change thresholds or coverage policy:
composer test:coveragenpm run test:js:coverage
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:
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
authorshipfield on thewp/v2/postsREST API endpoints - Ability to create guest authors via the
authorship/v1/usersREST API endpoint - Read-only access to users who can be attributed to a post via the
authorship/v1/usersREST API endpoint - Ability to specify attributed authors when creating or updating posts via WP-CLI with the
--authorshipflag
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.
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_Userobjects - 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
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
The following REST API endpoints and fields are available:
This endpoint allows:
- Searching all users who can be attributed to content
- Creating guest authors
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 scopenetwork: 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.
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.
Authorship implements a custom flag for use with posts, and migration commands. The following WP-CLI flags are available:
--authorship
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,11wp post update 220 --authorship=13
If this flag is not set:
- When creating a new post, if the
--post_authorflag is set then it will be used for attributed authors - When updating an existing post, no change will be made to attributed authors
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=trueThe 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.
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=trueThe 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.
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_secondsfilter- Parameters:
(float $pause_seconds, string $migration, array $assoc_args) - Return a numeric pause value in seconds.
- Parameters:
authorship_migrate_batch_pause_resolvedaction- 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.
- Parameters:
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.
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 (
Spaceto 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.
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
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.
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.
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.
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_userscapability, which only Administrators do - A user role cannot be provided, it is always set to Guest Author
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_postscapability of the post type by default
create_guest_authors- Used when creating a guest author
- Maps to
edit_others_postsby default
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.mdwhen 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.
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:
- Land the change on fork
developfirst. - At an explicit packaging checkpoint, cherry-pick eligible commits into a separately scoped upstream PR.
- Upstream PRs must be independently mergeable against upstream CI and meet upstream's PHP/WP baseline.
- Fork delivery is never blocked on upstream review or acceptance.
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.
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.
If the Authorship plugin doesn't suit your needs, try these alternatives:


