# Advanced Custom Fields Pro: WordPress plugin mirror and Git workflow > The pronamic/advanced-custom-fields-pro repository is a GitHub mirror of the Advanced Custom Fields Pro WordPress plugin, with updates synchronized through GitHub Actions. It is useful for inspecting released plugin code, but it is not the place to submit support requests or pull requests. **pronamic/advanced-custom-fields-pro** — Advanced Custom Fields Pro, Git-ified. Automatically synced via GitHub Actions! This repository is just a mirror of the Advanced Custom Fields Pro plugin. Please do not send pull requests and issues. - Repository: https://github.com/pronamic/advanced-custom-fields-pro - Website: https://www.advancedcustomfields.com/pro/ - Stars: 1,351 · Forks: 370 - Language: PHP - License: not declared - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/pronamic-advanced-custom-fields-pro ## What the Advanced Custom Fields Pro mirror contains This repository addresses a distribution problem specific to WordPress plugins: developers often need to inspect released code, compare plugin versions, or connect changes to a deployment history. The repository description identifies `pronamic/advanced-custom-fields-pro` as a mirror of the Advanced Custom Fields Pro plugin and says that synchronization happens automatically through GitHub Actions. Its default branch is `main`. Based on the repository layout, it contains the recognizable parts of a PHP WordPress plugin. The root includes `acf.php`, `index.php`, and `readme.txt`, while `assets/`, `includes/`, `pro/`, `schemas/`, `src/`, `vendor/`, and `lang/` hold separate areas of the distribution. That structure suggests that this is packaged plugin source rather than a standalone application or a development scaffold. The repository's primary language is PHP, consistent with its role inside WordPress. The intended users include WordPress developers who maintain custom fields in their own environments, engineers reviewing changes between ACF Pro releases, and organizations that want the plugin source represented in GitHub. The README describes Advanced Custom Fields as a WordPress plugin for controlling edit screens and custom field data. It does not document which individual fields or Pro features are included in this mirror, so the exact feature inventory cannot be established from the repository description alone. ## Why GitHub Actions synchronization changes the repository's role This repository is not presented as the canonical development location. The repository description says it is a mirror and warns readers not to send pull requests or issues. That boundary matters because a contributor cannot infer from the presence of GitHub workflows that the project accepts outside patches there. The README points ACF core issues toward the issue tracker only when they concern the core codebase, while the repository-specific description excludes pull requests and issues for this mirror. The stated synchronization mechanism means that vendor releases can appear in this GitHub repository without requiring developers to import each archive manually. Recent release entries show `v6.8.8`, `v6.8.9`, and `v6.8.10`, with `v6.8.10` dated 2026-09-11. Those tags or release entries provide a history for checking which plugin version was mirrored. They do not, by themselves, document the internal contents of the GitHub Actions workflow or guarantee that every installation will update immediately. For an engineer, the practical distinction is between using the mirror as release history and treating it as an upstream contribution channel. File commits and version entries can support code review, release comparison, and repository storage. They should not be used as evidence that patches submitted here will reach the commercial plugin. The documentation explicitly directs feedback to the ACF feedback board, core issues to the appropriate GitHub issue process, and support requests to the support forum or email-based ticket system. ## Acquiring ACF Pro and performing the first WordPress use The README does not provide installation commands, a Composer package name, a WordPress plugin directory path, or a downloadable package workflow. It directs readers who need help getting started to the ACF documentation, support forum, and support team. The repository description also identifies `https://www.advancedcustomfields.com/pro/` as the project's homepage. Because no installation steps are given here, inventing a `wp plugin install` command or a ZIP URL would not be reliable. The first practical use starts outside this mirror: obtain Advanced Custom Fields Pro through the vendor's product channel, install the resulting WordPress plugin, and then use the ACF interface to define the custom fields required by the site's content model. The README states that ACF is used to take control of WordPress edit screens and custom field data, but it does not provide a field-creation example, a `functions.php` snippet, or a REST API request. After installation, this repository can serve a separate first task: compare its current release entry with the ACF Pro version deployed on a WordPress site. Review `main`, inspect the relevant release entry, and compare the plugin files stored in the repository with the deployed plugin copy. The expected result is a clear record of whether the mirror contains the release used by the site. The repository does not document activation steps, license activation, database migrations, rollback procedures, or multisite behavior, so those parts require the vendor documentation and support channels. ## Reading the plugin layout during code review A reviewer should begin with the root files because they establish how the package presents itself to WordPress. `acf.php` is the obvious plugin entry point, while `index.php` and `readme.txt` sit beside it as distribution metadata. The `includes/` and `src/` directories likely cover different parts of the implementation, but their individual responsibilities are not documented in the README. The presence of both directories should not be treated as proof that all files are independently loadable. The `pro/` directory distinguishes the mirrored Pro package from the surrounding plugin structure. `vendor/` indicates that packaged dependencies are included, while `lang/` contains localization resources. `schemas/` contains schema-related files, and `assets/` contains non-PHP assets. These names make the repository useful for targeted review, but they do not disclose database schemas, activation hooks, update hooks, or extension APIs. The README discusses translation work and says that PRO translations may be submitted through a pull request on this repository, while free-version strings are imported from `translate.wordpress.org`. That statement applies to translation contributions, not general feature patches. The repository description's instruction not to send pull requests creates an important boundary that the README does not resolve in detail. Code review should therefore record the version and changed paths, but contribution routing should follow the current vendor instructions rather than opening a pull request against the mirror. ## Upgrade visibility and the limits of a Git mirror Upgrade visibility is the clearest benefit of this repository. Release entries dated 2026-08-20, 2026-08-28, and 2026-09-11 provide a sequence for ACF Pro versions `v6.8.8`, `v6.8.9`, and `v6.8.10`. An organization can record which version is deployed, compare that value with `main`, and inspect the corresponding Git diff. The repository was not archived, and its last push was on 2026-09-11. That establishes recent repository activity, but it does not guarantee compatibility with every WordPress version or custom field configuration. A Git history can also make an upgrade review concrete. Changes under `src/`, `pro/`, `schemas/`, or `vendor/` may require different levels of attention, although the README does not classify them by risk. A schema change deserves particular scrutiny because it may affect stored field definitions, but the repository does not state how migrations are performed or whether an upgrade can be rolled back. Upgrade planning must therefore come from the vendor's release documentation rather than Git tags alone. The mirror has no documented staging environment, deployment procedure, health check, or rollback command. Its automatic synchronization also creates a provenance question: the release shown in GitHub is not necessarily the package currently installed in a given WordPress site. The license is recorded as unknown, so redistribution, modification, and internal deployment rights cannot be confirmed from this repository. This is a review source, not a substitute for the vendor's licensing terms. ## Why a WordPress-native alternative may be a better fit The relevant alternative approach is to inspect the ACF Pro package installed directly in a WordPress environment rather than relying on a synchronized GitHub mirror. A WordPress installation gives the reviewer the exact plugin directory present in production, including the files selected by that site's license and deployment process. This approach is less convenient for release history because a site directory may not retain a meaningful Git history, but it avoids the question of whether a mirror commit matches the deployed package. Another alternative is to use the vendor's release package and changelog as the source of truth for an upgrade. That workflow provides the package intended for installation, but it does not create a line-by-line comparison across historical releases unless each archive is retained separately. The mirror is better for engineers who need Git diffs and commit history; the installed plugin directory is better for verifying what WordPress actually executes. ACF also differs from building custom field storage directly with WordPress plugins or site-specific PHP code. Direct implementations can avoid ACF's edit interface and package shape, but they would need their own validation, admin UI, serialization, permissions, migration, and compatibility handling. The available repository information does not compare those alternatives feature by feature, so the choice should be tied to whether the site already depends on ACF's data model and whether Git-based release inspection is the main requirement. ## Conclusion Developers who need a readable Git history of Advanced Custom Fields Pro can adopt this repository as a mirror for inspection and change tracking. Site operators should install the plugin through the vendor's supported channel, while contributors and support seekers should use the documented support and feedback systems. Before adoption, verify the license terms, compare `main` with the production plugin version, and confirm that the mirror contains every file needed in the target WordPress environment. ## FAQ ### How do I install Advanced Custom Fields Pro from this repository? The repository does not provide installation commands or package instructions. Its README directs users to the ACF documentation and support website, while the repository description points to the Advanced Custom Fields Pro homepage. ### Can I submit a pull request to the Advanced Custom Fields Pro mirror? The repository description explicitly says not to send pull requests or issues. The README separately discusses core issues and PRO translation submissions, so contribution routing depends on the type of change and the current vendor instructions. ### How can I tell which ACF Pro version is in the repository? The repository lists release entries such as `v6.8.8`, `v6.8.9`, and `v6.8.10` on its default branch, `main`. The latest listed entry is `v6.8.10`, dated 2026-09-11. ### Does this repository provide WordPress support? No. The README says the repository is not suitable for support requests and directs users to the community forum or the email-based ticket system. ## Sources - [Issues](https://github.com/pronamic/advanced-custom-fields-pro/issues) - [Project website](https://www.advancedcustomfields.com/pro/) - [pronamic/advanced-custom-fields-pro on GitHub](https://github.com/pronamic/advanced-custom-fields-pro) - [README](https://github.com/pronamic/advanced-custom-fields-pro/blob/main/README.md) - [Releases](https://github.com/pronamic/advanced-custom-fields-pro/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pronamic-advanced-custom-fields-pro