Talk:PHP

GA Reassessment

PHP

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Article (edit | visual edit | history) · Article talk (edit | history) · Watch • Watch article reassessment page • GAN review not found

Result: Delisted. Hog Farm _Talk 22:40, 12 February 2024 (UTC)

Multiple issues. The article is peppered with {{cn}} tags, and is largely based on primary sources (with not enough weight being given to third party sources). There is a one line section covering the PHP Foundation which should probably eithier be integrated into "History" (or removed completely). Additionally there are multiple dubious statements and promotional SEAOFBLUEs in the "Use" section while the "Security" section offers uncited WP:NOTGUIDE advice on security matters Sohom (talk) 08:24, 2 February 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

PHP

PHP could also be argumentatively agreeatively agreed to as for the acronym Personal Hypertext Protocol to not be errant regressive in acronym accuracy. ~2026-49488-72 (talk) 00:53, 13 September 2026 (UTC)

What's the point of this? It doesn't stand for that. Meters (talk) 01:04, 13 September 2026 (UTC)

critical security release

This is getting enough coverage that we can probably work it into the security section of this article. Example source: https://arstechnica.com/security/2026/10/php-maintainers-tell-web-devs-to-prepare-themselves-for-critical-security-patches/ –Novem Linguae (talk) 03:55, 21 October 2026 (UTC)

It’s large enough that multiple wiki farms/hosts have decided that it was better to be down for 13 hours than expose any potential exploit. Can’t imagine that there won’t be plenty of publicity/news about it in the coming days (in tech circles at least).

Chrisblammo123 (talk) 05:37, 21 October 2026 (UTC)

Got its own article as well: PHP2Shell. –Novem Linguae (talk) 09:01, 21 October 2026 (UTC)

Unicode

Was the native Unicode support planned for PHP 6 added in PHP 7 or later? -- Beland (talk) 16:05, 21 October 2026 (UTC)

No, the "native Unicode" branch was completely abandoned as a dead end. Pretty much all of the non-Unicode features planned for PHP 6 landed in 5.3 and 5.4, and since then so much of the engine has been rewritten that I'd be surprised if any of that original branch would be useful for anything. PHP 7 was called that precisely because it didn't contain what has originally been announced as PHP 6.

I'm sure I've seen some more recent retrospectives about the whole thing (including the anecdote that someone described the project as "making PHP a small library on the side of ICU"); I'll see if I can remember where and add some properly referenced updates to that section. - IMSoP (talk) 14:26, 22 October 2026 (UTC)

The specific code written for PHP 6 was abandoned, but what I'm asking is whether PHP now supports Unicode by default or whatever the right terminology is? That might be something that was done piecemeal in later releases or maybe there are still issues when Unicode is used? -- Beland (talk) 17:49, 22 October 2026 (UTC)

The main idea of PHP 6 was going to be that when you wrote a string like "noël", it would be stored in memory as UTF-16 (even if your source code was in UTF-8, or some "legacy" encoding); and built-in string functions would treat it as a sequence of Unicode code points, rather than a sequence of bytes. It wasn't a series of individual features, so much as a fundamental change in the core of the implementation. That's the part that was abandoned, and there has been no attempt to try anything like it since.

But, I don't think it's fair to say that means PHP "has problems with Unicode". The native strlen() function telling you that "noël" is 6 bytes is not wrong; mb_strlen() will instead tell you that it's 5 code points (one of which is a combining character); and grapheme_strlen() will tell you that it's 4 graphemes, which is probably what you'd intuitively call "characters". From that point of view, PHP's "Unicode support" has improved, and continues to improve.

Newer programming languages, which have the benefit of being created after Unicode matured, may make those different functions more obvious, so it's easier for a new user to get the answer they expect; although some languages proudly claim good Unicode support, but use code points as the default unit in contexts where graphemes would be more useful. And that's before we get into questions like what is the correct uppercase for "i"? - IMSoP (talk) 14:25, 23 October 2026 (UTC)

Ah, thanks for the clarification. Am I then correct in understanding that the limitation (which might not be a "problem" so much as an occasional inconvenience) is that there's no abstract "Unicode string" type, only strings containing characters in specific byte encodings? I guess I'm most familiar with Python, which supports both, and one has to be careful to know which is which. I think a clarification in the article would be helpful; would this be accurate?:

PHP does support using Unicode encodings for source code, but the language still (as of version 8) has no abstract "Unicode string" type. All strings are stored in a specific byte encoding, and there are functions that can distinguish between the number of bytes, Unicode points, and graphemes as needed, or convert to a different encoding.

-- Beland (talk) 05:18, 24 October 2026 (UTC)

Yes, that's exactly right :) PHP 6 would have had separate "u strings" and "b strings" very similar to Python 3. Instead, it's up to the programmer to keep track of the encoding intended in any particular string, and use the appropriate functions. Of course, ideally we'd find a good source for all this, but I think your summary is pretty much spot on. - IMSoP (talk) 11:10, 24 October 2026 (UTC)

I found some primary sources to support the explanation and added it. The Multibyte String extension does seem to provide similar functionality, but it's not integrated into the language core. -- Beland (talk) 02:30, 25 October 2026 (UTC)

Secondary sources

Now that a lot is being written about PHP in all sorts of publications, it might become easier to reference some of this article's statements (or even previously removed unsourced claims) with secondary sources rather than primary sources. We can let the dust settle a bit and check in a few weeks, of course. Nemo 08:07, 23 October 2026 (UTC)

So... what is PHP?

I read the article and still have no idea what PHP is. Like... y'all expect someone to know what a scripting language is when friggin WYSIWYG exists? Guylaen (talk) 10:05, 24 October 2026 (UTC)

Well, it's a programming language. For writing an algorithm, for example, something which is not exactly possible in WYSIWYG (but for someone with a different browser arrangement, WYSINWTS). Imaginatorium (talk) 14:16, 24 October 2026 (UTC)