About CI3 maintenance

[sapics]

@narfbg @lonnieezell @michalsn @MGatner @paulbalandan @samsonasik

Thank you for maintaining CI!

Recently, CI3 repository has less activities, but many users wish CI3 is maintained and support php8+, if it is possible. There are many candidates to help maintaining CI3 in forum, but no one has been selected yet. I also would like to help maintaining CI3 repository.

Anyway, I would like to talk about the future of CI3. (add maintainers, switch to 3.2.0+ or continue 3.1.12+, php8+ support, and so on)

[MGatner]

Adding maintainers would be a decision for the Foundation to make.

Personally I have no objections to the community keeping up CI3, but from a documentation and logistics standpoint I would like it to stop being the "standard" and see the majority of developers move on with CI4.

CI3 was a deeply loved framework and filled a crucial niche but its sensitivity to backwards-compatibility has kept around habits that are now 10+ years old. The larger PHP (and even larger webdev, and even even larger development) community won't take CodeIgniter seriously as long as CI3 is its iconic representation.

[sapics]

@MGatner Thank you for your response! I understand your opinion that CI4 is the standard framework and we need to wait the Foundation decision.

For me, the main problem is the "migration" from 3 to 4. The CI4 is the completely new framework, if it has the same concept. Thus, there are no simple migration. https://codeigniter4.github.io/userguide/installation/upgrade_4xx.html

My main hope is to add maintainers to bcit-ci group. If it is difficult for the Foundation to choose someone as maintainer, I would be grateful if you could let us know.

[lonnieezell]

Admittedly I've been way too busy lately so it's been a while since I checked that thread, but IIRC none of the people that volunteered to contribute had any experience, many without having even made PRs. Ideally, we'd like to see someone that has been active in the issues already.

To be honest, I have not kept a close eye on the C3 repo to see who has been active. I talked to Narf about it at one point and pointed him to the thread to see what he thought of the people, and then didn't hear back. He's been pretty busy I guess, also, but he's also the one with the most experience and guidance on that repo.

I would love to see someone(s) help out with that repo, though.

[sapics]

@lonnieezell Thank you for your response! And thank you for setting up the board in forum. I understand that CI4 members have less attention to CI3 ;)

If the recommendation is allowed, I would like to recommend @gxgpet from many candidates in forum. I am not CI specialist, but I think that @gxgpet have knowledges about CI and @gxgpet contributes from 2016. Could you check @gxgpet work? commits: https://github.com/bcit-ci/CodeIgniter/commits?author=gxgpet pull requests: https://github.com/bcit-ci/CodeIgniter/pulls?q=is%3Apr+author%3Agxgpet+ comments to issues and prs: https://github.com/bcit-ci/CodeIgniter/issues?q=commenter:gxgpet

[gxgpet]

Thank you for your statements, @sapics. Much appreciated, yet I'm not considering myself a really perfect contributor from the points of view stated here and on the forum.

I think that @narfbg is a very important and essential member of this project, and while I agree that I could, for the foreseeable future, continue to answer new issues/comments/responses/maybe even create PRs here, as well as the others could do it too, it would be great if the activity from here would be backed up/approved/checked by Andrey, in the end.

Maybe not much activity has happened around here in the past months or weeks, but let's be honest, the CI3 is in a good shape, for its stability and functionality, as it is a mature project. Because of this, I think that this version of CI is already on a good course of action, and thus, you couldn't really say that it's not maintained.

So in my opinion, there's nothing to be worried about CI3.

[sapics]

@gxgpet Thank you for your comment!

I agree that @narfbg is a important and essential member and @narfbg's knowledge, programming skill and hard work have kept CI3 stable and of high quality.

On the other hand, I'm worried that one maintainer do all the CI repository work, which puts a lot of strain on maintainer. For example, it would be a stress for maintainer to handle "how to" or "CI4 relates" issue. Besides, prs for typo do not require knowledge of php and CI, so anyone can handle it. (I'm not sure if @narfbg is stressed or not by these issues.)

One idea is to add a "sub" maintainer(s) after making the rule that only @narfbg can merge prs related to CI3 programs and publish. By adding the "sub" maintainer(s), we could get insurance for the repository to survive if we lose contact with main maintainer.

(I'm not good at English, so I use google translation. I'm sorry if I make any rude expressions or misunderstandings.)

[sapics]

I creates a patch for php8.0 and it passes all tests! I also switch from travis-ci to github actions. https://github.com/sapics/CodeIgniter/commit/9581af18a1e14b26a9febdc121221ead7e3f3305 https://github.com/sapics/CodeIgniter/actions/runs/479455234

For fixing error in mikey179/vfsstream (composer), I use my own repository as https://github.com/sapics/CodeIgniter/commit/9581af18a1e14b26a9febdc121221ead7e3f3305#diff-d2ab9925cad7eac58e0ff4cc0d251a937ecf49e4b6bf57f8b95aab76648a9d34R23. But, this is bad as official code and it also needs to set up secret environment variable in github repository, and this is the reason why I cannot create a PR now. It would be better to create a new composer package like codeigniter/vfsstream with bcit-ci/vfsStream repository. I would like to create a PR with fixing the commit, after composer codeigniter/vfsstream is made. Could someone in CI member make a new composer?

[kenjis]

@sapics Why don't you send a PR to mikey179/vfsstream? What is the error? Is it CodeIgniter specific?

[sapics]

@kenjis Currently, CI3 using mikey179/vfsstream "v1.1.0", but current version is "v1.6.8", and they are now working for "v2.x". Thus, there are no way to send a PR to old version, I think. I also guess that most of the repository owner would not accept old version's update patch.

The error is just from one line which is not specific to CodeIgniter ;) https://github.com/sapics/vfsStream/commit/00b34280d2c43edb0ad5a64719110fe7e7590350

[kenjis]

@sapics I got it. Even v1.x-dev requires PHP >=5.6.0. https://packagist.org/packages/mikey179/vfsStream#v1.x-dev Probably you're right.

[sapics]

@kenjis There were errors with v1.2.0 as #2526 😢

[sapics]

I have created followings which all tests are passed in php5.3-8.0. codeigniter31/framework in composer with repo. https://github.com/CodeIgniter31/CodeIgniter31 (EDIT: I deleted that)

I created it because I need CI3 to work with the latest PHP that can be tested for myself. Because, the currently released 3.1.11 is more than one year old and doesn't include fixes for php7.4 and php8.0. And there are no new updates or informations from the Foundation or CI members.

CAUTION The repository CodeIgniter31/CodeIgniter31 (EDIT: I deleted that) is not an official one, it is just a personal one. I do not guarantee future updates or operations of them. Please use it for a temporary tests, if anyone uses it. I recommend to wait for official release for production use.

[kenjis]

@sapics It is better to write the CAUTION in the README of the package/repository.

[MGatner]

Just my opinion, because I am unaware if there are any legal ramifications, but creating a GitHub organization intentionally mimicking an existing legal entity seems like a bad idea. You would not need your disclaimer if the code were already hosted under your personal fork.

[sapics]

I made it with the hope of helping someone, but I deleted it because I don't want it to be a legal issue.

[kenjis]

@sapics You have already published https://github.com/sapics/vfsStream/tree/v1.1.x and https://github.com/sapics/CodeIgniter/tree/jit80 Are they the same as deleted repositories under CodeIgniter31?

If so, you already would help someone who wants PHP8 compatible CodeIgniter 3.

[sapics]

@kenjis Thanks! Yes, it is the similar one which adds php80+jit tests. If it helps someone's work, I am happy :)

Some hours ago, I deleted the group and the composer, and repositories which relate to CI3. After that I forked CI3 repository, again. Sorry to CI member, if you feel bad to my action, I apologize.

[sapics]

I created pr #6014 which works well without changing composer with a bit hacky way. If someone wants to try to test in php8.0, please use #6014's commit. And we also need to merge the other pr for php8.0.

[MGatner]

@sapics you've done good work and it is worth sharing. I am not a member of the CodeIgniter Foundation nor do I have any knowledge of GitHub's legal stance. But the fact that you felt the need to put a disclaimer on the repo I think was telling. Sharing the code out of your personal account seems to me a much better approach, no disclaimer necessary. I also hope whoever is on the CI3 team will work with you on getting any appropriate changes made to the main repo.

[sapics]

Thanks @MGatner for reply! I am relieved by your reply. The PR could pass all tests in php8.0, thus, I hope CI3 will be easier to merge the other PRs.

[Tampa]

Years ago when I started with the first line of code I stumbled across a book with some recommendations for "how to release software" and one key point was made to try and create specific stable versions catering to a particular set of requirements rather than constantly changing a core part and potentially breaking or changing features in undesirable manners. This stuck with me for a long time and I think it very much applies to the underlying issue of PHP compatibility CI3 faces now.

It very much is just the opinion of the author of that book and myself, but CI3 as it stands should probably strive to achieve compatibility with the last version of PHP 7 before attempting the change to 8. A CI3.1 only really making sense as a breaking change that embraces PHP 8 changes in ways that might even require PHP 8 to function. The main reason for that is the changes made in PHP in some regards are quite severe, but also offer so much more.

I been slowly reading through the changes and following development of PHP 8 and it finally, at least seems, that the push is towards rejuvenating some older concepts and structures that were not able to adapt to the changes made since they were first thought up. A lot of these changes seem to want to make PHP 8 more relevant and less likely to develop pitfalls that can break modern application projects. It does seem odd to a veteran of PHP in a lot of ways, but seeing other languages evolve and bringing new concepts to the table it feels like the right move.

From the perspective of a hosting provider it is also easier to handle complications arising from major version changes of dependencies via discrete versions rather than constant development and I say that as a fan of the latter. It affords more time for application development when you don't have to debug due to underlying compatibility issues.

Few days ago I started looking into the same thing @sapics had, but ended up giving up trying to update all the way to 8 and instead wanted to just attempt to redo for 7.4 what was needed to take advantage of some fixes and enhancements. Not much seems to be needed for just that goal, but I am also pretty rusty with bare metal PHP nowadays. It just seemed so much more logical to let PHP 8 mature further and get the s*** tested out of it before potentially doing an upgrade and then later having to throw stuff out again as faults are found.

Again, just my point of view and advice. I'm well confident a good decision will be made and CI3 will continue to make my life easier as it has for so many years now. :)

[1stwebdesigns]

@Tampa you could well be correct. We have CI3 working fine under PHP 7.4. We won't upgrade to PHP8 until security support for 7.4 ends in November 2022, which is actually not that far away. Some assurances that CI3 will eventually support PHP8 would be nice, but I realise nobody is paying any money for CI so such an expectation cannot be justified.

[Andrewsuares]

Does anyone know what exactly is broken with CI3 on PHP 8?

[rhickmott]

Largely nothing.

I've been using CI3 on PHP8 on my dev machine for a few weeks.

Theres a couple of logic changes though such as comparing numbers to strings that have changed and behaviours in the language which need to be tested for.

Most notably affected are sessions and flash data however several fixes have been proposed but nothing merged in. The problem is nobody uses... everything! so we can't be sure and no doubt a few more will come forward.

I suppose it depends on if CI intend on supporting v3 (and PHP8) going forward to address them. Sadly CI4 isnt a option for me (yet) as the amount of work to essentially rewrite them is too large at present.

Get Outlook for Androidhttps://aka.ms/ghei36

---

From: Andrew Suares notifications@github.com Sent: Thursday, February 4, 2021 7:32:16 AM To: bcit-ci/CodeIgniter CodeIgniter@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [bcit-ci/CodeIgniter] About CI3 maintenance (#6012)

Does anyone know what exactly is broken with CI3 on PHP 8?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/bcit-ci/CodeIgniter/issues/6012#issuecomment-773097216, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADDFJ4KIBNDPMWKXHHV6R3TS5JEQBANCNFSM4VULBQIQ.

[1stwebdesigns]

Similar findings to me - I tested one of our projects in CI3 using PHP8. The most apparent thing that was broken was flash data. This was a really easy fix. I also heard that migrations are broken (I didn't test them), but again I think it's easy to fix.

We're also in the same boat, some of our CI3 projects are working well and do everything that's required, so a complete re-write in CI4 isn't justified at the moment.

[Andrewsuares]

We've deployed CI 3 on a large project. We do not use sessions and flash data. Works fine on PHP 7.3. HMVC modules makes it easy to manage all the parts of the system. The CI API works great. All in all, everything works.

Its insanely ridiculous and arrogant on how the CI foundation decided to dump v3 and move to v4. There was no good reason to kill a perfectly good framework.

[MGatner]

Its insanely ridiculous and arrogant on how the CI foundation decided to dump v3 and move to v4. There was no good reason to kill a perfectly good framework.

I think the fact that people consider version 4 a "kill" instead of an upgrade is pretty telling of the gap that version 3 created by its focus on backwards-compatibility. I've written about this on the forums but basically: backwards-compatibility is easier on developers because it makes a quicker upgrade path but I accumulates "development debt" that a future version will always need to pay for. Version 4 is paying that coin.

An example. PHP 5.3 (2009 I think?) introduced namespaces and PSR-0 established standards for namespaces and autoloading. In 2014 FIG deprecated these standards for a second set (PSR-4) which still holds today (7 years old mind you). CodeIgniter 3 was released in 2015 without native spl class loading and chose to maintain "Autoloading" as "components for the framework to initialize during bootstrap". Still to this day we get people switching to version 4 confused about autoloading, a PHP feature of 12 years and standard for 7.

Version 3 was awesome, and I still have and maintain many CI3 projects most of which are unlikely to get rewritten. But trying to keep CI3 in active development is creating legacy developers, people unfamiliar with the last ten years of improvements in PHP, web development, and coding in general.

My advice: take the time to learn CI4 (or another modern framework). Figure it out, learn what has changed in PHP, learn to collaborate on open-source libraries and work with developers outside of CI3 context. Then if you still love CI3, come back and make it better.

[rhickmott]

Oh I understand the reasoning behind it.

I don’t know what the foundations plan is with 3 and I don’t have hours to trawl though forum posts but the last time I looked it was remarkably quiet on the topic other than concerned posts. I have been using CI for a couple of Years now and used 3 as that’s what was “active”. In fact if you go to the CI Homepage and click downloads at the top it still says 3 is the current branch with 4 “upcoming” 🤷‍♂️

I fully intend to port projects and start new ones on CI4 but that takes time and meanwhile I have servers that will get upgraded to PHP8 in the next 12 months and I need to make sure projects still on CI3 will continue to run even if it means I have to patch in code to fix issues myself.

I fully understand that this is a free project and it takes time to maintain older stuff but PHP8 is unlikely to require major changes but even after months or discussion and pulls on basic stuff like the session issue were still at 3.1.11. I think many people are perplexed that support was seemingly dropped overnight last March.

Even if the foundation have no plans to support 3 themselves at least let the community maintain it and state on the downloads page that it’s a defunct branch and publicly maintained.

[gxgpet]

So let's make CI3 compatible with PHP8.

I can see that the #6013 PR is addressing the flashdata issue. Now we need it only to be merged.

As for other opinions here, there goes mine...

I suppose it depends on if CI intend on supporting v3 (and PHP8) going forward to address them. Sadly CI4 isnt a option for me (yet) as the amount of work to essentially rewrite them is too large at present.

We're also in the same boat, some of our CI3 projects are working well and do everything that's required, so a complete re-write in CI4 isn't justified at the moment.

Its insanely ridiculous and arrogant on how the CI foundation decided to dump v3 and move to v4. There was no good reason to kill a perfectly good framework.

In my opinion, CI3 should be a long-living PHP framework, which by grandfathering many things that made this framework famous, won't follow today's trends (usually called "standards", "PSRs", and so on). If anyone requires those, then you should go with CI4. By the way, having CI3 doesn't force your code to be written in a certain way. You can use whatever you want for your app code.

In fact, if you look at every PHP framework from the present day, it makes this ecosystem to be full of just copy-cat software. Has anyone from here used a JavaScript framework? Like AngularJS, Vue JS or React? They are fundamentally different and thus, they increase the real pool of decisions you can take on deciding the one you should use.

I hardly believe that there's a PHP framework out there that does the things so different, as CI3 does. So how about thinking about diversity when thinking on CI3?

An example. PHP 5.3 (2009 I think?) introduced namespaces and PSR-0 established standards for namespaces and autoloading. In 2014 FIG deprecated these standards for a second set (PSR-4) which still holds today (7 years old mind you). CodeIgniter 3 was released in 2015 without native spl class loading and chose to maintain "Autoloading" as "components for the framework to initialize during bootstrap". Still to this day we get people switching to version 4 confused about autoloading, a PHP feature of 12 years and standard for 7.

CI3 doesn't care about PSR definition about how you should namespace the classes and how autoloading is done. Others do, such as CI4. In fact, CI3 has the "Composer autoload" feature, which enables bringing composer libraries right into CI3 instance, if you need them.

Version 3 was awesome, and I still have and maintain many CI3 projects most of which are unlikely to get rewritten. But trying to keep CI3 in active development is creating legacy developers, people unfamiliar with the last ten years of improvements in PHP, web development, and coding in general.

That has nothing to do with people's own development skills. Ah, and the "legacy" non-argument argument used for someone who doesn't blindly follow the magic unicorns out there.

CI3 is compatible up to the latest PHP 7 version. And that make it very up-to-date for the PHP language itself.

My advice: take the time to learn CI4 (or another modern framework). Figure it out, learn what has changed in PHP, learn to collaborate on open-source libraries and work with developers outside of CI3 context. Then if you still love CI3, come back and make it better.

If that fits your needs, by all means, do it (CI4 / any other "modern" framework). That's why we have out there CI3 and CI4. Because they are different. Otherwise, CI3 would have been changed until there would be no actual difference between it and CI4.

LE: The superhero of CI3, Narf, just merged #6013. :)

[Andrewsuares]

An example. PHP 5.3 (2009 I think?) introduced namespaces and PSR-0 established standards for namespaces and autoloading. In 2014 FIG deprecated these standards for a second set (PSR-4) which still holds today (7 years old mind you).

Who is FIG to dictate to me on how I run by business. Is FIG going to fund all of the extensive re-write and all of the testing involved to port my apps over to CI 4? I care about rolling out new features to give the benefit to users immediately over the shortest time possible. My userbase does not care about namespaces.

[MGatner]

the "legacy" non-argument argument used for someone who doesn't blindly follow the magic unicorns out there

@gxgpet Just to be clear, I have no issues with people running legacy code (like I said, I have plenty of projects myself) nor does "legacy" mean "bad". I am no trying to demean developers, I still work with many who write vanilla PHP and have never touched a framework. But PHP is a language, and it evolves and changes, and versions are dropped from support and projects (and developers) who stick to unsupported versions become legacy. Sometimes it's possible to patch these, but generally speaking production code is better either a) kept on the latest versions or b) not tampered with.

Who is FIG to dictate to me on how I run by business

@Andrewsuares Definitely not the intention of FIG, you do you! What FIG provides is a collaborative context for PHP developers to agree on "meta-language standards". Does that mean it is the only way to do things? No. But being able to say "PSR-7 compliant" up front saves a whole lot of time for a developer to use a project and collaborate on things. CI3 (or CI4 for that matter) need never adopt any of FIG's standards but it will come at a collaboration cost with the larger PHP community.

[MGatner]

Sorry for the spam but I also just want to inject this side comment because it has caused confusion before: I am not part of the CodeIgniter Foundation, and if I were I would not be so plain about my opinions on this topic. I am very glad these conversations are happening and I share my opinion freely and respectfully, but I don't want anyone to take it the wrong way.

[Tampa]

This is not really the point of this topic, but as someone from the background of writing straight php code for a long time looking for a framework that is both easy to understand and use, all while delivering a way to reduce workload and make it easier to write code that is sane and stable CI3 appealed the most. Other options such as Laravel, cake and what have you, similarly to CI4 in fact, just seem to make changes for the sake of change or are built for specific types of "web apps". The big appeal with CI3 is that it is relatively easy to use for php beginners and offers a way to elevate the understanding of functions and code that is flexible.

I consciously made the decision not to even bother with CI4 after looking at the docs and not even being able to gather what really changed and how I could even approach to re-create my "apps"(god it's a website not an app ffs) in CI4. CI3 on the other hand actually still brings me joy in writing code that I can re-use in a manner that feels somewhat at home with the concept of other languages such as c++ even(cpp and header files, controllers and models). At first I struggled with this concept and wrote code in view, not understanding why the complexity of three different files. However, as things got bigger being able to re-use models, alter data in controllers and output new views is really quite useful and a big strong point of CI3 I think.

To me it seems CI4 exists to please those looking for even faster, thrown together "web apps" rather than building stronger and more reliable websites and systems that can still be made very flexible. I had hoped it was more of the same, but to be so vastly different and far more "complex" is not making it easy to like. Maybe I am just lazy or not smart enough for CI4.

Back on topic. Last I checked there had been maintainers selected to handle CI3 from now on or has this changed recently? The other question for a pull request, so long as it does not go into a specific release is whether PHP8 changes are breaking toward PHP7, which pretty much determines whether a new, specific, release is needed or changes can be made and released as update.

As some have said there is no one really using all parts of CI3 and would thus be the first to notice compatibility changes. Is that not something that can be crowd-sourced though? Tests. Each user following this project or even this issue ticket might use a different part, but in this has a pretty good idea of what they use and how to notice if it does not work. Extrapolating test cases from this should not be all too difficult and then it just becomes a matter of conducting those tests. Equally either a past or current maintainer likely has a relatively good overview of the parts CI3 is comprised of and thus could provide input into a checklist of things to probe for issues.

So perhaps the first order of business should be to create a list of all parts of CI3. Then establish expected behaviors of these parts based on examples or code similarly to what users run. Lastly, change PHP and see whether results have changed and adjust accordingly, either just for PHP8 or all supported PHP versions.

[MGatner]

Maybe I am just lazy or not smart enough for CI4

I would suggest that probably the biggest thing you are noticing is "familiarity". CI4 has kept the same principles that have always guided CodeIgniter and set it apart from the Symfonies and Laravels of the world: straightforward, use-only-what-you-need, comprehensive docs, lightweight, no "magic". CI4 does look very different, because PHP looks very different, but if you spent some time on it for your apps ("websites" 🥳) you might find it less jarringly foreign.

[MGatner]

Re: PHP 8... some just needs to download the framework and slap PHPStan on it and run a static code analysis under PHP 8. That should catch 99.9% of compatibility issues.

[kenjis]

After all, it seems that no experienced developer is qualified to be an additional maintainer. So nobody can help @narfbg to develop CI3. He is an only maintainer of CI3 now.

Is this correct?

[Tampa]

Re: PHP 8... some just needs to download the framework and slap PHPStan on it and run a static code analysis under PHP 8. That should catch 99.9% of compatibility issues.

That sounds interesting, do you have some links or more info on that?

[MGatner]

Sure! You can think of static analysis like a robot that reads your code and catches problems. This can be simple things like syntax errors (echo strtolower('HI';) or more complex logic errors that still "work" ($test = false; if ($test && $someOtherThing)...). You can read more about it and play with it here: https://phpstan.org

I did a quick run-through:

git clone https://github.com/bcit-ci/CodeIgniter.git
cd CodeIgniter
composer require phpstan/phpstan
./vendor/bin/phpstan analyze application/ system/ tests/ index.php

There are a lot of issues on PHP 7.4 and 8.0 and while there are a lot of issues the list is identical, suggesting that the framework itself is as safe in PHP 8 as 7.4 (as far as static analysis goes). It looks like some of the dependencies might have issues though, like vfsStream - but I think that's known?

[otengkwame]

Conversations here really makes it clear people still love CI3. I remember I also joined in on the forum as one interested in maintaining CI3 but it did not happen, so I have decided to extend CI3 myself and use it for my personal projects and I have made the source available on GitHub.

What I did first was to pull the "system" folder and make it a composer repository "sylynder/codeigniter". I would want to know if that is bad to do. If not I decided I will visit the issues and pull request to use it to upgrade on the said repository.

I then worked on the extension and named it "Webby" which I'm still working on. I have planned to make it have a similar tradition as CI3, where only the "system" folder used to be upgraded. It is still a work in progress.

The whole idea is to help beginners and also developers who love CI3 to move to CI4 slowly because I have made it possible to use namespaces and a little mimicking the 'service()' helper function in CI4 by powering "ci()" function which uses the codeigniter instance from an external class that acts as the old known "get_instance()" function to do something similar. Still learning and upgrading my understanding on some concepts.

And I can say CI3 is very easy to extend without touching the core classes. Most extensions can be done in "core" folder and the "library" folder when you prefix it with "MY" or "Whatever". This is making what I'm working on possible.

Suggestions, coaching and advice are welcomed. If anybody is interested check it out here: https://github.com/sylynder/webby

[narfbg]

OK people, I could say a lot about a lot of what's been written here, but I'll stick to the most important part ...

First, the foundation hasn't decided anything about CI3 - it never needed to, never had to, and to my knowledge was never intended to deal with CI3 at all. I've been at the helm since forever and this is all on me.

And secondly, we (everybody who's ever been involved) have actually always been looking for more people to have on the team, but it's no surprise that you can't just pick a random person from a crowd. I believe we've found someone suitable right now in @gxgpet and he's welcome to the team. @lonnieezell As I'm not sure what adding someone to the teams we already have setup would mean in terms of access to other repos, can you sort out the proper permissions for him?

[lonnieezell]

@narfbg Awesome that you found someone! I've invited @gxgpet to the Reactor Team which gives him access to only the CodeIgniter repo, but that can always be adjusted down the road if needed.

[rhickmott]

Thanks @narfbg I'm sure I won't be the only one that will say they appreciate the work of yourself (and the other devs) in maintaining CI3 :) it's good to know the project is being maintained while everyone ports projects.

[Daniel-Monroy]

thanks for maintaining the project <3

[spitfire64]

Thanks for keeping CI3 alive. It means a lot to me and my projects 👍

[orionstar]

@narfbg Awesome that you found someone! I've invited @gxgpet to the Reactor Team which gives him access to only the CodeIgniter repo, but that can always be adjusted down the road if needed.

@gxgpet can also merge PRs in the translations repository? https://github.com/bcit-ci/codeigniter3-translations

[Andrewsuares]

@narfbg Thanks for your excellent work on CI 3. I've been testing CI 3 on PHP 8 and it works great! You've done all of this behind the scenes so thank you for that.