Add PHP 8.4 support in a PHP >= 5.1 compatible way

[dregad]

• This re-does @xabbuh's commit 7b307a9 (PR [PHP 8.4] Fixes for implicit nullability deprecation #868)
• Alternative to @MyIgel's PR Add PHP 8.4 support for 1.7.x by dropping support for PHP < 7.1 #899.

I believe mine is the better approach for the 1.7.x branch (which still officially supports PHP 5.3 and later) as it maintains backwards-compatibility for anyone still using PHP < 7.1.

I hope this can be merged quickly, and a new release tagged. Thanks in advance, and let me know if there is anything else I can do to speed that up.

[dregad]

🟢 Build is passing for all PHP versions now

I'm not sure why the workflow is running on my fork and not here though, is that normal ?

[xabbuh]

This is a BC break as the method can no longer be called with null as the second argument anymore.

[xabbuh]

same here

[dregad]

@xabbuh you're absolutely right, I am well aware of that. BUT:

1. it's only changing the signature of a protected method, not a public interface, so impact to the outside world is limited to extension classes that actually overload one or more of these 3 methods - blockCode(), blockSetextHeader() or blockTable() - so most likely a very small population
2. the fix is very simple: just adapt the signature of overloaded function to match, and make sure you send the parent an empty array instead of null. So in my opinion the impact and risk are quite low, and with a clear message in the release notes, acceptable.

As an added side benefit, we have stronger typing (array instead of array|null).

For SemVer compliance, considering that a protected function is technically not a public API:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API.

I believe this could be released as 1.8.0, with a clear message in the release notes. I am willing to draft it if you want.

In any case, there is absolutely no way to fix 8.4 compatibility without some minor BC break, so if you disagree with my proposal, at least take your pick from one of the alternatives:

• @MyIgel's PR Add PHP 8.4 support for 1.7.x by dropping support for PHP < 7.1 #899, which proposes another kind of BC break: increasing minimum PHP version to 7.1 which IMO is more impacting than this (but that's debatable), and passing the drop of PHP 5.x compatibility would be hard to qualify as a SemVer minor version change.
• Release master branch as 2.0.0: of course this would be ideal actually, but unfortunately that seems to have completely stalled since November (see discussion in Merge 1.8.x-beta into master #881)

Status quo is not an option.

[MyIgel]

Regarding the 2.0.0 release: Is there anything that needs help / a plan going forward so that this could be an option too?

[dregad]

@erusev could this please be merged, and a new version released ? Let me know if I can help.

[Evgeny1973]

What are we waiting for?

[BenjaminHoegh]

These changes are easy for us to adopt in extensions, so I see no issue here

[BenjaminHoegh]

I have to ask tho, why 5.1? supporting anything below 7.4 should not be a thing

[dregad]

I have to ask tho, why 5.1? supporting anything below 7.4 should not be a thing

IIRC at some point someone requested that there should be no BC break in 1.7.x hotfix hence not changing the PHP compatibility.

But I agree that in 2025 it doesn't make much sense.

[dregad]

Parsedown 1.7.5 with PHP 8.4/8.5 compatibility was released in the parsedown/parsedown fork (implementing this PR).