PHP: The latest news in the PHP world

Weekly help thread

2026-06-22T06:00:19+00:00

Hey there!

This subreddit isn't meant for help threads, though there's one exception to the rule: in this thread you can ask anything you want PHP related, someone will probably be able to help you out!

submitted by /u/brendt_gd
[link] [comments]

Pitch Your Project 🐘

2026-06-19T08:00:29+00:00

In this monthly thread you can share whatever code or projects you're working on, ask for reviews, get people's input and general thoughts, … anything goes as long as it's PHP related.

Let's make this a place where people are encouraged to share their work, and where we can learn from each other 😁

Link to the previous edition: /u/brendt_gd should provide a link

submitted by /u/brendt_gd
[link] [comments]

Tired of typos slipping through code review - built a wrapper around Rust typos-cli

2026-06-24T14:56:18+00:00

Hi everyone,

I’ve been using the Rust-based typos CLI for spellchecking codebases, but wanted a setup that fits more naturally into PHP projects and CI pipelines alongside tools like Pint, PHPStan, Rector, etc. The primary use case is CI - no global installs required on runners, and consistent spellchecking across teams.

To solve this, I built a lightweight wrapper that ships with the correct platform binary, so nothing needs to be installed globally. The actual spellchecking is handled by the Rust typos project, which does all the heavy lifting.

Feedback welcome, especially from anyone already running typos in PHP projects. Cheers!

GitHub: https://github.com/chr15k/php-typos

submitted by /u/BrilliantImpossible8
[link] [comments]

One Month of Ecosystem Security Engineering

2026-06-23T11:36:36+00:00

If you're curious about what our Ecosystem Security Team has been up to the past month, you're in luck! Volker Dusch has provided an update in our recent blog post.

submitted by /u/elizabethn
[link] [comments]

How to Contribute to PHP’s Source Code

2026-06-24T13:21:01+00:00

submitted by /u/nunomaduro
[link] [comments]

Is it hard to find very senior PHP developers with experience in complex, highly regulated environments?

2026-06-22T19:37:55+00:00

The firm I work for has a very old PHP codebase based on ZF1. It works but its got a lot of dark corners and tech debt that I hear vague mystical things about.

Deployment is complicated. Its a SASS app with a lot of individual customer databases and no way to deploy to a single pilot customer after a risky refactoring ... all customers are at risk of regressions during a deploy, and there is no automated testing at all to mitigate those risks.

The dev team is weak and dependent on a contractor who is the big giant head.

We need to find a super strong developer to replace the contractor who can stand up to a couple of strong personalities, take total ownership and responsibility for unwinding tech debt, implementing new features, and building a much strong development culture.

So far all resumes and interviews have been very underwhelming and I'm wondering whether the broader PHP ecosystem actually contains developers of this seniority simply due to lack of PHP in this market segment.

I may be deep in the weeds in thinking that PHP is not applied to big enterprise-scale SASS apps, but that is my intuition and I'm looking for some opinions on the matter to help me decide how to modify my recuiting strategy or even my long term architectural plans.

Any thoughts on this?

EDIT: I should have considered that this would be taken as a job post so I must say this is USA based. Its is full-time remote, but you gotta be based in the USA. Sorry!

EDIT: I'm overwhelmed by the outreach. I will slowly work through all the DMs and replies during the day.

submitted by /u/funkycitizen
[link] [comments]

PHP RFC: Duration class

2026-06-21T20:13:51+00:00

submitted by /u/gaborj
[link] [comments]

New Zephir releases

2026-06-22T06:01:11+00:00

I've noticed that, after a hiatus of about a year, new releases of Zephir have appeared (mainly bug fixes, but also new features, such as support for variadic functions/methods). Do you think it makes sense to revive this language for developing PHP extensions?

https://github.com/zephir-lang/zephir

submitted by /u/Mastodont_XXX
[link] [comments]

pdo_duckdb: a PDO driver for DuckDB, and my first PDO driver in 15+ years

2026-06-21T17:52:30+00:00

DuckDB is the in-process analytical database, roughly SQLite for OLAP work: columnar, vectorized, no server, one file. PHP has shipped PDO_SQLite in core for twenty years but had nothing equivalent for DuckDB. If you wanted DuckDB from PHP, your options were FFI against its C API or shelling out to the CLI, neither of which looks anything like the rest of your data layer.

So I wrote pdo_duckdb, a native PDO driver. You connect with a DSN and use the same PDO API you already use for SQLite, MySQL, and Postgres: prepared statements, positional and named params, transactions, foreach over results.

php $db = new PDO('duckdb:/path/to/analytics.duckdb'); $stmt = $db->prepare('SELECT region, SUM(amount) AS total FROM sales WHERE year = ? GROUP BY region'); $stmt->execute([2026]); foreach ($stmt as $row) { /* ... */ }

A few things beyond the standard surface:

a native Appender for bulk loads, much faster than row-by-row INSERT, and it accepts PHP arrays for LIST/STRUCT/MAP columns
result streaming for large scans via PDO::DUCKDB_ATTR_UNBUFFERED, so a huge SELECT isn't bounded by memory
DuckDB's own extensions (httpfs, json, and so on) load through plain SQL, no special API
when open_basedir is set, the driver disables DuckDB's SQL-level file access (read_csv, COPY, ATTACH) so the sandbox holds at the SQL layer, not just for the database file path

It's honest-early. The query path, appender, transactions, and type decoding all work and are tested, but it's young, and I haven't published benchmarks because the speed here is DuckDB's and the driver's job is to stay out of its way. lastInsertId isn't supported, since DuckDB has no rowid.

This is also the first PDO driver I've written since I was one of the original authors of PDO back around 2005. The driver model itself has barely changed; the world around it has. The thing that actually cost me a release was static-linking DuckDB's C++ runtime into a C extension so the prebuilt Linux binary loads on a clean host. PIE ships prebuilt binaries now, so install is just:

pie install iliaal/pdo_duckdb

Free, BSD-3 licensed. Repo: https://github.com/iliaal/pdo_duckdb

Longer write-up with the details: https://ilia.ws/blog/pdo-duckdb-a-pdo-driver-for-duckdb

Happy to answer questions, and I'd welcome feedback from anyone running DuckDB for analytics off a PHP stack.

submitted by /u/Ilia0001
[link] [comments]

Hibla Database Chapter Completed

2026-06-22T12:56:31+00:00

Hello everyone, I just wanted to share that I finally able to finished building the entire Hibla Async Database Ecosystem..

Sqlite Client: https://github.com/hiblaphp/sqlite
Mysql Client: https://github.com/hiblaphp/mysql
PostgreSQL Client: https://github.com/hiblaphp/postgres
Standalone Query Builder: https://github.com/hiblaphp/query-builder
Schema Manager and CLI tooling extension library for the query builder: https://github.com/hiblaphp/schema-manager
Meta-package for Hibla database ecosystem: https://github.com/hiblaphp/database

With these pieces finally in place, I can now focus on building a high-performance, multi-core RFC compliant HTTP server designed to take full advantage of the entire Hibla stack.

submitted by /u/rc0604
[link] [comments]

90% memory usage, constant alerts, 50K redundant queue jobs — here is how I fixed my PHP server in one week

2026-06-22T17:26:09+00:00

Running a PHP app that processes a lot of background work? Here is what happened when my 8 GB Hetzner VPS hit its limit and what actually fixed it.

The app: LaraPlugins.io, a PHP 8.5 + Laravel Octane + FrankenPHP stack with Horizon workers running health checks, GitHub syncs, and package indexing 24/7.

The problems were embarrassingly basic once I looked:

12 Horizon workers with unlimited job processing, each grabbing 500 MB. Set maxJobs to 100 per worker so memory gets released regularly. Combined memory ceiling dropped by ~2 GB.

One queue job type dispatching 50,000 individual HTTP calls to Cloudflare every week. Replaced it with a Redis set + bulk API approach. One self-rescheduling job handles the entire batch now. The Redis set deduplicates naturally.

MySQL sort buffer was too small for sorting-heavy queries. The default sort_buffer_size causes disk-based sorts when you query 76,000 rows by downloads, stars, or health score. A single config bump in the Docker Compose file fixed it.

A JSON blob column loaded on every query when most queries never read it. Global scope to exclude the column by default, load it explicitly only when needed.

GitHub API rate limits causing crash-retry loops. Added explicit 429 detection with proper backoff matching the retry-after window instead of relying on Horizon's retry mechanism.

Observability tooling ingesting everything. Laravel Nightwatch was logging every queue job and request. Cut the event ingestion to what I actually monitor. The agent container stopped being a resource drain.

The 8 GB VPS went from 90%+ memory with constant New Relic alerts to a stable 65-80% with no regressions. Response times stayed under 100 ms average.

Full write-up with before/after numbers on y blog.

submitted by /u/HolyPad
[link] [comments]

PHP-FPM segfault (general protection fault) with IonCube Loader PHP 8.5 on missing named argument

2026-06-22T15:19:26+00:00

PHP 8.5.7, IonCube Loader 15.5.0, Linux, Apache + PHP-FPM

Symptom: PHP-FPM worker crashes with general protection fault in ioncube_loader_lin_8.5.so when a static method is called with named arguments where a required parameter is missing that is not the last parameter. Apache returns 503 or 500. No PHP error handlers, shutdown functions, or exception handlers are called.

Reproduced with this script:

php

class Testtesttest { static function IneedThreeParams( ?string $param1, mixed $param2, int $param3, ) {} } function missAnArgument() { Testtesttest::IneedThreeParams( param1: 'Test', param3: 1, ); } missAnArgument();

Expected: PHP handles this with an ArgumentCountError.

Found result:

Without IonCube loaded, PHP handles this with an ArgumentCountError. (correct)
With IonCube loaded: Apache return 503 or 500; PHP-FPM worker crashes with general protection fault in ioncube_loader_lin_8.5.so

My solution: disabling Ioncube.
Another solution: never forget arguments.

submitted by /u/FrameOne2009
[link] [comments]

Working On Job Listing Website 🌐🌎👨🏾‍💻

2026-06-22T08:35:37+00:00

Day #01 working with Slim PHP microframework

Working with logic data modeling, so far I've covered

- Entities

- Attributes

- Relationships

Looking forward to:

- Object mapping

- Use of Repository pattern

- PDO connection and prepared statements

- Authorization and Authentication using JWT

Slim is freedom throgh plug and play, but if one is not careful, it can be hell, "freedom of plugging" cause !!

What are you currently working on ? Please share and lets build together "building in public"

Happy coding 😃

submitted by /u/iamsamaritan300
[link] [comments]

Need cleaner statistics in Laravel dashboards? I built Laravel Statistician

2026-06-21T19:26:47+00:00

submitted by /u/Omar_Ess
[link] [comments]

A Filament plugin that turns scattered activity logs into one clean timeline for any model

2026-06-21T05:09:47+00:00

submitted by /u/Agreeable-Pace2487
[link] [comments]

The PHP Ambassador Program is Open

2026-06-19T15:25:44+00:00

You can now join the PHP Ambassador Special Interest Group if you want to help improve the perception of PHP in spaces outside our bubble. Help us help the community tell the real story of modern PHP development! hashtag#php hashtag#phpc

submitted by /u/elizabethn
[link] [comments]

Harden Your Session Cookie Configuration in PHP, PHP 8.6 RFC

2026-06-18T21:47:08+00:00

submitted by /u/CauliflowerSlight838
[link] [comments]

tree-sitter-language-pack 1.9 - 306 tree-sitter parsers as a native PHP extension

2026-06-19T08:41:50+00:00

Hi Peeps,

Goldziher, CTO at kreuzberg.dev. I posted tree-sitter-language-pack here back at v1.0 when it had ~170 parsers. It's at 306 now and just hit 1.9, so here's an update.

It's a native PHP extension (ext-php-rs) that gives you tree-sitter parsing for 306 languages without vendoring grammar sources or matching ABI versions yourself. Parsers download on demand and cache locally. Past plain parsing you get functions, classes, imports, symbols, docstrings and syntax-aware chunking, which is useful if you're feeding code into an LLM.

composer require kreuzberg-dev/tree-sitter-language-pack

On methodology, since it comes up: yes, built with AI agents, but on a strict harness - TDD, benchmark-driven hot paths, strict linting and high coverage in every language. The PHP extension is generated from the Rust core by our binding generator alef and verified, not hand-rubber-stamped.

MIT licensed. Feedback welcome.

submitted by /u/Goldziher
[link] [comments]

Hosting Laravel sites on dirt cheap WordPress hosting, saves me money and I built a package to make the workflow not terrible

2026-06-19T13:35:55+00:00

submitted by /u/Andreww-carnegie
[link] [comments]

I Replaced JSON With a Custom Binary Format. In PHP.

2026-06-19T17:31:50+00:00

submitted by /u/Old-Illustrator-8692
[link] [comments]

What shipped across my native PHP extensions since I last posted here, and why five of them lowered their minimum PHP version

2026-06-18T11:44:01+00:00

I maintain a set of native PHP extensions: php_excel, mdparser, php_clickhouse, fastchart, fastjson, phpser. Each has had a release or three since I last posted it here, and rather than drop six separate release threads on you, here is one roundup of what actually changed.

The thing that cuts across most of them: I lowered the minimum PHP version. php_excel, fastchart and fastjson now build on 8.1; phpser and mdparser on 8.2. All of them had required 8.3. Most libraries raise their floor over time rather than lower it, but for a native extension the minimum is a packaging decision, not a language one. None of these needed an 8.3-only engine API. So if you are pinned to 8.1 or 8.2 by your distro or your employer, you can run them now.

What else shipped, briefly:

mdparser had the biggest internal change. I swapped the parsing backend from cmark-gfm to md4c, a single-file streaming parser compiled into the extension, which roughly doubled throughput: the old backend benchmarked at ~5-9x the fastest pure-PHP parsers, md4c is ~10-20x. It also brought CommonMark 0.31 conformance (652/652) and a set of opt-in dialect extensions (LaTeX math, wiki links, ==highlight==, super/subscript, GitHub-style admonitions). The public API did not change, so it is a drop-in upgrade.

php_excel added libxl 5.2.0 support, so you can now read the data validations stored in an xlsx file, and a new AS_TEXT write mode that writes a value verbatim, so untrusted input starting with '=' cannot turn into a live formula when someone opens the file. Plus a sweep of bounds checks on the libxl integer arguments.

php_clickhouse got insertFromStream(), which stream-parses a TSV or CSV file and INSERTs it in C++ batches without buffering the whole file in PHP memory. The release after was a hardening round: fixed a heap use-after-free reading Map columns, a clone-corrupts-the-heap bug, and setDatabase() now survives a reconnect instead of silently reverting to the constructor database.

fastchart changed the most by version number, 0.2 to 1.3, so it is past 1.0 now. The recent highlights are vector PDF output (renderToFile('out.pdf') renders every chart type as real vector geometry, no rasterization) and structured image-map data for click regions.

fastjson grew document-surgery functions: RFC 6901 JSON Pointer reads that pull one value out of a large document without decoding the whole thing, RFC 7386 merge-patch, and a relaxed decode mode that accepts JSONC (comments, trailing commas). All backed by yyjson.

phpser, my binary serializer aimed at cache workloads, got a faster decoder: it installs declared object properties straight into their slots instead of building a properties hashtable per object, about 22-25% faster on same-class DTO batches. It also closed a correctness gap where a crafted numeric-string array key could slip past isset() / array_key_exists().

All of these are native C extensions, BSD-licensed, installable via PIE, and live at github.com/iliaal (each repo has its full changelog). I wrote up the minimum-version decision and most of these in more depth here: https://ilia.ws/blog/lowering-the-php-floor-what-shipped-across-five-extensions

Happy to answer questions, especially on the mdparser engine swap or the php_clickhouse streaming loader, which are the two I expect people will have opinions on.

submitted by /u/Ilia0001
[link] [comments]

Authenticating a PayPal notification is not the same as trusting what it says (CVE-2026-9189)

2026-06-18T17:56:47+00:00

submitted by /u/StrangeR_825
[link] [comments]

The pattern I landed on for using OPC UA subscriptions in Laravel (after one too many "but how do I actually use it?" questions)

2026-06-19T08:12:12+00:00

I maintain php-opcua, a pure-PHP OPC UA client (talking to PLCs / industrial gear). Since the intro post, the question I keep getting isn't about the protocol — it's "okay, but how do I actually wire this into a real Laravel app?" And it's a fair question, because OPC UA subscriptions break PHP's whole mental model.

The core tension: subscriptions are stateful. The server keeps your session open and pushes value changes to you. A PHP-FPM request lives for a few milliseconds and then dies, taking the session with it. So polling the PLC on every request means a full handshake (~150ms) each time, and you still can't receive pushed data at all.

The pattern I've settled on, and that I think holds up in production:

A small long-lived daemon (ReactPHP) owns the OPC UA session and the subscriptions. One session, period.
Your web requests never touch the PLC. They talk to the daemon over local IPC (~5ms) instead.
Every value change the daemon receives gets dispatched as a normal Laravel event (DataChangeReceived). From the app's point of view it's just another event.
A tiny listener mirrors the latest value into the cache.
Livewire just polls the cache (wire:poll.1s). It never knows OPC UA exists. So the expensive part — the plant network — is paid once by the daemon, no matter how many browsers are watching the dashboard. The whole thing is about 80 lines end to end.

Two things I didn't expect to matter as much as they did:

Declaring subscriptions in config instead of code. The daemon recreates them on its own boot, so the dashboard survives a daemon restart with zero application code. That resilience turned out to be the part people actually cared about.
A "LIVE" badge that doesn't lie. A dashboard showing a frozen last-good value while the PLC is unreachable is worse than no dashboard. So the badge goes green only when both the connection is up and the last notification is fresh (heartbeat timestamp). Connection-up alone isn't enough — a subscription can be silently dead on a healthy connection. Full writeup with all the code (config, listener, Livewire component, the badge logic): https://www.php-opcua.com/blog/opcua-subscriptions-laravel-dashboard

The daemon-owns-the-session part isn't really up for debate — that's how the package works, and it's what makes subscriptions possible under PHP's request model at all. Where there's actually room for choice is the last hop: once a value lands in Laravel as a DataChangeReceived event, how you get it to the browser. I went with listener → cache → Livewire polling because it's the simplest thing that survives restarts, but broadcasting/websockets, SSE, or a queued listener writing to the DB are all reasonable depending on the load. If you've shipped one of those for a live dashboard, I'd like to hear how it held up — always looking for patterns worth adding to the docs.

submitted by /u/One-Mongoose-6961
[link] [comments]

PHP and AI : what actually exists at the language level

2026-06-19T11:09:56+00:00

We hear a lot about coding PHP with AI, and PHP calling remote API to query them.

And there are tools maturing quickly in the ecosystem: transformers, home made LLM, FFI libraries and even Rasmus himself creating an extension to run models from within PHP.

So much new ideas poping up!

https://www.exakat.io/php-and-ai-what-actually-exists-at-the-language-level/

submitted by /u/exakat
[link] [comments]

This Week In PHP Internals | June 17, 2026

2026-06-17T21:50:11+00:00

[SLIDE 01 — title] Hello world, it's Wednesday, June 17, 2026, and here's what happened This Week in PHP Internals. [SLIDE 02 — generics goes to a vote] We start where we left off last week: generics. Last week, this was the most traction generics had seen in years. This week, Seifeddine Gmati took his Bound-Erased Generics RFC to a vote — and he did it *over Larry Garfield's explicit objection* . Here's the thing about that vote: as of this recording, it's **losing** . 7 in favor, 18 against, 5 abstaining. It needs a two-thirds majority, and it's sitting around a quarter. Rowan Tommins summed up the No camp in one line: "I want PHP to have generic types, but I want to be able to trust those types. This RFC does not deliver that." Erased generics let you write a type the engine **won't enforce** — and 18 voters decided that's a step they're not willing to take. [SLIDE 03 — quote] Larry had warned them. He reposted this into the vote thread for visibility: "you don't call the vote until you know you have the votes." Right now, that looks *prescient* . [SLIDE 04 — the path forward] So what happens to generics now? Two camps are already sketching the next move. Larry's pitch: *don't* cram this into `8.6`. Make `8.6` the last of the `8.x` line, make PHP 2027 a `9.0`, and ship enforced generics there as the headline — "PHP 9, now with generics." Levi Morrison surprised himself by voting yes anyway, as a "stepping stone" you tighten later. And a non-voter writing as wheakerd made the plea of the week: don't let this collapse into "full reified generics now, or PHPDoc forever" — ship a smaller, **enforceable** subset first, interfaces and abstract classes, and grow from there. The vote runs through June 28. There's also a secondary vote on syntax — `+T`/`-T` versus `in T`/`out T` — and the C#-style in-out spelling is winning 18 to 4. [SLIDE 05 — literal scalar types] And honestly, Seifeddine had a *week* . While his generics RFC was going down, he opened a brand-new one: Literal Scalar Types. The idea — let a parameter be typed as the literal values it actually accepts. `array_filter`'s `$mode` really only takes `0`, `1`, or `2`, but it's typed `int`, because that's all we can say today. Literal types let the signature say what it **means** . David Gebler's first reaction was the obvious one — don't enums already do this? Seifeddine's answer: enums are a closed set in a new file with an import; a literal union describes existing scalar APIs and open value sets without any of that. And he found time to back a third proposal too — Jorg Sowa's revival of case-sensitive PHP. *Busy man.* [SLIDE 06 — the php tag, again] Remember `.phpc` from last week — pure-code files with no `<?php`, the proposal that collapsed so thoroughly even its biggest defender conceded? Hendrik Mennen brought it back. As a full RFC this time, with a working patch — 50 lines of C, ninety-eight hundred thirty-six tests passing, and a sub-vote on the file extension. The reception? *Same as last time.* Matteo Beccati: "unnecessary complication for practically no real-world benefit." Kamil Tekiela took the motivation apart piece by piece. But credit to Hendrik — instead of digging in, he conceded the weak arguments and sharpened to one honest sentence: most new PHP files are pure code, the `<?php` carries zero meaning in them, and PHP is the **only** modern mainstream language that still makes it mandatory. Then he asked the room to tell him plainly — is the friction worth solving, is the mechanism wrong, or is it just not a real problem? *That's* how you run a discussion. [SLIDE 07 — function autoloading, mark 5] Paul Jones opened — and I'm quoting his own subject line — "Function Autoloading, mark 5." The fifth crack at letting PHP autoload functions the way it autoloads classes. Rob Landers, who wrote mark 4, replied with the dry truth: "the consensus was that the SPL autoloader needs to go, and nobody wanted more added to it... maybe the list has changed its mind. Hopefully." And the early replies bring real concerns: Anton Smirnov and Rowan Tommins both flagged the same footgun — lean on function autoloading, forget to fully-qualify a name, and your code might *accidentally* work, only because something else loaded that function first, then silently fall back to a global on the next refactor. Rowan's fix: a `declare()` at the top of the file that pins how unqualified names resolve. Function autoloading is PHP's *white whale* , and attempt 5 is already drawing the hard questions. [SLIDE 08 — the votes that failed] Now — voting season. A lot of votes were live this week, and it was *brutal* at the top end. We covered generics. Two more are going down with it. Nicolas Grekas put his `__exists()` method to a vote — a genuinely clever fix: a magic method that finally lets an object tell a property set to `null` apart from one that doesn't exist at all, the way `array_key_exists()` does for arrays. Beautifully argued RFC. The result so far: 0 yes, 9 no, 5 abstain. Sometimes the list just doesn't want the extra magic. And Daniel Scherzer's `ReflectionAttribute::getCurrent()` — which lets an attribute know what it's attached to — is failing 2 to 5, with Larry, Ocramius, and Benjamin Außenhofer all pushing an interface-based alternative instead. [SLIDE 09 — the votes that passed] But the smaller, focused stuff is *sailing through* . Tim Düsterhus's RFC to deprecate returning values from constructors and destructors: 23 to nothing. Weilin Du's `Locale` display-keyword additions: 6 to nothing. Jakub Zelenka's Polling API already passed, 33 to 1, and it's merged. And a **security win** — Sjoerd Langkemper's RFC to cap `php://filter` chains at 16, which shuts down a nasty local-file-inclusion-to-remote-code-execution trick, is cruising at 26 to nothing. The pattern's hard to miss: tight, well-scoped proposals pass easily; the ambitious, magic-heavy ones are getting turned away. [SLIDE 10 — SNMP, a follow-up] A human follow-up, and a good one. Last week we flagged Steven Wilton, who'd shipped an SNMP module RFC and gotten total silence — "someone go help the man." This week, someone **did** . Tim Düsterhus picked it up: he leveled with Steven that SNMP is niche enough that reviewers are scarce, said he couldn't do it himself — and then went and recruited one in the Foundation Slack. He left Steven a concrete checklist: rebase, undraft the ready PRs, link the RFC. Steven did all of it within 2 days. The PRs are now waiting on a reviewer. The list came through. [SLIDE 11 — working groups & the Foundation] On governance: Ben Ramsey's Working Groups RFC came **roaring back** this week. The idea — let the project charter small teams with real authority, so not everything needs a full-list vote. Tim Düsterhus still isn't sold; he thinks the RFC process already covers it. But the spicy moment came when Alex Rock floated whether PHP Foundation staff should be barred from voting on RFCs. Larry shut that down *hard* : "the Foundation employs a majority of the people who really understand the engine — excluding them from voting would be project suicide. The Foundation has no vote. The people who do half the work, who happen to work for the Foundation, have votes. As they should." [SLIDE 12 — modules, still churning] The modules saga *refuses to die* , and it's spinning off children. Alex Rock extended his proposal with Packages — Rust-style crates, with package-level visibility. And Michael Morris opened a whole new thread called "Containers," arguing that "namespaces in PHP are a bit of a hack" and floating containers as cleaner encapsulation. Rowan Tommins and Alex Rock are both in there. No RFC yet — this one's still at the whiteboard. But the appetite for **real encapsulation** in PHP clearly isn't going away. [SLIDE 13 — closures & docs] Two quieter movers. Nicolas Grekas's serializable-closures RFC — fixing the fact that `8.5`'s attribute closures silently break `serialize()`-based caches — got its first real review from Tim Düsterhus, who wants it split in two and thinks the security model is more cautious than it needs to be. And Jordi Kroon announced he'll open voting **Friday, June 19** , on pulling third-party extension docs — `imagick`, `redis`, `mongodb` — out of the main PHP manual. Watch for that one to go live. [SLIDE 14 — quick hits] Quick hits. Xavier Leune wants to expose `libcurl`'s socket callbacks so you can do SSRF filtering natively — validate the peer IP before connect — without dropping to FFI. A newcomer pitched a `get_favicon()` function and got the classic welcome: Kamil Tekiela asking, politely, what problem it actually solves. Larry and Ilija's 5-year-old Pattern Matching RFC picked up sharp new feedback on whether a failed match should be able to fail silently. And Roman Pronskiy revised his social-media policy to add a "discretion" principle — the team can refuse a platform that's a bad fit — a quiet echo of the X.com fight from last week. And fresh overnight: Jorg Sowa's case-sensitive-PHP revival drew immediate fire. Rob Landers, flatly — "I honestly can't think of anything good that this RFC would bring" — while others flagged the *casing salad* in PHP's own built-ins, where `DateTime`, `PDO`, and `mysqli` already disagree, as the real sticking point. [SLIDE 15 — end slate] That's the week — and a heavy one: a generics vote going down, 3 RFCs rejected, 4 passed, and a modules debate that keeps multiplying. Links to every thread are below. We're Artisan Build. See you next week.

submitted by /u/ProjektGopher
[link] [comments]