# Fieldmanager: a PHP toolkit for WordPress forms and admin screens > Fieldmanager is a WordPress plugin from Alley Interactive that provides a library for building forms, metaboxes and custom admin screens, so a plugin or theme does not have to hand-roll its own field types and save handling. The catch is that it is a plugin you install alongside your own, not a Composer dependency you require, and its licensing is not one GitHub can classify. **alleyinteractive/wordpress-fieldmanager** — Custom field types for WordPress - Repository: https://github.com/alleyinteractive/wordpress-fieldmanager - Stars: 564 · Forks: 99 - Language: PHP - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/alleyinteractive-wordpress-fieldmanager ## A library that installs as a plugin Fieldmanager is described as a comprehensive toolkit for building forms, metaboxes, and custom admin screens for WordPress, and it is the kind of library that saves a developer from writing the same field rendering, validation and persistence code once per admin screen. The installation model is the first thing to understand, because it is unusual for a library. The README says to download the plugin and install it into your plugins directory and activate it on the plugins screen. There is no Composer require line in the instructions, and there is no autoloader to wire up. Fieldmanager is a plugin in the WordPress sense: it lives in the plugins directory, it is activated, and it registers its own API for other plugins and themes to call. That design has a real consequence for a project that expects Fieldmanager to travel inside its own plugin bundle. If your plugin is distributed on its own, a user who installs it needs Fieldmanager present too, and the two are activated separately in the WordPress admin. For agencies that install one plugin into each client site it is manageable. For a plugin intended for the WordPress.org directory, bundling a second plugin under a different licence is a decision that has to be made deliberately. The API documentation lives at api.fieldmanager.org, the project site is fieldmanager.org, and there is a separate repository, fieldmanager-demos, which the README says illustrates a lot of what you can do with Fieldmanager. ## Versioning policy, and what the main branch means The versioning section is short and specific, and it is the sort of thing that is worth reading before pinning a version. The README says the main branch on GitHub is the bleeding edge release, and that as of 1.0 Fieldmanager will maintain a typical release cycle, with alpha, beta, and RC releases, and that the project hopes to move through minor versions pretty quickly. The recommendation that follows is unambiguous: while the project encourages everyone to develop with and test on early releases and help find the bugs, stable releases are recommended for production. That is a normal, careful policy, and it has a matching instruction for the reader. The official releases are on the GitHub releases page for the repository, and the tags follow a conventional version scheme, with the recent ones being v1.6.3 on 2026-08-12, v1.6.2 on 2026-05-15 and v1.6.1 on 2024-05-06. The gap between v1.6.1 and v1.6.2 is just over two years, which tells you the cadence is not a fixed schedule, and the last push to the repository was on 2026-08-12. The minor version numbers are worth reading as a signal. Moving through minor versions quickly is the stated intent, so a 1.6 to 1.7 jump is where behaviour changes land, and a project that depends on Fieldmanager needs to read the changelog for each minor rather than assuming a patch release is safe. ## The repository layout, and where the code actually sits The top level of the repository is small and readable. There is fieldmanager.php as the plugin entry point, a php/ directory holding the PHP source, templates/ for the rendered output, css/ and js/ for the assets, images/ for the icon and images, docs-src/ for the documentation sources, and a tests/ directory with a phpunit.xml at the root, which means the test suite is run with PHPUnit. There is also a .phpcs/ directory and a phpcs.xml, so the coding standard is enforced by a checker rather than by convention alone, plus an .editorconfig and a .gitattributes for line endings and editor behaviour. The presence of tests/ and phpunit.xml is the detail that matters most to a reader deciding whether to depend on this. A WordPress plugin that ships a PHPUnit configuration and a phpcs standard has a project structure built around verification, and a composer.json at the root gives the project a dependency manifest even though the README does not instruct a consumer to require it. The composer.json records the package name as fieldmanager, the version as 1.6.3, the repository type as git with the GitHub URL, and the license field as GPL-2.0. ```json { "name": "fieldmanager", "description": "Fieldmanager is a comprehensive toolkit for building forms, metaboxes, and custom admin screens for WordPress.", "version": "1.6.3", "repository": { "type": "git", "url": "https://github.com/alleyinteractive/wordpress-fieldmanager" }, "license": "GPL-2.0", "devDependencies": {} } ``` The devDependencies object is empty, so the test and lint tooling is not managed by Composer even though a composer.json is present. That is worth noticing for anyone who assumed composer install would set up a development environment. ## Building the API documentation, which is the only documented developer workflow The README documents one build command, and it is the one a contributor will actually run. Building the API documentation, whose latest version is published at api.fieldmanager.org, requires ApiGen to be installed, and once that is present the entire documentation tree is generated with a single command using the configuration file in the repository root. ```bash apigen -c apigen.neon ``` The configuration file apigen.neon is at the top level of the repository, and the docs-src/ directory is the source it draws from. ApiGen is a PHP tool that reads source and emits reference documentation, and the neon format is its configuration syntax. A contributor who wants to see the current API surface locally installs ApiGen, runs that command, and gets the same tree that is published on the site. The contribution process itself is minimal in the README: development happens on GitHub, bugs go in the issue queue, and enhancements or bug fixes are submitted as pull requests, which the README says are always welcome. There is no documented branch naming convention, no commit message rule, and no stated review process, so a first-time contributor has to infer those from the existing history or ask. The credits.txt file at the root carries the author attribution, and the licence file is named license.txt, with lowercase naming that differs from the LICENSE.md convention used by many current WordPress plugins. ## Requirements, licence and the maintenance picture The requirements are listed in two lines, and both are floors rather than targets. WordPress 5.8 or newer and PHP 8.1 or newer. For a plugin distributed through the WordPress.org directory, a PHP 8.1 floor is a meaningful constraint, since it excludes a large share of the shared hosting that still runs PHP 7.4, and the fact that the recent releases have moved through 1.6.x with the last one in August 2026 suggests the floor has been tested against current WordPress. The licence is the part that needs care, and it is genuinely ambiguous in the metadata. The repository's licence field on GitHub reads as a custom licence that GitHub cannot classify, and the LICENSE file is what governs. Meanwhile, package.json records the license as GPL-2.0. A GPL-2.0 plugin and a proprietary plugin cannot simply be combined in one distributed product, and a custom licence may impose terms a GPL label does not describe. Anyone shipping this to a client should read license.txt and the LICENSE file directly rather than relying on either metadata field, and this is a question for whoever owns the licence, not a legal opinion. The maintenance picture is modest rather than alarming. The last push to the repository was on 2026-08-12, which is inside the six month window from the current date, and the release history shows a v1.6.3 in August 2026 and a v1.6.2 in May 2026. There is a longer gap before that, back to v1.6.1 in May 2024, so the visible development is concentrated in the last eighteen months. ## Where Fieldmanager is the wrong choice Three cases point elsewhere. The first is a headless WordPress install. Fieldmanager is entirely about the admin side of WordPress, forms, metaboxes and custom admin screens. A project using WordPress as a content API behind a JavaScript front end has no admin UI to build, so the toolkit has nothing to offer. The second is a team that wants a self-contained plugin. The install route is a second plugin in the plugins directory that has to be activated alongside your own code. If your deliverable is a single zip uploaded to a client, you now have two things to install and activate, two version sets to track, and a dependency on a plugin the client might deactivate. The third is a project that has already committed to a different form layer. The WordPress plugin ecosystem has several field and form builders, and each of them takes over the admin screen rendering in its own way. Running two of them on the same post type produces duplicate metaboxes or conflicting save handlers, and the README does not describe how Fieldmanager detects or avoids that. The alternative worth comparing against is writing the fields directly with the WordPress settings API and add_meta_box. The difference in approach is entirely about volume: the core API gives you the same primitives Fieldmanager wraps, and Fieldmanager's value is that it has already solved the repetition, the escaping, the nonce handling and the save loop for a standard set of field types. If you need three fields, the core API is less code than the dependency. If you need thirty across six admin screens with consistent behaviour, the toolkit wins on the number of lines you do not write and on the consistency you would otherwise have to enforce by hand. ## Conclusion Fieldmanager fits a team building a WordPress plugin that ships several admin forms, where writing field markup, validation and save routines by hand would be duplicated across every screen. It does not fit a project that wants a Composer library it can require, since Fieldmanager is installed as a plugin and activated, and it does not fit a team that needs to know exactly which licence applies, because the repository carries a custom licence while package.json records GPL-2.0. Before you adopt it, read the LICENSE file and license.txt in the repository root, and check the release page rather than the main branch, since the README describes main as the bleeding edge release and recommends stable releases for production. ## FAQ ### What is Fieldmanager? It is a WordPress plugin from Alley Interactive described as a comprehensive toolkit for building forms, metaboxes and custom admin screens. The API documentation is published at api.fieldmanager.org, and a separate fieldmanager-demos repository illustrates much of what it can do. ### How do I install Fieldmanager? Download the plugin and install it into your plugins directory, then activate it on the plugins screen. It is not a Composer dependency: the README instructs activation as a separate plugin rather than a require statement in your own project. ### What are the requirements for Fieldmanager? WordPress 5.8 or newer and PHP 8.1 or newer. The PHP floor is the constraint that matters in practice, since it excludes hosts still on PHP 7.4. ### How do I generate the Fieldmanager API documentation? Install ApiGen and run apigen -c apigen.neon from the repository root, using the configuration file that is committed there. The result is the same documentation tree published at api.fieldmanager.org, built from the docs-src/ directory. ### Which branch should I use for Fieldmanager in production? The README says the main branch is the bleeding edge release and recommends stable releases for production, which are published on the GitHub releases page as version tags such as v1.6.3. The project states that as of 1.0 it runs alpha, beta and RC releases and moves through minor versions quickly, so read the changelog for each minor version. ## Sources - [alleyinteractive/wordpress-fieldmanager on GitHub](https://github.com/alleyinteractive/wordpress-fieldmanager) - [Issues](https://github.com/alleyinteractive/wordpress-fieldmanager/issues) - [README](https://github.com/alleyinteractive/wordpress-fieldmanager/blob/main/README.md) - [Releases](https://github.com/alleyinteractive/wordpress-fieldmanager/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/alleyinteractive-wordpress-fieldmanager