Quarterly Progress Report - Q2 2026  🔗 **Source:** [Quarterly Progress Report - Q2 2026](https://thephp.foundation/blog/2026/07/21/quarterly-report-q2-2026/) > [!note]+ Document Notes > tags: ["php", "open-source-sustainability", "software-security", "language-maintenance", "developer-infrastructure", "foundation-governance"] > author: "Elizabeth Barron" > source: "The PHP Foundation" > reference: "https://thephp.foundation/blog/2026/07/21/quarterly-report-q2-2026/" > date_created: "2026-07-22" > > # 🏷️ Quarterly Progress Report - Q2 2026 > <!-- deep-read:sections start --> ## 🧭 Table of Contents - References - Summary - Main Content and Notes - References - Paraphrase - Newsletter - Action Items - Hypotheses - Methodology - Questions - Future Research - Implications - Learning Styles Assessment - Accessibility Assessment - DEIB Assessment - Logical Validity - DARVO Analysis - Conclusion - Refactor Appendix - Template Library ## 🔗 References - [Quarterly Progress Report - Q2 2026](https://thephp.foundation/blog/2026/07/21/quarterly-report-q2-2026/) - [PHP Foundation core developers](https://thephp.foundation/structure/#Core%20Developers) - [AF_PACKET raw-buffer pull request](https://github.com/php/php-src/pull/21631) - [STF hook dependency pull request](https://github.com/php/php-src/pull/22538) - [Follow-up improvements for ext/uri RFC](https://wiki.php.net/rfc/uri_followup) - [Query parameter RFC](https://wiki.php.net/rfc/query_params) - [PHP Ecosystem Security Team](https://thephp.foundation/blog/2026/05/18/announcing-ecosystem-security-team/) - [PHP Foundation board minutes](https://github.com/ThePHPF/foundation/tree/main/board%20minutes) ## 📝 Summary **What happened:** The PHP Foundation published its first quarterly contractor report. It describes work by a 13-person core team across eight countries, plus foundation leadership. Q2 work covered engine correctness, sockets, streams, TLS, Windows builds, extension installation, URI APIs, security triage, package audits, php.net infrastructure, contributor tools, and public governance. **Why it matters:** PHP maintenance is distributed systems work in both the technical and organizational senses. Small engine fixes, build updates, package audits, infrastructure migrations, and contributor support combine to keep a language used by a large share of the web dependable. **Stakeholders:** PHP core developers, package maintainers, WordPress contributors, hosting companies, plugin and theme authors, enterprise engineering teams, security researchers, sponsors, and end users whose sites depend on supported PHP versions. **Risks:** The report is selective and self-reported. Several projects remain experimental or target a version after PHP 8.6. Security work must balance transparency with responsible disclosure. Part-time staffing and broad scope can create capacity and continuity pressure. **Bottom line:** The strongest result is not one feature. It is a maintenance portfolio that joins core correctness, ecosystem security, release infrastructure, and clearer governance. WordPress teams should turn this visibility into earlier compatibility testing and better coordination with PHP maintainers. ## 📖 Main Content ### 1. Maintenance work becomes visible The Foundation says future reports will summarize contractor work each quarter. It also states that routine review, bug fixing, and triage continue outside the highlighted projects. This distinction matters because visible features rarely represent the full cost of language stewardship. ### 2. Engine correctness and performance remain active research areas Work addressed error-handler and destructor bugs, type-checking duplication, string allocation in `ext/phar`, stream architecture, and an experimental 8-byte `zval`. The `zval` experiment could affect memory use across PHP, but the report correctly labels it early-stage work. ### 3. New system APIs expand PHP's reach `AF_PACKET` support lets privileged PHP processes interact with Linux packet sockets. Stream error APIs, polling, TLS session resumption, PSK support, and cryptographic status exposure strengthen network and systems programming paths. These capabilities carry clear permission and threat-model requirements. ### 4. Release infrastructure is part of language safety The php.net CDN migration, Visual Studio 2026 support, dependency updates, Windows crash fixes, and continued PECL build work show that language delivery is inseparable from infrastructure. A secure source tree is not enough if release channels or binary dependencies fall behind. ### 5. Testing data improved The report says `gcovr` accuracy rose from about 54 percent to 71 percent. The important change is not only a larger number; it is a more trustworthy map of what has and has not been exercised. Coverage still measures execution, not behavioral correctness. ### 6. Extension distribution is moving toward Composer-like workflows PIE 1.5 work adds multiple-extension installation, unattended selection, no-op reinstalls, lock-file installation, provider API support, and security maintenance. Aligning extension management with familiar dependency workflows can reduce operational friction, but adoption and rollback behavior need field evidence. ### 7. Language and API proposals continue in parallel URI Builder work is landing, while query-parameter and UUID ideas remain at proposal or proof-of-concept stages. The report distinguishes accepted work from pending votes and experiments, which helps readers avoid treating all listed items as shipped features. ### 8. Ecosystem security extends beyond php-src The new PHP Ecosystem Security Team reportedly scanned more than 500 widely used Composer packages and shared more than 100 fixes with maintainers. This shifts part of the security model from waiting for reports toward coordinated discovery and repair across dependencies. ### 9. Governance and communication are treated as project infrastructure Leadership launched an ambassador program, advisory-board meetings, a State of PHP survey, a revived newsletter, and published governing-board minutes. These moves create more feedback channels and make some decisions easier to inspect. ### 🗒️ Notes - The report covers 13 contractors in eight countries, most working part-time. - It explicitly says the list is selective and excludes much routine maintenance. - Several technical claims link to pull requests or RFCs, but not every accomplishment has a direct evidence link. - One parser experiment was paused, an important example of reporting stopped work instead of only wins. - Family leave is acknowledged without framing absence as a performance problem. - The phrase “safe by design” for raw packet access depends on correct capability management and deserves a narrower claim. - Counts for package scans and fixes are useful, but severity, validation, disclosure timing, and downstream adoption are not reported. ## 📚 References - The quarterly report is the primary source for staffing, project status, and activity claims. - Linked php-src pull requests and PHP RFC pages provide stronger technical evidence for specific work. - Foundation board minutes provide governance records, but independent adoption and outcome data remain outside this report. - Security claims should be checked against advisories and maintainer confirmations when disclosure permits. ## 🗣️ Paraphrase 1. The Foundation plans to make contractor work easier to follow through quarterly reporting. 2. The team is geographically distributed, mostly part-time, and responsible for routine maintenance that the report does not enumerate. 3. Several developers worked on engine bugs, memory use, type checks, streams, and future language behavior. 4. New low-level socket and TLS features widen what PHP can do in controlled system environments. 5. The project migrated php.net delivery infrastructure and kept Windows toolchains and dependencies current. 6. Better coverage reporting gives maintainers a clearer view of test gaps, though it does not prove correctness. 7. PIE is adding extension-management behavior that resembles modern dependency tools. 8. URI improvements are accepted, while query parameters, UUIDs, and smaller values remain proposals or experiments. 9. A new ecosystem security group scanned widely used Composer packages and worked privately with maintainers on fixes. 10. Foundation leadership expanded surveys, meetings, ambassador work, newsletters, and public minutes. ## 📰 Newsletter ### PHP maintenance is a portfolio, not a patch note The PHP Foundation's first quarterly report reads less like a release announcement and more like the maintenance map the web rarely gets to see. Engine bugs, TLS APIs, Windows dependencies, CDN migration, package audits, extension tooling, and board minutes all belong to the same reliability story. **WordPress angle:** WordPress inherits the result of this work before most site owners know it exists. Core and hosting teams should track PHP 8.6 proposals early, test stream and TLS changes against real workloads, watch PIE's extension workflow, and feed ecosystem security findings into plugin and dependency guidance. ## ✅ Action Items ### DevRel - Publish a quarterly “PHP changes that affect WordPress developers” briefing with status labels for shipped, accepted, proposed, and experimental work. ### OSPO - Fund cross-project maintenance, security coordination, and contributor documentation instead of measuring value only through features. ### Community - Invite PHP maintainers to a public WordPress compatibility session and pay for preparation time. ### WordPress teams - **Core:** Build a tracked PHP 8.6 compatibility matrix and open issues before beta milestones. - **Core Performance:** Benchmark memory, garbage collection, streams, and `ext/phar` changes on representative WordPress workloads. - **Core AI:** Keep PHP-version assumptions explicit in generated code and test suggestions against supported WordPress environments. - **Core Program Team:** Assign owners and dates for cross-project PHP readiness work. - **Mobile:** Verify API clients against server-side TLS and error-handling changes where behavior can surface in apps. - **Playground:** Add preview blueprints for supported PHP snapshots when safe builds exist. - **Community:** Host maintainer exchanges that include package security, release engineering, and contributor pathways. - **Training:** Teach how PHP RFC status differs from implementation and release availability. - **Marketing:** Describe compatibility work as maintenance value without turning proposals into product promises. - **Support:** Track PHP-version and extension failures with enough detail to reveal ecosystem patterns. - **Design:** Give compatibility and environment warnings clear hierarchy and recovery paths. - **Documentation:** Link PHP-version requirements to tested behavior, known issues, and upgrade guidance. - **Photos:** Use accurate credits and alternative text for contributor and event images. - **TV:** Caption PHP and WordPress cross-project talks and add corrected transcripts and chapters. - **Polyglots:** Give translators context for engine, extension, stream, and security terminology. - **Accessibility:** Test upgrade and error messages with assistive technology and plain-language criteria. - **Meta:** Surface PHP compatibility signals in plugin, theme, and hosting-facing WordPress.org tools. - **CLI:** Test WP-CLI on new PHP versions, Windows builds, stream APIs, and extension configurations. - **Hosting:** Stage PHP updates with dependency inventories, rollback plans, and observed workload tests. - **Tide:** Add compatibility checks only when results are deterministic and actionable. - **Openverse:** Monitor runtime and dependency updates that affect ingestion, media processing, or API clients. - **Themes:** Check PHP deprecations in theme tooling and server-rendered blocks. - **Plugins:** Audit Composer dependencies, follow ecosystem security guidance, and test against upcoming PHP releases. ### The WPOCC - Maintain an enterprise PHP-readiness checklist covering hosting, extensions, observability, rollback, and vendor communication. ### FAIR - Record runtime, extension, and dependency requirements in package metadata that can travel across federated repositories. ## 🧪 Hypotheses - Quarterly contractor reports will increase sponsor understanding of maintenance work that does not produce headline features. - Earlier WordPress testing against PHP proposals and release candidates will reduce late compatibility fixes. - Package security outreach will produce more installed fixes when maintainers receive patch help instead of findings alone. - More accurate coverage data will shift review effort toward code with both high impact and low exercised coverage. - Composer-aligned extension installation will reduce environment drift when lock-file and rollback behavior are clear. ## 📊 Methodology - Compare issue and pull-request timing before and after quarterly reports to test whether public visibility changes contributor response. - Track WordPress compatibility failures across PHP release candidates, betas, and general availability. - Measure package-security outcomes by severity, maintainer response time, fix release, and downstream adoption. - Benchmark proposed engine changes with WordPress core, WooCommerce-scale data, command-line tasks, and long-running workers. - Survey sponsors and contributors about which report fields improve decisions. - Publish definitions, sampling rules, missing data, and confidence limits beside each metric. ## ❓ Questions - How will the Foundation measure outcomes rather than activity in future reports? - Which PHP 8.6 changes pose the largest compatibility risk for WordPress? - What portion of security fixes reached released package versions and downstream installations? - How does part-time staffing affect continuity for security and release-critical work? - Which experiments were stopped, and what evidence drove those decisions? - Can quarterly reporting link every major claim to an RFC, pull request, advisory, benchmark, or governance record? ## 🔮 Future Research - Maintenance capacity and bus-factor mapping across php-src and major Composer packages. - Independent benchmarks for smaller `zval` representations on content-management workloads. - Adoption and rollback studies for PIE extension installation. - Cross-ecosystem analysis of proactive package-security teams. - Governance research on whether public minutes and advisory meetings widen participation. - Compatibility forecasting between PHP release plans and WordPress support windows. ## 💡 Implications - **Practice:** Treat runtime, dependencies, build pipelines, and release channels as one maintenance system. - **Policy:** Require status labels and evidence links so readers can separate shipped work from proposals. - **Security:** Pair privileged APIs and proactive scans with least privilege, coordinated disclosure, and verified fix adoption. - **Education:** Teach maintenance as engineering work, including triage, review, packaging, and governance. - **Funding:** Support sustained contractor time and ecosystem response capacity, not only feature delivery. ## 🧠 Learning Styles Assessment - **Visual:** A workstream diagram by engine, security, infrastructure, tooling, and governance would clarify the portfolio. - **Aural:** A short quarterly briefing or podcast could make the report easier to follow while retaining a transcript. - **Verbal:** Contributor-by-contributor prose supports careful reading but needs a glossary for engine terms. - **Kinesthetic:** Reproducing one linked benchmark or pull request would turn the report into a practical learning path. - **Logical:** Status, evidence type, target version, risk, and dependency fields would improve comparison. - **Social:** Public Q&A and advisory sessions can connect maintainers, users, and sponsors. - **Solitary:** Direct RFC and pull-request links support independent investigation. - **Naturalistic:** Classification by project subsystem is more relevant than nature-based learning for this source. - **Estimated reading level:** Professional technical reading, roughly grades 11 through college, due to engine and security terms. ## 📊 Accessibility Assessment - **Perceivable — WCAG 2.2 AA 1.1, 1.2, 1.3, 1.4:** The article is text-first and its author image has alternative text; code tokens and links must remain distinguishable without color alone. - **Operable — WCAG 2.2 AA 2.1–2.5:** Navigation, links, and sponsor controls need keyboard access, visible focus, and adequate target size. - **Understandable — WCAG 2.2 AA 3.1–3.3:** Expand acronyms such as STF, FFI, PGO, and ZTS on first use and mark language changes where present. - **Compatible — WCAG 2.2 AA 4.1:** Semantic headings, links, lists, and code markup should preserve relationships for assistive technology. - **Cognitive accessibility:** Add a summary table, stable status labels, and short definitions for specialist concepts. - **Motor accessibility:** Avoid hover-only disclosures and precision-dependent navigation. - **Sensory accessibility:** Do not rely on the contributor image, color, or a future video to carry project status. ## 🌍 DEIB Assessment - **Cultural breadth:** The team spans eight countries, but the report does not describe regional participation, language access, or community impact. - **Inclusive language:** The tone respects maintainers and describes family leave without stigma. - **Neurodiversity support:** Predictable headings help scanning; a workstream index and glossary would reduce memory load. - **Representation:** Named attribution makes labor visible, though contractor status and opportunity pathways deserve continued transparency. - **Psychological safety:** Reporting a paused experiment and routine maintenance can normalize learning, limits, and non-feature work. ## ✅ Logical Validity ### Strong reasoning - The report distinguishes routine maintenance from selected highlights. - It marks several efforts as future, pending, experimental, or paused rather than presenting them as released. - Counts, countries, coverage changes, package scans, and fixes give readers concrete anchors. - Links to pull requests, RFCs, team announcements, and board minutes make some claims inspectable. ### Fallacies and weak moves - **Selection bias — highlighted accomplishments:** A leadership-selected report can overrepresent visible successes. **Fix:** Publish selection criteria and link a machine-readable activity index. - **Appeal to novelty — new APIs and experiments:** New mechanisms are not valuable merely because they are new. **Fix:** State user problems, alternatives, benchmarks, and stopping conditions. - **Security-by-permission claim — AF_PACKET:** Requiring `CAP_NET_RAW` limits ordinary access but does not make privileged use safe by itself. **Fix:** Document threat models, deployment controls, and misuse cases. - **Activity-outcome substitution — scan and fix counts:** Large counts do not show severity, adoption, or risk reduction. **Fix:** Report validated releases and downstream uptake when disclosure allows. - **Self-reporting bias — organizational progress:** Foundation leadership evaluates its own quarter. **Fix:** Add board-approved goals, progress criteria, and independent community feedback. ### Tone of voice Proud, concrete, and generally careful about project status. The report favors accomplishment framing and would benefit from planned-versus-delivered comparisons and named unresolved risks. ## 🛡️ DARVO Analysis - **Deny:** No denial of harm or responsibility is evident. - **Attack:** No attack on critics, maintainers, or users is evident. - **Reverse victim and offender:** No reversal is evident. - **Assessment:** DARVO is not present. This is an institutional progress report, not a response to an accusation. ## 🎯 Conclusion Q2 shows PHP maintenance as a connected set of engine, security, infrastructure, tooling, and governance tasks. The report improves visibility and gives WordPress teams concrete areas to watch. Its next step should be evidence-linked status reporting that measures adoption, compatibility, and risk reduction alongside activity. ## 🧱 Refactor Appendix ### Literature Split Pad #### H1 — Maintenance is a portfolio - **Claim:** Language reliability depends on more than core feature work. - **Evidence:** The report spans engine bugs, TLS, builds, CDN delivery, package security, extension tooling, and governance. - **Limit:** It does not quantify the relative cost or effect of each workstream. #### H2 — Visibility changes maintenance funding - **Claim:** Quarterly reports can make routine and preventive work easier for sponsors to value. - **Evidence:** The Foundation explicitly created the report to improve communication about contractor projects. - **Limit:** Sponsor or community response has not yet been measured. #### H3 — Ecosystem security requires direct maintainer support - **Claim:** Finding vulnerabilities creates value only when fixes are released and adopted. - **Evidence:** The security team paired scans with more than 100 fixes shared with maintainers. - **Limit:** Severity and downstream adoption data are absent. #### H4 — Experiments need status labels - **Claim:** Clear labels prevent proposals and prototypes from being mistaken for shipped behavior. - **Evidence:** The report distinguishes accepted RFCs, pending votes, early experiments, future targets, and paused work. - **Limit:** Status can change after publication. ### Atomic Split Pad #### Z1 — Maintenance reporting is funding infrastructure Work that remains invisible is harder to sponsor, staff, and defend during prioritization. #### Z2 — Coverage accuracy is a map, not proof Better coverage data improves decisions about test gaps but cannot establish behavioral correctness. #### Z3 — Privileged access is not a safety guarantee An API restricted to powerful accounts still needs a threat model, narrow capabilities, and operational controls. #### Z4 — Package security ends at adoption A disclosed or privately shared fix reduces risk only after a safe release reaches dependent systems. #### Z5 — Release infrastructure is part of the language CDNs, toolchains, dependencies, and binary builders determine whether secure source changes reach users safely. ### Fleeting Queue - Map PHP 8.6 proposals to WordPress core and popular extension test suites. - Compare the PHP report format with quarterly maintenance reporting in other open-source foundations. - Track whether the 100-plus package fixes appear in releases and dependency updates. - Build a status table for RFC, implementation, release, and WordPress-readiness dates. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Quarterly Progress Report - Q2 2026.md|Quarterly Progress Report - Q2 2026 by thephp.foundation]] ## Highlights - Our core team consists of 13 people, distributed across 8 countries. Most of our contractors work part-time for The PHP Foundation and have other ventures aside from working on the PHP core. Also, this report is not meant to be a comprehensive list of everything our contractors shipped, but a high-level summary of their most impactful work. ([View Highlight](https://read.readwise.io/read/01ky5685vz8mrbemxvnc4c3425)) - Note: The report states its staffing scope and warns that the selected work is not the full maintenance record. - Tags: atom/literature/h1, open-source-sustainability - David shipped [`AF_PACKET` raw buffer support](https://github.com/php/php-src/pull/21631) in PHP's sockets extension, so PHP can now work with low-level Linux packet sockets directly instead of shelling out or resorting to FFI. This PR closes a real gap with C, Python, Go, and Rust, and opens up native packet capture and injection for PHP. It's also safe by design, since like every other language it needs a privileged account (`CAP_NET_RAW/root`) to use, so it doesn't widen the attack surface for ordinary code. ([View Highlight](https://read.readwise.io/read/01ky5688r6t677frdtf0zyvagr)) - Note: Privilege limits ordinary access, but privileged packet capture still needs a threat model and operational controls. - Tags: atom/literature/h2, fallacy/security-by-permission - Ilija focused on ongoing security and regular issue handling and triage, work that keeps critical bugs from piling up and gets exploitable issues fixed before they reach users. He also continued work on the STF stream project, a core I/O abstraction where improvements pay off across many parts of the engine at once. In addition, he experimented with an 8-byte `zval` representation, which is a potentially high-leverage change, since `zval` is the fundamental value representation used throughout the engine, meaning a smaller size could meaningfully cut memory footprint and improve performance broadly. This is in the very early stages of experimentation. Finally, he drove improvements to `gcovr` accuracy from roughly 54% to 71%, giving the team a far more trustworthy picture of what's actually tested and better ability to catch under-tested code early. ([View Highlight](https://read.readwise.io/read/01ky5687yb0krbkw7jve85eekp)) - Note: More accurate coverage data improves the test-gap map without proving behavior is correct. - Tags: atom/zettel/z2, software-testing - Volker founded the [PHP Ecosystem Security Team](https://thephp.foundation/blog/2026/05/18/announcing-ecosystem-security-team/), a new effort to help PHP project maintainers find, fix, and handle security vulnerabilities. This is important because many maintainers, especially of smaller projects, lack the time or expertise to catch these issues themselves, leaving gaps that affect the wider ecosystem. Toward that end, he scanned over 500 of the most-used Composer packages and nearly every major framework, sharing 100+ fixes directly with maintainers, which translates into concrete, shipped security improvements across a large swath of the PHP ecosystem rather than just one project. He also worked alongside maintainers to help grow the team and support projects through specific security incidents (projects with a security need are encouraged to reach out). ([View Highlight](https://read.readwise.io/read/01ky5686vtw5fpwgn09c7esn2w)) - Note: Security outreach paired broad scanning with direct fixes, while downstream adoption remains the outcome to verify. - Tags: software-security, atom/literature/h1 - In addition to our team of developers, The Foundation's Executive Director (that's me!) and Director of Fundraising (Ben Marks) have also been hard at work making progress on our goals. Q2 focused on getting a lay of the land through a listening tour, creating and kicking off implementation of a strategy plan for the rest of the year, and onboarding new contractors, sponsors, and Board members. We launched the PHP Ambassador program, quarterly Advisory Board meetings, the State of PHP Survey, revived the monthly newsletter, and began publishing [minutes](https://github.com/ThePHPF/foundation/tree/main/board%20minutes) from the Governing Board meetings. We continue to focus on increasing Foundation transparency and collaboration with the community, and expanding our mission to include other initiatives besides PHP core language development. ([View Highlight](https://read.readwise.io/read/01ky5689kcmtyg0chpy0ga5kbh)) - Note: The Foundation treats public meetings, surveys, minutes, and communication as project infrastructure. - Tags: atom/literature/h2, foundation-governance