#microformats 2025-05-22

2025-05-22 UTC
#
[tantek]
is anyone here using the top-of-tree php-mf2 parser or are people generally only using the official release? https://github.com/microformats/php-mf2
#
Loqi
[preview] [microformats] php-mf2: php-mf2 is a pure, generic microformats-2 parser for PHP. It makes HTML as easy to consume as JSON.
[aciccarello]1, [tw2113]1, [schmarty]1, aurailus[d], Saige_Leah[d], sisoma_new[d], aaronpk, barnaby, [tw2113] and ramsey joined the channel
#
jamesgallagher
edited /rel-edit (+534) "add brainstorming on public vs. private distinction"
(view diff)
#
capjamesg
[tantek] I have started to document the distinction above ^
#
capjamesg
If you have feedback, let me know.
#
capjamesg
I think it should go in the "Definition" section when ready.
jeremych- and Guest6 joined the channel
#
[tantek]
Good brainstorm capture
#
[tantek]
Another way we could capture things like that are "open questions"
[me1850], barnaby, [Den], [asuh], [lazcorp], duanin2 and gRegor joined the channel
#
[tantek]
how long have you been using it and any problems to report? I ask because we started discussing making a new official release
#
[lazcorp]
I'm using it as it's a dependency of indieweb/mention-client-php - been using it for about 2 years, but now PHP8.4 is demanding things that didn't exist in PHP 5.6.0
#
[lazcorp]
No problems until I upgraded to PHP 8.4
#
[lazcorp]
It's just a notice at the moment - logged at https://github.com/microformats/php-mf2/issues/268
#
Loqi
[preview] [lazaruscorporation] #268 Implicitly marking parameter $context as nullable is deprecated (PHP 8.4.5)
#
[lazcorp]
It would be great to have a new release that support modern versions of PHP - I'd help where I can
#
[tantek]
I believe we support back to PHP5.x in order to support a very wide variety of clients, including WordPress plugins which themselves want to support WordPress running on old versions of PHP
#
gRegor
Yeah. That WP share is dwindling, though. Looks like 3% total for 5.x according to https://wordpress.org/about/stats/
#
gRegor
I think last time we discussed a release we considered packaging one final php-mf2 that supports 5.x, then move forward with php7+
#
Loqi
[preview] [gRegor] Re: bumping minimum PHP in php-mf2, this is good to hear, wasn't aware of that: https://github.com/microformats/php-mf2/pull/264#issuecomment-2381926915
#
[lazcorp]
php7.1 would give support for nullable types (which I think is the issue I'm facing with PHP 8.4.5)
#
[lazcorp]
PHP 7.4 and even 8.0 have reached EOL - it might be worth (after the final 5.x release) jumping to PHP 8.2
#
gRegor
That would break in some installs of WP
#
[lazcorp]
Are the WP installs using Composer to load it? If so then they should use the 5.x release based on the required php version in composer.json
#
gRegor
Ah, that I'm not sure about. I thought it was packaged in the WP plugin. GWG?
#
gRegor
But I guess if that's the case, then it's up to the plugin dev anyway
#
gRegor
Otherwise definitely in favor of 8.2
[aciccarello] joined the channel
#
[tantek]
8.x still breaks far too much code. It's not practical for libraries
#
[tantek]
And yeah I believe it's packaged in the WP plugin (rather than loaded by Composer)
#
[tantek]
I'm still finding 8.x breakages, despite having a VERY small codebase
#
[lazcorp]
I think php 7.1 is the earliest version that introduces the features that are now required in php 8.4
#
[tantek]
I don't really understand that sentence
#
[tantek]
presumably all features are optional?
#
[tantek]
8.x broke more than any major version of PHP I've worked with. It's kinda insane
#
[lazcorp]
In PHP 8.4 implicitly marking parameters as nullable is deprecated - they have to be explicitly marked as null. So "function parse($url = null)" needs to be "function parse(string|null $url = null)" in php8.4.x
#
[lazcorp]
The problem is that support for nullable types wasn't introduced until php7.1
#
capjamesg
cccccbtrbjtvcbbtllcrnnghjhlnblibfcuejbftfdhv
#
GWG
It is packaged, as nothing in WP uses composer by default
#
capjamesg
Ignore me 🤦
#
[tantek]
oh no capjamesg lol
#
GWG
We do change the namespace to avoid collision
#
gRegor
cat on keyboard :D
#
[lazcorp]
(we have strayed back into #microformats - I feel we should probably swap back to #indieweb-dev for this discussion - apart from James' cat)
#
gRegor
php-mf2 test suite is already running against 8.1, so I would expect it to work smoothly up to that version
#
[tantek]
right, no problem raising the "works with up to" version.
#
[tantek]
I question the need for any fancy new features introduced in 7.x or 8.x though, especially for a library
#
[tantek]
bug/syntax fixes sure
#
[lazcorp]
I'm running 8.3 on my live site and it works fine, but just upgraded my dev box to 8.4.x and that's when it started complaining
#
[tantek]
and removing deprecated/dropped things
#
gRegor
If it's possible to silence deprecated warnings in just php-mf2, that might be an option. Though I'm not sure that's possible. And we'd still need to stay on top of those in dev to fix them for future releases.
#
[lazcorp]
[tantek] the problem is that a feature introduced in 7.1 is now obligatory in 8.4 (and the old pre-7.1 way of doing it is deprecated)
#
gRegor
There are ways around the nullable type thing, but we'd need to refactor some of the code to ensure methods don't sometimes get called with a null and sometimes with another type
#
[lazcorp]
if we could do that then that would be great - I'm all in favour of keeping the package working in as old a PHP version as possible
#
gRegor
7.1 minimum gives us good support with the nullable types though, so wouldn't need to refactor nearly as much
#
jkingweb
@[lazcorp] What you wrong is not quite true. foo($bar = null) is fine. foo(Baz $bar = null) is not. Removing type hints is a viable fix is one wishes to retain pre-7.1 compatibility. Those using strict mode in a 7.0 code base are out of luck, but there are probably vanishingly few of those who can't bump their requirement to 7.1.
#
[lazcorp]
@jkingweb - it's quite possible that I'm misunderstanding the problem - I logged my issue in https://github.com/microformats/php-mf2/issues/268
#
Loqi
[preview] [lazaruscorporation] #268 Implicitly marking parameter $context as nullable is deprecated (PHP 8.4.5)
#
jkingweb
Type hints were largely useless prior to PHP 7, anyway, and if what you want is IDE support, you can still write docblock annotations.
#
[lazcorp]
So it sounds like the code in mf2 - "public function parse($convertClassic = true, DOMElement $context = null) {}" breaks in php 8.4.5 _because_ it has the "DOMElement" type
#
[lazcorp]
OK, thanks - I understand now
#
[lazcorp]
But still, something needs fixing
#
[tantek]
yeah I was going to say this is not a problem I have run into with CASSIS
#
jkingweb
Using ?DOMElement would work as well, but simply omitting the type is compatible with any PHP version.
#
[tantek]
but then again I'm not big into using explicit types in scripting languages 🙂
#
[tantek]
^ exactly that "omitting the type is compatible with any PHP version"
#
[tantek]
mo' types mo' problems 😉
#
[artlung]
Mileage varies based on usage. I love and rely on types unless I decide not to.
#
[tantek]
every time I run into a scripting language error / warning about types, my response is ok, you get to be a string, and you get to be a string, and yes you also get to be a string
#
[lazcorp]
It might be worth just omitting the type declarations in the next PHP 5.x+ release - just to ensure compatibility with PHP 8.4 while we decide on the future direction?
#
gRegor
That might be simplest. We could add some type checking in methods if it's really needed, `instanceof`, `is_string`, `is_int` etc.
#
[tantek]
Yes, the approach gRegor suggests is exactly what I have had to do in the few instances where type checking was necessary.
balintm, [tw2113] and [social] joined the channel