Extensionalize phpBB

General discussion of development ideas and the approaches taken in the 3.x branch of phpBB. The next feature release of phpBB 3 will be 3.2/Rhea followed by 3.3.
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.1. If you need support for phpBB 3.1 please visit the 3.1.x Support Forum on phpbb.com.

If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
User avatar
javiexin
Registered User
Posts: 90
Joined: Thu Dec 22, 2011 10:04 am

Re: Extensionalize phpBB

Post by javiexin » Sat Jun 03, 2017 3:56 pm

While I do understand your concerns, I think that they highly influenced by your last statement:
VSE wrote:
Sat Jun 03, 2017 3:17 pm
And the extensions team is already understaffed and overwhelmed with all of its current extensions duties.
Let's not try to be influenced by the current status of the teams, and try to think positively, even if at the end, the choice is to do nothing.

Let me try to rebate your points.
VSE wrote:
Sat Jun 03, 2017 3:17 pm
It makes releases more difficult to ship as we would be required to also manage/release multiple extensions with a phpBB release to ensure users are kept up to date, as well as distribute them with every release, making an already dificult task even more difficult for those involved in releases.
Not necessarily. The code is released today with every release, and distributed together. That does not need to change at all. Or, in case it does, it would be the same situation as with any other extension at a release change: if there is no BC break, no problem. At least within minors, this should never be an issue, unless something specific has changed, and in that case, the extra effort would be required either way, with or without extensions.
VSE wrote:
Sat Jun 03, 2017 3:17 pm
It degrades testing phpBB. phpBB's core code is continuously tested in its entirety on three separate development branches. Some minor change here could create a major bug there, and if all these componenets are removed, some phpBB development regressions will no longer be detected, and the burden on the support team will sky rocket as they get bombarded by unforseen bugs and support topics, and have to scramble to figure out why the problem is occurring by dealing with a littany of separate extensions..probelms that could have been detected during testing.
Again, not necessarily. What blocks the possibility to test the core WITH THE CORE EXTENSIONS together? The only requirement would be to have extra tests to enable/disable each new block independently, nothing really fancy. Note I have renamed these from "official" to "core" extensions, so that it does not give the impression that they are at the same category: they do not have to be treated the same way as the current official extensions are treated.
VSE wrote:
Sat Jun 03, 2017 3:17 pm
It also makes testing and devloping extensions immensely difficult. Extensions are always developed and tested and validated against fresh phpBB installations. Removing all those componenets from the core means extensions will not be tested in the complete environment they are currently. It also measn to pull off testing in a "fully loaded" board would make the lives of the testers enourmously tougher than it already is. And indicidual developers will most likely not be developing while on a "fully-loaded" install either.
The testing environment is decided by the Validation team. This would mean a change? Well... maybe, maybe not. Testing could be defined to be done with the "core" extensions enabled, or with them disabled. And in any case, the installation should not be much more difficult. Already today, the core is shipped with an enabled extension, that may be disabled by the admin later on. These could be the same, so would make NO difference when setting up a new environment for testing.
VSE wrote:
Sat Jun 03, 2017 3:17 pm
Also extensions that are continuously unit-tested will not be able to detect any bugs associated with those extensions, as they won't be part of the core phpBB installation that is used during unit testing, leading to extension authors having to support multiple new issues unforeseen, making their motivation to do this work wane.
Same assumption as above: these core extensions could/should be part of the core testing environment, so this should not be the case.
VSE wrote:
Sat Jun 03, 2017 3:17 pm
It also ensures the componenets will probably go stale as once it's out of the core, it will no longer be a primary responsibility of the development team. And the extensions team is already understaffed and overwhelmed with all of its current extensions duties.
Team definition and responsibilities may be redefined as well: if the core is smaller, the team to develop and maintain it could be smaller as well, and viceversa, if there is a new block component (core extensions), there could be a new team, or keep the responsibility in the core team, or move it to the extension team and grow that team. That is an organizative issue, not so much related to what I am proposing here, that is more architecture and componentization of the core.

Let's not focus on the organization issues for a moment, please. I understand that, in the end, for this proposal to be successful, this will have to be solved. But before we go there, we should decide whether FROM THE TECHNICAL perspective, this makes sense or not. Once that is clear, and if the view is generally positive, then we could (and should) worry about the organizative issues. But why go there, if we are still very far, in terms of conceptualizing and technically deciding about these?

Thanks a lot,
-javiexin

User avatar
david63
Registered User
Posts: 215
Joined: Mon Feb 07, 2005 7:23 am
Location: Lancashire, UK

Re: Extensionalize phpBB

Post by david63 » Sat Jun 03, 2017 6:04 pm

There is one issue that would be problematical with the current update/upgrade procedure and that is that is that extensions that need updating would need to de disabled first and then re-enabled.
David
Remember: You only know what you know -
and you do not know what you do not know!

User avatar
javiexin
Registered User
Posts: 90
Joined: Thu Dec 22, 2011 10:04 am

Re: Extensionalize phpBB

Post by javiexin » Sat Jun 03, 2017 6:18 pm

david63 wrote:
Sat Jun 03, 2017 6:04 pm
There is one issue that would be problematical with the current update/upgrade procedure and that is that is that extensions that need updating would need to de disabled first and then re-enabled.
Only those that have new migrations, or very special cases of changes in ext.php. Otherwise, it is not needed. For those case, it is possible to include a new migration that if the extension is enabled, disables it and then reenables. Very simple migration I think.

And anyhow, I think I remember seeing some code in the core to do exactly that: disable extensions before an upgrade, and then reenable them after (I think it is in the 3.1 to 3.2 upgrade, but I'm not sure).

And in any case, this is the kind of things that should be discussed after we have a clear picture of whether this is good or bad from a technical / architectural point of view.

Regards,
-javiexin

User avatar
3Di
Registered User
Posts: 694
Joined: Tue Nov 01, 2005 9:50 pm
Location: Milano (I) Frankfurt (D)
Contact:

Re: Extensionalize phpBB

Post by 3Di » Sun Jun 04, 2017 3:52 am

Interesting discusssion IMO. Me following this one.

There are pros and cons, yet the balance needs a clarification.
Want to compensate me for my interest? Don't ask me, just do it
I'm available for custom phpBB jobs, you can PM me the details.
New: my Live Board, Extensions and Tools for phpBB - Men at works.

User avatar
david63
Registered User
Posts: 215
Joined: Mon Feb 07, 2005 7:23 am
Location: Lancashire, UK

Re: Extensionalize phpBB

Post by david63 » Sun Jun 04, 2017 6:53 am

javiexin wrote:
Sat Jun 03, 2017 6:18 pm
david63 wrote:
Sat Jun 03, 2017 6:04 pm
There is one issue that would be problematical with the current update/upgrade procedure and that is that is that extensions that need updating would need to de disabled first and then re-enabled.
Only those that have new migrations, or very special cases of changes in ext.php. Otherwise, it is not needed. For those case, it is possible to include a new migration that if the extension is enabled, disables it and then reenables. Very simple migration I think.

And anyhow, I think I remember seeing some code in the core to do exactly that: disable extensions before an upgrade, and then reenable them after (I think it is in the 3.1 to 3.2 upgrade, but I'm not sure).

And in any case, this is the kind of things that should be discussed after we have a clear picture of whether this is good or bad from a technical / architectural point of view.

Regards,
-javiexin
I agree that it can be done - all I said was that with the current update/upgrade routines this is not possible, but what I would add that having seen the [large] number of users that have problems updating/upgrading then the update/upgrade routine needs to be simplified not made more complex.
David
Remember: You only know what you know -
and you do not know what you do not know!

User avatar
Ger
Registered User
Posts: 270
Joined: Mon Jul 26, 2010 1:55 pm
Location: 192.168.1.100
Contact:

Re: Extensionalize phpBB

Post by Ger » Thu Jun 08, 2017 12:00 pm

I like this idea actually. Now of course the choices of which function should be extensionalized and which shouldn't is open to debate. But something that's mentioned quite often are the COPPA functionality (USA only) and birthdays. Those two aren't really biggies I think so you might consider moving those to an extension in let's say 3.3 or 3.4. Take one or 2 features for each upcoming version and I think it can be handled very well.
Above message may contain errors in grammar, spelling or wrongly chosen words. This is because I'm not a native speaker. My apologies in advance.

User avatar
canonknipser
Registered User
Posts: 59
Joined: Mon Sep 19, 2011 4:42 am
Location: Germany

Re: Extensionalize phpBB

Post by canonknipser » Thu Jun 08, 2017 1:04 pm

I like this idea too - and it is already done with 3.2 (Vigilink extension - which is a official extension, but not listed in the extensions DB?). So this is no "new stuff"
Greetings, Frank

english is not my native language

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1731
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: Extensionalize phpBB

Post by DavidIQ » Thu Jun 08, 2017 1:11 pm

I'll quote this for emphasis as this will be our current official position on this idea and the responses/breakdown that have attempted to address these concerns have fallen quite short of that:
VSE wrote:
Sat Jun 03, 2017 3:17 pm
The very idea of this makes everything many orders of maginitude harder to maintain, as far as updates, compatibility, development, usability and language translations go.

It makes releases more difficult to ship as we would be required to also manage/release multiple extensions with a phpBB release to ensure users are kept up to date, as well as distribute them with every release, making an already dificult task even more difficult for those involved in releases.

It degrades testing phpBB. phpBB's core code is continuously tested in its entirety on three separate development branches. Some minor change here could create a major bug there, and if all these componenets are removed, some phpBB development regressions will no longer be detected, and the burden on the support team will sky rocket as they get bombarded by unforseen bugs and support topics, and have to scramble to figure out why the problem is occurring by dealing with a littany of separate extensions..probelms that could have been detected during testing.

It also makes testing and devloping extensions immensely difficult. Extensions are always developed and tested and validated against fresh phpBB installations. Removing all those componenets from the core means extensions will not be tested in the complete environment they are currently. It also measn to pull off testing in a "fully loaded" board would make the lives of the testers enourmously tougher than it already is. And indicidual developers will most likely not be developing while on a "fully-loaded" install either.

Also extensions that are continuously unit-tested will not be able to detect any bugs associated with those extensions, as they won't be part of the core phpBB installation that is used during unit testing, leading to extension authors having to support multiple new issues unforeseen, making their motivation to do this work wane.

It also ensures the componenets will probably go stale as once it's out of the core, it will no longer be a primary responsibility of the development team. And the extensions team is already understaffed and overwhelmed with all of its current extensions duties.
tldr;
I wouldn't spend too much time thinking about or even working on this idea as there are no plans to implement it at this time nor in the near (next 5-10 years) future. Good idea? Maybe on paper. In practice (at least right now) this is going to be a nightmare for maintenance, testing, releases, and many other things.
Image

User avatar
Ger
Registered User
Posts: 270
Joined: Mon Jul 26, 2010 1:55 pm
Location: 192.168.1.100
Contact:

Re: Extensionalize phpBB

Post by Ger » Thu Jun 08, 2017 1:34 pm

If that's the case you might just as well lock this topic.
Above message may contain errors in grammar, spelling or wrongly chosen words. This is because I'm not a native speaker. My apologies in advance.

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1731
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: Extensionalize phpBB

Post by DavidIQ » Thu Jun 08, 2017 1:36 pm

Agreed. Locked.
Image

Locked