Hi, Internals
Oniguruma(鬼車) maintenance was ended on April 24, 2025.
https://github.com/kkos/oniguruma
This library uses mbregex in php-src.
There is forked library in Onigumo(鬼雲).
https://github.com/k-takata/Onigmo
How do we do that?
- Move to Onigumo
- Stay in Oniguruma
- Deprecate mbregex functions
I created issue in php-src too.
https://github.com/php/php-src/issues/18467
Regards
Yuya.
--
Yuya Hamada (tekimen)
Hi, Internals
Oniguruma(鬼車) maintenance was ended on April 24, 2025.
https://github.com/kkos/oniguruma
This library uses mbregex in php-src.There is forked library in Onigumo(鬼雲).
https://github.com/k-takata/OnigmoHow do we do that?
- Move to Onigumo
- Stay in Oniguruma
- Deprecate mbregex functions
I created issue in php-src too.
https://github.com/php/php-src/issues/18467Regards
Yuya.
Onigmo seems to be abandoned too, with no meaningful commits in 5 years
2025年4月30日(水) 17:13 Anton Smirnov sandfox@sandfox.me:
Hi, Internals
Oniguruma(鬼車) maintenance was ended on April 24, 2025.
https://github.com/kkos/oniguruma
This library uses mbregex in php-src.There is forked library in Onigumo(鬼雲).
https://github.com/k-takata/OnigmoHow do we do that?
- Move to Onigumo
- Stay in Oniguruma
- Deprecate mbregex functions
I created issue in php-src too.
https://github.com/php/php-src/issues/18467Regards
Yuya.Onigmo seems to be abandoned too, with no meaningful commits in 5 years
Hi,
Yes, Onigmo is only supported to Unicode 11.0. Seems Onigumo abandoned too.
Found more one way to "include Oniguruma again" when Japanese users discussions.
However, this way is difficult because that means we maintenance Oniguruma.
Regards
Yuya
Yuya Hamada (tekimen)
2025年4月30日(水) 17:13 Anton Smirnov sandfox@sandfox.me:
Hi, Internals
Oniguruma(鬼車) maintenance was ended on April 24, 2025.
https://github.com/kkos/oniguruma
This library uses mbregex in php-src.There is forked library in Onigumo(鬼雲).
https://github.com/k-takata/OnigmoHow do we do that?
- Move to Onigumo
- Stay in Oniguruma
- Deprecate mbregex functions
I created issue in php-src too.
https://github.com/php/php-src/issues/18467Regards
Yuya.Onigmo seems to be abandoned too, with no meaningful commits in 5 years
Hi,
Yes, Onigmo is only supported to Unicode 11.0. Seems Onigumo abandoned too.
Found more one way to "include Oniguruma again" when Japanese users
discussions.
However, this way is difficult because that means we maintenance Oniguruma.Regards
Yuya
Yuya Hamada (tekimen)
What about bundling Oniguruma to php-src/ext/mbstring/oniguruma again as it
once was already? This would make development easier to be located inside
php-src. However, everything put inside php-src has a questionable future
on its own. For example, to be buildable as a standalone library and used
elsewhere.
2025年6月19日(木) 3:45 Peter Kokot petk@php.net:
2025年4月30日(水) 17:13 Anton Smirnov sandfox@sandfox.me:
Hi, Internals
Oniguruma(鬼車) maintenance was ended on April 24, 2025.
https://github.com/kkos/oniguruma
This library uses mbregex in php-src.There is forked library in Onigumo(鬼雲).
https://github.com/k-takata/OnigmoHow do we do that?
- Move to Onigumo
- Stay in Oniguruma
- Deprecate mbregex functions
I created issue in php-src too.
https://github.com/php/php-src/issues/18467Regards
Yuya.Onigmo seems to be abandoned too, with no meaningful commits in 5 years
Hi,
Yes, Onigmo is only supported to Unicode 11.0. Seems Onigumo abandoned too.
Found more one way to "include Oniguruma again" when Japanese users discussions.
However, this way is difficult because that means we maintenance Oniguruma.Regards
Yuya
Yuya Hamada (tekimen)
What about bundling Oniguruma to php-src/ext/mbstring/oniguruma again as it once was already? This would make development easier to be located inside php-src. However, everything put inside php-src has a questionable future on its own. For example, to be buildable as a standalone library and used elsewhere.
Hi,
Surely, I think make sense to be include inside php-src.
From GitHub comment
(https://github.com/php/php-src/issues/18467#issuecomment-3044192511),
FreeBSD will end to maintenance Oniguruma in 2026-12-01.
Therefore, I think re-include Oniguruma inside php-src.
Is require an RFC if re-include Oniguruma?
Regards
Yuya
--
Yuya Hamada (tekimen)
2025年6月19日(木) 3:45 Peter Kokot petk@php.net:
On Wed, 30 Apr 2025 at 11:04, youkidearitai youkidearitai@gmail.com
wrote:2025年4月30日(水) 17:13 Anton Smirnov sandfox@sandfox.me:
Hi, Internals
Oniguruma(鬼車) maintenance was ended on April 24, 2025.
https://github.com/kkos/oniguruma
This library uses mbregex in php-src.There is forked library in Onigumo(鬼雲).
https://github.com/k-takata/OnigmoHow do we do that?
- Move to Onigumo
- Stay in Oniguruma
- Deprecate mbregex functions
I created issue in php-src too.
https://github.com/php/php-src/issues/18467Regards
Yuya.Onigmo seems to be abandoned too, with no meaningful commits in 5
yearsHi,
Yes, Onigmo is only supported to Unicode 11.0. Seems Onigumo abandoned
too.Found more one way to "include Oniguruma again" when Japanese users
discussions.
However, this way is difficult because that means we maintenance
Oniguruma.Regards
Yuya
Yuya Hamada (tekimen)
What about bundling Oniguruma to php-src/ext/mbstring/oniguruma again as
it once was already? This would make development easier to be located
inside php-src. However, everything put inside php-src has a questionable
future on its own. For example, to be buildable as a standalone library and
used elsewhere.Hi,
Surely, I think make sense to be include inside php-src.
From GitHub comment
(https://github.com/php/php-src/issues/18467#issuecomment-3044192511),
FreeBSD will end to maintenance Oniguruma in 2026-12-01.Therefore, I think re-include Oniguruma inside php-src.
Is require an RFC if re-include Oniguruma?
Regards
Yuya--
Yuya Hamada (tekimen)
RFC would be kind of pointless to vote on something that won't be available
to download so unless there is some other way to integrate regex support in
mbstring extension, I'd say let's bundle it.
2025年6月19日(木) 3:45 Peter Kokot petk@php.net:
What about bundling Oniguruma to php-src/ext/mbstring/oniguruma again as it once was already? This would make development easier to be located inside php-src. However, everything put inside php-src has a questionable future on its own. For example, to be buildable as a standalone library and used elsewhere.
Hi,
Surely, I think make sense to be include inside php-src.
From GitHub comment
(https://github.com/php/php-src/issues/18467#issuecomment-3044192511),
FreeBSD will end to maintenance Oniguruma in 2026-12-01.Therefore, I think re-include Oniguruma inside php-src.
Is require an RFC if re-include Oniguruma?
Hi
Yes.
This also won't solve the problem.
The problem is that Oniguruma is currently not maintained, not that it's unavailable. Bundling the library inside PHP does not solve that maintenance problem.
How many times have we unbundled extensions from PHP because they were unmaintained?
Kind regards
Niels
On Tue, Jul 15, 2025 at 6:44 PM Niels Dossche dossche.niels@gmail.com
wrote:
2025年6月19日(木) 3:45 Peter Kokot petk@php.net:
What about bundling Oniguruma to php-src/ext/mbstring/oniguruma again
as it once was already? This would make development easier to be located
inside php-src. However, everything put inside php-src has a questionable
future on its own. For example, to be buildable as a standalone library and
used elsewhere.Hi,
Surely, I think make sense to be include inside php-src.
From GitHub comment
(https://github.com/php/php-src/issues/18467#issuecomment-3044192511),
FreeBSD will end to maintenance Oniguruma in 2026-12-01.Therefore, I think re-include Oniguruma inside php-src.
Is require an RFC if re-include Oniguruma?
Hi
Yes.
This also won't solve the problem.
The problem is that Oniguruma is currently not maintained, not that it's
unavailable. Bundling the library inside PHP does not solve that
maintenance problem.
Well bundling effectively means that PHP teams is responsible for fixing
(at least the security) issues. So in some way it solves the problem for
users. The question is whether the maintenance burden that it adds is worth
it.
Kind regards,
Jakub
2025年7月16日(水) 21:37 Jakub Zelenka bukka@php.net:
2025年6月19日(木) 3:45 Peter Kokot petk@php.net:
What about bundling Oniguruma to php-src/ext/mbstring/oniguruma again as it once was already? This would make development easier to be located inside php-src. However, everything put inside php-src has a questionable future on its own. For example, to be buildable as a standalone library and used elsewhere.
Hi,
Surely, I think make sense to be include inside php-src.
From GitHub comment
(https://github.com/php/php-src/issues/18467#issuecomment-3044192511),
FreeBSD will end to maintenance Oniguruma in 2026-12-01.Therefore, I think re-include Oniguruma inside php-src.
Is require an RFC if re-include Oniguruma?
Hi
Yes.
This also won't solve the problem.
The problem is that Oniguruma is currently not maintained, not that it's unavailable. Bundling the library inside PHP does not solve that maintenance problem.Well bundling effectively means that PHP teams is responsible for fixing (at least the security) issues. So in some way it solves the problem for users. The question is whether the maintenance burden that it adds is worth it.
Kind regards,
Jakub
Hi, all
Thanks for response.
Niels, Peter
I see. We dropped many extensions abandonment libraries in the past.
Maybe Oniguruma(mbregex) drop is make sense.
Considering that (I hope/think) most developers have moved to UTF-8 for their encoding
Yes, Derick. I hope that we are moving forward to Unicode too.
how useful is it to have a separate (and
not-comptible-with-PCRE) regular expression engine still?
I don't know how useful is Oniguruma(mbregex).
But seems many uses it.
https://github.com/search?q=mb_ereg+language%3APHP&type=code&l=PHP
Anyway, I agree simple regex engine, Only PCRE.
Jakub
Well bundling effectively means that PHP teams is responsible for fixing (at least the security) issues.
Yes, that's right.
Therefore, I said ambiguous my position(drop support mbregex or still
support in re-include Oniguruma).
However, I want to support PCRE and drop support mbregex.
Regards
(Sorry for the weird way to respond)
Yuya
Yuya Hamada (tekimen)
2025年7月16日(水) 21:37 Jakub Zelenka bukka@php.net:
On Tue, Jul 15, 2025 at 6:44 PM Niels Dossche dossche.niels@gmail.com
wrote:2025年6月19日(木) 3:45 Peter Kokot petk@php.net:
What about bundling Oniguruma to php-src/ext/mbstring/oniguruma
again as it once was already? This would make development easier to be
located inside php-src. However, everything put inside php-src has a
questionable future on its own. For example, to be buildable as a
standalone library and used elsewhere.Hi,
Surely, I think make sense to be include inside php-src.
From GitHub comment
(https://github.com/php/php-src/issues/18467#issuecomment-3044192511
),
FreeBSD will end to maintenance Oniguruma in 2026-12-01.Therefore, I think re-include Oniguruma inside php-src.
Is require an RFC if re-include Oniguruma?
Hi
Yes.
This also won't solve the problem.
The problem is that Oniguruma is currently not maintained, not that
it's unavailable. Bundling the library inside PHP does not solve that
maintenance problem.Well bundling effectively means that PHP teams is responsible for fixing
(at least the security) issues. So in some way it solves the problem for
users. The question is whether the maintenance burden that it adds is worth
it.Kind regards,
Jakub
Hi, all
Thanks for response.
Niels, Peter
I see. We dropped many extensions abandonment libraries in the past.
Maybe Oniguruma(mbregex) drop is make sense.Considering that (I hope/think) most developers have moved to UTF-8 for
their encodingYes, Derick. I hope that we are moving forward to Unicode too.
how useful is it to have a separate (and
not-comptible-with-PCRE) regular expression engine still?I don't know how useful is Oniguruma(mbregex).
But seems many uses it.
https://github.com/search?q=mb_ereg+language%3APHP&type=code&l=PHPAnyway, I agree simple regex engine, Only PCRE.
Jakub
Well bundling effectively means that PHP teams is responsible for fixing
(at least the security) issues.Yes, that's right.
Therefore, I said ambiguous my position(drop support mbregex or still
support in re-include Oniguruma).
However, I want to support PCRE and drop support mbregex.Regards
(Sorry for the weird way to respond)Yuya
Yuya Hamada (tekimen)
I still think that Oniguruma needs to be bundled to make builds simpler.
Deprecating this part of the mbstring extension will take until PHP 9 to be
able to remove it (at least according to current PHP practices -
deprecation and removal phase). And in the meantime PHP can be at least
built with Oniguruma. Otherwise, there will be a situation where PHP 8.5
will have the option to enable mbregex functionality, while Oniguruma can't
be found in the distribution packages (not downloadable through
packages). If these functions can be replaced with the PCRE regular
expressions, that's fantastic.
I still think that Oniguruma needs to be bundled to make builds simpler. Deprecating this part of the mbstring extension will take until PHP 9 to be able to remove it (at least according to current PHP practices - deprecation and removal phase). And in the meantime PHP can be at least built with Oniguruma. Otherwise, there will be a situation where PHP 8.5 will have the option to enable mbregex functionality, while Oniguruma can't be found in the distribution packages (not downloadable through packages). If these functions can be replaced with the PCRE regular expressions, that's fantastic.
I'm not sure if distros will drop oniguruma just yet. It's a reasonably
popular dependency, and decrepit libraries are shipped by distros all
the time (i.e. c-client...). To say nothing of maintenance being
picked up someone.
I still think that Oniguruma needs to be bundled to make builds simpler.
Deprecating this part of the mbstring extension will take until PHP 9 to be
able to remove it (at least according to current PHP practices -
deprecation and removal phase). And in the meantime PHP can be at least
built with Oniguruma. Otherwise, there will be a situation where PHP 8.5
will have the option to enable mbregex functionality, while Oniguruma can't
be found in the distribution packages (not downloadable through packages).
If these functions can be replaced with the PCRE regular expressions,
that's fantastic.I'm not sure if distros will drop oniguruma just yet. It's a reasonably
popular dependency, and decrepit libraries are shipped by distros all
the time (i.e. c-client...). To say nothing of maintenance being
picked up someone.
Here it's marked as deprecated and has expiration date:
https://www.freshports.org/devel/oniguruma/
Well, of course not anywhere soon and everywhere, but eventually probably.
2025年7月23日(水) 0:24 Peter Kokot petk@php.net:
I still think that Oniguruma needs to be bundled to make builds simpler. Deprecating this part of the mbstring extension will take until PHP 9 to be able to remove it (at least according to current PHP practices - deprecation and removal phase). And in the meantime PHP can be at least built with Oniguruma. Otherwise, there will be a situation where PHP 8.5 will have the option to enable mbregex functionality, while Oniguruma can't be found in the distribution packages (not downloadable through packages). If these functions can be replaced with the PCRE regular expressions, that's fantastic.
I'm not sure if distros will drop oniguruma just yet. It's a reasonably
popular dependency, and decrepit libraries are shipped by distros all
the time (i.e. c-client...). To say nothing of maintenance being
picked up someone.Here it's marked as deprecated and has expiration date: https://www.freshports.org/devel/oniguruma/
Well, of course not anywhere soon and everywhere, but eventually probably.
Hi
Anyway, I create a Pull Request.
https://github.com/php/php-src/pull/19258
Honestly, this PR is not good, too ugly.
I've come to want to abandon maintenance.
(I want to deprecate in PHP 8.x and abandon in PHP 9)
I've already receive not good reaction.
I don't know how do I do maintain mbregex...
Regards
Yuya
--
Yuya Hamada (tekimen)
Hi, Internals
Oniguruma(鬼車) maintenance was ended on April 24, 2025.
https://github.com/kkos/oniguruma
This library uses mbregex in php-src.There is forked library in Onigumo(鬼雲).
https://github.com/k-takata/OnigmoHow do we do that?
- Move to Onigumo
- Stay in Oniguruma
- Deprecate mbregex functions
I created issue in php-src too.
https://github.com/php/php-src/issues/18467
Considering that (I hope/think) most developers have moved to UTF-8 for
their encoding, how useful is it to have a separate (and
not-comptible-with-PCRE) regular expression engine still?
I don't know how much oniguruma adds on top of PCRE, but PCRE also has
had significant improvements for UTF-8 encoded strings since we first
added mbstring/mbregex.
Wouldn't a replacement for:
mb_regex_encoding($fromEncoding);
mb_ereg_match($pattern, $string);
be:
pcre_match($patern, iconv($fromEncoding, 'UTF-8', $string));
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social