[PHP-DEV] Oniguruma maintenance was ended on 2025-04-24

Mailing Lists php.internals
1

Hi, Internals

Oniguruma(鬼車) maintenance was ended on April 24, 2025.

This library uses mbregex in php-src.

There is forked library in Onigumo(鬼雲).

How do we do that?
- Move to Onigumo
- Stay in Oniguruma
- Deprecate mbregex functions

I created issue in php-src too.

Regards
Yuya.

--
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- youkidearitai (tekimen) · GitHub
-----------------------------

2

---------- Forwarded message ---------
From: David CARLIER <devnexen@gmail.com>
Date: Wed, 30 Apr 2025 at 06:20
Subject: Re: [PHP-DEV] Oniguruma maintenance was ended on 2025-04-24
To: youkidearitai <youkidearitai@gmail.com>

Hi youkidearitai.

I would be in favor on moving to whatever viable solution in the long run appears (e.g. being at least available in packages distros).
However, it might be best to remain with oniguruma for the time being. It might end up as separated from php tree, who knows ?

Just my 2 cents.

On Wed, 30 Apr 2025 at 06:07, youkidearitai <youkidearitai@gmail.com> 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.

–

Yuya Hamada (tekimen)

3

On 30/04/2025 08:05, youkidearitai wrote:

Hi, Internals

Oniguruma(鬼車) maintenance was ended on April 24, 2025.
GitHub - kkos/oniguruma: regular expression library
This library uses mbregex in php-src.

There is forked library in Onigumo(鬼雲).
GitHub - k-takata/Onigmo: Onigmo is a regular expressions library forked from Oniguruma.

How do we do that?
- Move to Onigumo
- Stay in Oniguruma
- Deprecate mbregex functions

I created issue in php-src too.
Oniguruma maintenance was ended 2025-04-24 · Issue #18467 · php/php-src · GitHub

Regards
Yuya.

Onigmo seems to be abandoned too, with no meaningful commits in 5 years

4

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.
> GitHub - kkos/oniguruma: regular expression library
> This library uses mbregex in php-src.
>
> There is forked library in Onigumo(鬼雲).
> GitHub - k-takata/Onigmo: Onigmo is a regular expressions library forked from Oniguruma.
>
> How do we do that?
> - Move to Onigumo
> - Stay in Oniguruma
> - Deprecate mbregex functions
>
> I created issue in php-src too.
> Oniguruma maintenance was ended 2025-04-24 · Issue #18467 · php/php-src · GitHub
>
> 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
- youkidearitai (tekimen) · GitHub
-----------------------------

5

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)

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.

6

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.
> > GitHub - kkos/oniguruma: regular expression library
> > This library uses mbregex in php-src.
> >
> > There is forked library in Onigumo(鬼雲).
> > GitHub - k-takata/Onigmo: Onigmo is a regular expressions library forked from Oniguruma.
> >
> > How do we do that?
> > - Move to Onigumo
> > - Stay in Oniguruma
> > - Deprecate mbregex functions
> >
> > I created issue in php-src too.
> > Oniguruma maintenance was ended 2025-04-24 · Issue #18467 · php/php-src · GitHub
> >
> > 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
- youkidearitai (tekimen) · GitHub
-----------------------------

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
(Oniguruma maintenance was ended 2025-04-24 · Issue #18467 · php/php-src · GitHub),
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
- youkidearitai (tekimen) · GitHub
-----------------------------

7

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)

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.

8

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
(Oniguruma maintenance was ended 2025-04-24 · Issue #18467 · php/php-src · GitHub),
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

9

On Wed, 30 Apr 2025, youkidearitai wrote:

Hi, Internals

Oniguruma(鬼車) maintenance was ended on April 24, 2025.
GitHub - kkos/oniguruma: regular expression library
This library uses mbregex in php-src.

There is forked library in Onigumo(鬼雲).
GitHub - k-takata/Onigmo: Onigmo is a regular expressions library forked from Oniguruma.

How do we do that?
- Move to Onigumo
- Stay in Oniguruma
- Deprecate mbregex functions

I created issue in php-src too.
Oniguruma maintenance was ended 2025-04-24 · Issue #18467 · php/php-src · GitHub

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: Xdebug: Support

mastodon: @derickr@phpc.social @xdebug@phpc.social

10

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

11

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
> (Oniguruma maintenance was ended 2025-04-24 · Issue #18467 · php/php-src · GitHub),
> 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.

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
- youkidearitai (tekimen) · GitHub
-----------------------------

12

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)

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.

13

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.

14

On Tue, 22 Jul 2025 at 15:09, Calvin Buckley <calvin@cmpct.info> wrote:

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.

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.

15

2025年7月23日(水) 0:24 Peter Kokot <petk@php.net>:

On Tue, 22 Jul 2025 at 15:09, Calvin Buckley <calvin@cmpct.info> wrote:

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.

Here it's marked as deprecated and has expiration date: FreshPorts -- devel/oniguruma: Regular expressions library compatible with POSIX/GNU/Perl

Well, of course not anywhere soon and everywhere, but eventually probably.

Hi

Anyway, I create a Pull Request.

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)
- https://tekitoh-memdhoi.info
- youkidearitai (tekimen) · GitHub
-----------------------------