# Oniguruma maintenance was ended on 2025-04-24 - Thread: https://externals.io/message/127245 - Original archive: https://news-web.php.net/php.internals/127245 - Started by youkidearitai on 2025-04-30T05:05:02+00:00 - Messages: 15 - RFC: Oniguruma maintenance end and end of mbregex (Implemented (PHP 8.6)) — https://externals.io/rfc/eol-oniguruma.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #127245 — youkidearitai — 2025-04-30T05:05:02+00:00 URL: https://externals.io/message/127245#127245 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 --- ## #127246 — David CARLIER — 2025-04-30T05:20:42+00:00 URL: https://externals.io/message/127245#127246 ---------- Forwarded message --------- From: David CARLIER Date: Wed, 30 Apr 2025 at 06:20 Subject: Re: [PHP-DEV] Oniguruma maintenance was ended on 2025-04-24 To: youkidearitai 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. > 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 --- ## #127248 — Anton Smirnov — 2025-04-30T08:10:22+00:00 URL: https://externals.io/message/127245#127248 · In reply to: #127245 > 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 --- ## #127249 — youkidearitai — 2025-04-30T08:24:30+00:00 URL: https://externals.io/message/127245#127249 · In reply to: #127248 2025年4月30日(水) 17:13 Anton Smirnov : > > > > […] > > 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 --- ## #127713 — Peter Kokot — 2025-06-18T18:41:20+00:00 URL: https://externals.io/message/127245#127713 · In reply to: #127249 > 2025年4月30日(水) 17:13 Anton Smirnov : > > […] > > 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. --- ## #128046 — youkidearitai — 2025-07-15T07:26:17+00:00 URL: https://externals.io/message/127245#128046 · In reply to: #127713 2025年6月19日(木) 3:45 Peter Kokot : > > > > […] > > > 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 --- ## #128048 — Peter Kokot — 2025-07-15T10:58:05+00:00 URL: https://externals.io/message/127245#128048 · In reply to: #128046 > 2025年6月19日(木) 3:45 Peter Kokot : > > […] > wrote: > > […] > years > > […] > too. > > […] > discussions. > > […] > Oniguruma. > > […] > 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. --- ## #128052 — Niels Dossche — 2025-07-15T16:42:50+00:00 URL: https://externals.io/message/127245#128052 · In reply to: #128046 > 2025年6月19日(木) 3:45 Peter Kokot : > > […] > > 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 --- ## #128079 — Derick Rethans — 2025-07-16T12:25:06+00:00 URL: https://externals.io/message/127245#128079 · In reply to: #127245 > 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 --- ## #128081 — Jakub Zelenka — 2025-07-16T12:31:15+00:00 URL: https://externals.io/message/127245#128081 · In reply to: #128052 On Tue, Jul 15, 2025 at 6:44 PM Niels Dossche wrote: > > > […] > 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 > > 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 --- ## #128100 — youkidearitai — 2025-07-18T00:38:37+00:00 URL: https://externals.io/message/127245#128100 · In reply to: #128081 2025年7月16日(水) 21:37 Jakub Zelenka : > > > > […] > > > 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 --- ## #128174 — Peter Kokot — 2025-07-22T09:10:49+00:00 URL: https://externals.io/message/127245#128174 · In reply to: #128100 > 2025年7月16日(水) 21:37 Jakub Zelenka : > > […] > wrote: > > […] > 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. > > […] > ), > > […] > it's unavailable. Bundling the library inside PHP does not solve that > maintenance problem. > > […] > (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. > > […] > > 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. > > > […] > their encoding > > Yes, Derick. I hope that we are moving forward to Unicode too. > > > […] > > 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 > > > […] > (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. --- ## #128179 — Calvin Buckley — 2025-07-22T13:08:58+00:00 URL: https://externals.io/message/127245#128179 · In reply to: #128174 > > 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. --- ## #128180 — Peter Kokot — 2025-07-22T15:20:21+00:00 URL: https://externals.io/message/127245#128180 · In reply to: #128179 > > > […] > 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. --- ## #128245 — youkidearitai — 2025-07-27T14:08:40+00:00 URL: https://externals.io/message/127245#128245 · In reply to: #128180 2025年7月23日(水) 0:24 Peter Kokot : > > > > […] > > > 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) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai