Oniguruma maintenance was ended on 2025-04-24

php.internals

youkidearitai

1 year ago
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) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------

Anton Smirnov

1 year ago
On 30/04/2025 08:05, youkidearitai wrote:
> 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. >
Onigmo seems to be abandoned too, with no meaningful commits in 5 years

youkidearitai

1 year ago
2025年4月30日(水) 17:13 Anton Smirnov <sandfox@sandfox.me>:
> > On 30/04/2025 08:05, youkidearitai wrote: > > 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. > > > > 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) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------

Peter Kokot

1 year ago
On Wed, 30 Apr 2025 at 11:04, youkidearitai <youkidearitai@gmail.com> wrote:
> 2025年4月30日(水) 17:13 Anton Smirnov <sandfox@sandfox.me>: > > > > On 30/04/2025 08:05, youkidearitai wrote: > > > 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. > > > > > > > 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) > - https://tekitoh-memdhoi.info > - https://github.com/youkidearitai > ----------------------------- >
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.

youkidearitai

1 year ago
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>: >> > >> > On 30/04/2025 08:05, youkidearitai wrote: >> > > 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. >> > > >> > >> > 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) >> - https://tekitoh-memdhoi.info >> - https://github.com/youkidearitai >> ----------------------------- > > > 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) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------

Peter Kokot

1 year ago
On Tue, 15 Jul 2025 at 10:06, youkidearitai <youkidearitai@gmail.com> wrote:
> 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>: > >> > > >> > On 30/04/2025 08:05, youkidearitai wrote: > >> > > 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. > >> > > > >> > > >> > 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) > >> - https://tekitoh-memdhoi.info > >> - https://github.com/youkidearitai > >> ----------------------------- > > > > > > 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) > - https://tekitoh-memdhoi.info > - https://github.com/youkidearitai > ----------------------------- >
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.

Niels Dossche

1 year ago
On 15/07/2025 09:26, youkidearitai 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. How many times have we unbundled extensions from PHP because they were unmaintained? Kind regards Niels

Jakub Zelenka

1 year ago
On Tue, Jul 15, 2025 at 6:44 PM Niels Dossche <dossche.niels@gmail.com> wrote:
> On 15/07/2025 09:26, youkidearitai 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

youkidearitai

1 year ago
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: >> >> On 15/07/2025 09:26, youkidearitai 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 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) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------

Peter Kokot

1 year ago
On Fri, 18 Jul 2025 at 03:01, youkidearitai <youkidearitai@gmail.com> wrote:
> 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: > >> > >> On 15/07/2025 09:26, youkidearitai 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 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) > - https://tekitoh-memdhoi.info > - https://github.com/youkidearitai > -----------------------------
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.

Calvin Buckley

1 year ago
On Jul 22, 2025, at 6:10 AM, Peter Kokot <petk@php.net> wrote:
> > 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.

Derick Rethans

1 year ago
On Wed, 30 Apr 2025, youkidearitai wrote:
> 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
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