Title: developer-experience – Make WordPress Core --- # Tag Archives: developer-experience [ ](https://profiles.wordpress.org/johnbillion/) [John Blackbourn](https://profiles.wordpress.org/johnbillion/) 12:56 pm _on_ July 11, 2025 Tags: developer-experience, [PHP ( 78 )](https://make.wordpress.org/core/tag/php/) # 󠀁[Proposal: PHPStan in the WordPress core development workflow](https://make.wordpress.org/core/2025/07/11/proposal-phpstan-in-the-wordpress-core-development-workflow/)󠁿 **tl;dr** Several official WordPress projects use PHPStan for static code analysisStatic code analysis "...the analysis of computer software that is performed without actually executing programs, in contrast with dynamic analysis, which is analysis performed on programs while they are executing." - [Wikipedia](https://en.wikipedia.org/wiki/Static_program_analysis) of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher files as part of their development tooling and quality control. It’s used by thousands of WordPress plugins and themes to catch and prevent bugs before they’re committed. Let’s use it for WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. too. ## What is PHPStan? [PHPStan](https://phpstan.org/) is a mature, popular, and well-maintained static code analysis tool for PHP. From the PHPStan website: > PHPStan scans your whole codebase and looks for both obvious & tricky bugs. Even > in those rarely executed `if` statements that certainly aren’t covered by tests. > You can run it on your machine and in CI to prevent those bugs ever reaching your > customers in production. PHPStan provides a means of scanning 100% of the PHP code in a project and identifying whole classes of bugs relating to code correctness within the context of the project as a whole, even before executing, testing, or writing tests for the code. Another static code analysis tool that is already in wide use in WordPress is PHP_CodeSniffer( PHPCSPHP Code Sniffer [PHP Code Sniffer,](https://github.com/squizlabs/PHP_CodeSniffer) a popular tool for analyzing code quality. The [WordPress Coding Standards](https://github.com/WordPress/WordPress-Coding-Standards/) rely on PHPCS.), which checks adherence to coding standards that primarily relate to code formatting (although the WordPress Coding StandardsWordPress Coding Standards The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress [Coding Standards Handbook](https://developer.wordpress.org/coding-standards/). May also refer to [The collection of PHP_CodeSniffer rules](https://github.com/WordPress/WordPress-Coding-Standards/)( sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards. provides additional rules for security, performance, and internationalisation best practices). PHPStan doesn’t care about coding style, it is un-opinionated and only tests the _validity_ and _correctness_ of code using [increasingly strict levels of rules](https://phpstan.org/user-guide/rule-levels) which allow it to be gradually introduced into an existing code base, even one the size and age of WordPress. It is complementary to PHPCS, not a replacement. ## What is being proposed? On [#61175](https://core.trac.wordpress.org/ticket/61175), [@westonruter](https://profiles.wordpress.org/westonruter/) notes that: > PHPStan is a vital static analysis tool for identifying bugs in code. Previously > it has been used to identify problems in core by manually running PHPStan on the > core codebase. This post proposes that: * PHPStan gets added as a development dependency to WordPress with the required settings and [a configured baseline](https://phpstan.org/user-guide/baseline). * PHPStan analysis runs as a required check during CI on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. [https://github.com/](https://github.com/) Actions. * Documentation on usage of PHPStan gets added to the core handbook. * These changes are implemented during the WordPress 6.9 development cycle. [@justlevine](https://profiles.wordpress.org/justlevine/) has kindly been working on the bulk of the core implementation, the baseline, and the CI workflow [in this pull request on GitHub](https://github.com/WordPress/wordpress-develop/pull/7619). Work on a documentation page for the handbook is yet to start. The advantage of implementing a baseline is that PHPStan analysis can be introduced without having to make sweeping changes to the core codebase in order to pass all of the PHPStan rules from day one. The analysis will apply to code changes going forward, and existing issues in the baseline can continue to be addressed just as they have been in recent releases. ## Benefits of PHPStan Adopting PHPStan improves our codebase and development workflows in several ways: * **Catch bugs in untested code**: Unit, integration, and E2E tests only cover the code they execute. PHPStan can find bugs in code that isn’t explicitly tested, and make sure that code changes don’t introduce new bugs even in old code that has no tests. * **Prevent logic and type errors**: Unlike the enforcement of code formatting in PHPCS, PHPStan can trace the flow of code execution and identify critical errors that would otherwise only be caught at runtime. This is increasingly important as we work to maintain compatibility with the increasingly strict type safety requirements of PHP. * **Improve contributor experience (for humans and 🤖)**: PHPStan provides immediate, automated feedback to contributors, helping new, veteran, and even agentic developers catch their mistakes and learn how to navigate the WordPress codebase. This reduces the burden on committers during code review and helps AI tooling use WordPress as accurately as possible. * **Incremental adoption**: PHPStan provides levels of strictness that can be adopted incrementally, as well as ways to ignore rules and baseline errors in preexisting code without interrupting the codebase. This keeps in line with the [policy against unnecessary code refactoring](https://make.wordpress.org/core/handbook/contribute/code-refactoring/). Taken together, using PHPStan will help the project maintain and improve the quality and correctness of the WordPress codebase, paving the way for faster development, fewer bugs, and the safe adoption of newer PHP features over time. While _not a part of this proposal_, PHPStan also offers benefits such as type narrowing, IDEIDE Integrated Development Environment. A software package that provides a full suite of functionality to software developers/programmers. Normally an IDE includes a source code editor, code-build tools and debugging functionality. hinting, documentation, and code validation features like generics, callable signatures, integer ranges, [and lots more](https://phpstan.org/writing-php-code/phpdoc-types). These enhancements can be implemented as and when appropriate. ## Concerns [When the implementation of native TypeScript in Gutenberg was proposed](https://make.wordpress.org/core/2021/03/18/proposal-native-typescript-support-in-gutenberg/), there were some concerns raised: * The use of TypeScript could raise the barrier to entry for contributors. * TypeScript may not be here forever (ie. it could be outlasted by the underlying language). If similar concerns are applied to the implementation of PHPStan: * Like any tool, there is an element of learning involved and there is always a risk of raising the barrier to entry, however that should not be a reason to refrain from introducing new tooling that provides an overall benefit to the project. Contributors who have not used PHPStan before may not be familiar with its error messages and may need guidance addressing issues that it reports, but handbook documentation, guidance from others, and general familiarisation over time will help. We’ll likely also find that the new generation of PHP developers is familiar with PHPStan due to its wide usage in many other popular and newer projects. * Unlike TypeScript, PHPStan isn’t a language itself that needs to be interpreted or transpiled in order to convert it to the PHP code that runs WordPress. If the PHPStan project were to disappear, WordPress would continue to work, the PHPStan checks could be removed, and another static analyzer could be implemented if necessary. That said, PHPStan is an active and well-maintained project so this shouldn’t be a concern. You might have heard that PHPStan is only used to check type declarations, but this is not correct. In fact it only takes types into account when you start using it at level 3 or higher, and its scope is far beyond just type safety. Take a look through [the PHPStan rule levels](https://phpstan.org/user-guide/rule-levels) to see what it covers. You might have heard that PHPStan only works for object-oriented codebases, this is also not correct. There is nothing inherent about PHPStan that restricts it to analyzing only OOP code. It works great with functional, procedural, and OOP code, with and without namespaces, and mostly whatever else you can throw at it, including excellent support for incomplete code. There are two alternatives to PHPStan: [Psalm](https://github.com/vimeo/psalm) and [Phan](https://github.com/phan/phan). All three of these static code analysis tools are mature, popular, and well-maintained. PHPStan is being proposed because it’s the most popular out of these three tools (both inside and outside of the WordPress ecosystem), and because it’s the one that is most familiar to contributors to other official WordPress projects, and contributors and committers to WordPress core. Implementing PHPStan will not prevent developers using Psalm or Phan to scan their plugins, themes, or projects, or indeed to scan WordPress core using those tools too. ## What about GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. 󠀁[https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/)󠁿? The Gutenberg repo does not use PHPStan, however it would benefit from doing so in the same way that WordPress core will. [A proposal to implement PHPStan into the development of Gutenberg can be found here](https://github.com/WordPress/gutenberg/issues/66598). It’s not strictly part of this proposal, but the teams do need to determine whether this is a prerequisite. ## Does this affect end users? End users and website owners are not _directly_ affected by this change. PHPStan itself does not affect PHP at runtime in much the same way that TypeScript doesn’t affect JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. [https://www.javascript.com](https://www.javascript.com/) at runtime. The purpose of this class of tooling is to allow developers to maintain code at a higher standard. The effect this has on end users, consumers, developers, and web hosts is a higher quality application that is more maintainable, reliable, and correct, and will continue to be so over time.  ## Next steps * This proposal can stay open for a couple of weeks as several northern hemispherical contributors and committers are enjoying well-earned holidays. * Work needs to continue on the pull request that adds the configuration, baseline, and CI. * Continued communication needs to happen with the Gutenberg team to determine whether PHPStan scanning in Gutenberg is a prerequisite. * A documentation page for the handbook needs to be drafted. The latest version of PHPStan will be used (currently 2.1.17). This requires PHP 7.4 or greater which means the implementation of PHPStan depends on the minimum supported version of PHP in WordPress being increased to 7.4, [which is under consideration for WordPress 6.9](https://core.trac.wordpress.org/ticket/62622). Therefore the 6.9 development cycle needs to be announced before this change can be implemented. In the meantime there is no need to be concerned about PHPStan failures on PHP 7.2 and 7.3 in the pull request. Further technical details can be found on ticketticket Created for both bug reports and feature development on the bug tracker. [#61175](https://core.trac.wordpress.org/ticket/61175). ## Elsewhere If you’re curious about how other projects use PHPStan, here are some links. PHPStan is used by [thousands of WordPress plugins, themes, tools, and projects](https://github.com/search?q=path%3Acomposer.json+%22wordpress%22+%22phpstan%22&type=code), and [25,000 packages across the PHP ecosystem](https://packagist.org/packages/phpstan/phpstan). It’s been in use for years by several other official WordPress projects, including: * [WP-CLI](https://github.com/wp-cli/wp-cli) * [Performance Lab](https://github.com/WordPress/performance) * [Plugin Check plugin](https://github.com/WordPress/plugin-check) * [Two Factor plugin](https://github.com/WordPress/two-factor) * [SQLite Database Integration plugin](https://github.com/WordPress/sqlite-database-integration) * [WPGraphQL plugin](https://github.com/wp-graphql/wp-graphql) * [WordPress Coding Standards](https://github.com/WordPress/WordPress-Coding-Standards) * [Twenty Twenty-One](https://github.com/WordPress/twentytwentyone) and [Twenty Twenty-Two](https://github.com/WordPress/twentytwentytwo) It’s also been used previously by individual contributors to remediate many issues in WordPress core, most recently in [#63268](https://core.trac.wordpress.org/ticket/63268). If you are interested in using PHPStan as part of the development tooling in your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress. org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party., theme, or project, you should take a look at [the phpstan-wordpress package by Viktor Szépe](https://github.com/szepeviktor/phpstan-wordpress) which provides WordPress-specific extensions for PHPStan. ## Acknowledgements Thanks to [@justlevine](https://profiles.wordpress.org/justlevine/) [@westonruter](https://profiles.wordpress.org/westonruter/) [@swissspidy](https://profiles.wordpress.org/swissspidy/) [@sergeybiryukov](https://profiles.wordpress.org/sergeybiryukov/) and others for their work on PHPStan fixes in recent releases and for helping with this proposal. [#developer-experience](https://make.wordpress.org/core/tag/developer-experience/), [#php](https://make.wordpress.org/core/tag/php/) [ ](https://profiles.wordpress.org/adamsilverstein/) [Adam Silverstein](https://profiles.wordpress.org/adamsilverstein/) 4:22 pm _on_ September 20, 2023 Tags: [browser support ( 6 )](https://make.wordpress.org/core/tag/browser-support/), developer-experience, [standards ( 5 )](https://make.wordpress.org/core/tag/standards/) # 󠀁[Seeking proposals for Interop 2024](https://make.wordpress.org/core/2023/09/20/seeking-proposals-for-interop-2024/)󠁿 ## TL;DR Once again it’s time to submit your proposals, as Interop 2024 is happening! WordPress developers, please contribute your proposals for 2024 as [on GitHub](https://github.com/web-platform-tests/interop/issues/new/choose) or as a comment on this post. ## What is Interop? Developing for the web’s diverse browsers has historically been complicated by gaps in browser capabilitiescapability A **capability** is permission to perform one or more types of task. Checking if a user has a capability is performed by the ` current_user_can` function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability). that developers had to work around. Interop is a multi-year, multi-browser effort to address that.  Interop aims to improve interoperability across the three major web browser engines( Chromium, WebKit and Gecko) in important areas as identified by web developers. Interop provides a benchmark – agreed on by representatives of three major browsers and developed through a process of public nomination – and a scoring mechanism.  _The overall goal is to make developers’ lives better by enabling a widely compatible“_ [_Baseline_](https://web.dev/baseline/)_” of web platform features._ The scale of WordPress and the wide variety of use cases we support puts WordPress developers in a unique position to contribute to and benefit from this effort. In the past, WordPress has helped identify and adopt important features like `srcset` and native lazy loading, and Interop gives us an opportunity to contribute feedback directly to browser developers.  The **Interop 2023** work has already [made great progress](https://wpt.fyi/interop-2023) including on suggestions WordPress developers made on [last year’s post](https://make.wordpress.org/core/2022/10/10/seeking-proposals-for-interop-2023/) like color-mix, inert, import-maps and some contentEditable areas. Now, the effort has begun to identify issues for [Interop 2024](https://web.dev/interop-2024-proposals/). What browser interoperability issues continue to present problems for WordPress developers? You can make suggestions to the Interop 2024 project directly by opening a [GitHub issue](https://github.com/web-platform-tests/interop/issues/new/choose) or leave a detailed comment below. Suggestions can include features that have inconsistent behaviors across browsers or features that aren’t available in all browsers. When formulating proposals, keep in mind that **the goal of the project is to improve interoperability between browsers rather than identify new features**. What potential features in WordPress are blocked by cross-browser compatibility issues? Help make browsers better by submitting issues! [#browser-support](https://make.wordpress.org/core/tag/browser-support/), [#developer-experience](https://make.wordpress.org/core/tag/developer-experience/), [#standards](https://make.wordpress.org/core/tag/standards/) [ ](https://profiles.wordpress.org/adamsilverstein/) [Adam Silverstein](https://profiles.wordpress.org/adamsilverstein/) 5:48 pm _on_ October 10, 2022 Tags: [browser support ( 6 )](https://make.wordpress.org/core/tag/browser-support/), developer-experience, [standards ( 5 )](https://make.wordpress.org/core/tag/standards/) # 󠀁[Seeking proposals for Interop 2023](https://make.wordpress.org/core/2022/10/10/seeking-proposals-for-interop-2023/)󠁿 ## TL;DR Proposals for Interop 2023 focus areas are open and can be submitted as a [GitHub issue](https://github.com/web-platform-tests/interop/issues/new?template=focus-area-proposal.yml) until **October 15, 2022**. ### What is Interop? Interop is an effort to improve interoperability across the three major web browser engines (Chromium, WebKit and Gecko) in important areas as identified by web developers. This work provides a benchmark – agreed on by representatives of three major browsers and developed through a process of public nomination – and identifies focus areas to be scored according to their pass rate on selected relevant tests.   The scale of WordPress and the wide variety of use cases we support puts WordPress developers in a unique position to contribute to and benefit from this effort. In the past, WordPress has helped identify and adopt important features like `srcset` and native lazy loading, and Interop gives us an opportunity to contribute feedback directly to browser developers.  The Interop 2022 work has already [made great progress](https://wpt.fyi/interop-2022) and the effort has begun to identify issues for Interop 2023. What browser interoperability issues continue to present problems for WordPress developers? You can make suggestions to the Interop 2023 project directly by opening a [GitHub issue](https://github.com/web-platform-tests/interop/issues/new?template=focus-area-proposal.yml). Suggestions can include features that have inconsistent behaviors across browsers or features that aren’t available in all browsers. When formulating proposals, keep in mind that the goal of the project is about improving interoperability between browsers rather than identifying new features. What potential features in WordPress are blocked by cross-browser compatibility issues? We can help make browsers better by submitting these issues! [#browser-support](https://make.wordpress.org/core/tag/browser-support/), [#developer-experience](https://make.wordpress.org/core/tag/developer-experience/), [#standards](https://make.wordpress.org/core/tag/standards/)