[RFC|Merged] Extension Admin

These requests for comments/change have lead to an implemented feature that has been successfully merged into the 3.1/Ascraeus branch. Everything listed in this forum will be available in phpBB 3.1.
User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC] Extension Admin

Post by MichaelC » Wed Sep 05, 2012 1:44 pm

imkingdavid wrote:
Pony99CA wrote:Also, I'm not completely familiar with how extensions work under the covers, so forgive me if I'm way off base here, but are there scenarios where you might have one extension whose execution is dependent on another's? If so, how is that order enforced? If there's no dependency item in the manifest, should there be up/down buttons in the Extensions Manager to control their order of execution?
As far as I know, allowing extensions to specify dependencies was decided against (though I think it would have been a good idea). A sort of hackish way to do this is to check in your extension code for a table or event or something unique about the extension you depend on. If it doesn't find that, then your extension should just not run regardless of being enabled.
We decided to do it, but to wait until 3.2 before adding it (and it would be part of composer).

The hackish way we found was in ext.php's install() you can check in the phpbb_ext table has an an entry with your requirement extension and that it is enabled. Then adding checks throughout your extension to check that the requirement is still enabled.

However the Extension/MOD Team may decide that they won't allow this.
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
Pony99CA
Registered User
Posts: 986
Joined: Sun Feb 08, 2009 2:35 am
Location: Hollister, CA
Contact:

Re: [RFC|Merged] Extension Admin

Post by Pony99CA » Wed Sep 05, 2012 9:30 pm

oddfish wrote:This is probably more up to date with what is happening
details.gif
I don't think anything else is needed in the detail page as it is for detail and not for purging or enabling.
As I suggested, I may not know based on the list screen whether I want to purge or enable the extension, so why shouldn't there be buttons on the details page to allow that?

Steve
Silicon Valley Pocket PC (http://www.svpocketpc.com)
Creator of manage_bots and spoof_user (ask me)
Need hosting for a small forum with full cPanel & MySQL access? Contact me or PM me.

User avatar
oddfish
Registered User
Posts: 110
Joined: Tue Mar 27, 2007 5:53 am
Location: on my way home
Contact:

Re: [RFC|Merged] Extension Admin

Post by oddfish » Wed Sep 05, 2012 9:38 pm

Pony99CA wrote:As I suggested, I may not know based on the list screen whether I want to purge or enable the extension, so why shouldn't there be buttons on the details page to allow that?
I see details as, for example, an about page of what it is you are or want to view/install - I have yet to see any suggested buttons on such a page but perhaps changing that might suit some.

User avatar
Pony99CA
Registered User
Posts: 986
Joined: Sun Feb 08, 2009 2:35 am
Location: Hollister, CA
Contact:

Re: [RFC] Extension Admin

Post by Pony99CA » Wed Sep 05, 2012 9:46 pm

Unknown Bliss wrote:
imkingdavid wrote:
Pony99CA wrote:Also, I'm not completely familiar with how extensions work under the covers, so forgive me if I'm way off base here, but are there scenarios where you might have one extension whose execution is dependent on another's? If so, how is that order enforced? If there's no dependency item in the manifest, should there be up/down buttons in the Extensions Manager to control their order of execution?
As far as I know, allowing extensions to specify dependencies was decided against (though I think it would have been a good idea). A sort of hackish way to do this is to check in your extension code for a table or event or something unique about the extension you depend on. If it doesn't find that, then your extension should just not run regardless of being enabled.
We decided to do it, but to wait until 3.2 before adding it (and it would be part of composer).

The hackish way we found was in ext.php's install() you can check in the phpbb_ext table has an an entry with your requirement extension and that it is enabled. Then adding checks throughout your extension to check that the requirement is still enabled.
But it's not just whether the extension is installed and enabled or not; it's about the order the extensions are run in.

For example, in phpBB 2.x, I believe there was a MOD to more easily support Custom BBCodes, and several MODs that created Custom BBCodes used that. Let's presume that somebody creates a similar "foundation" extension in phpBB 3.1 and other extensions use it. It might be the case that the foundation extension has to run first before any of the dependent extensions can run. Is there any method to guarantee order of execution?

I think that I saw mention of an "extension ID" earlier in the topic. If that extension ID is assigned when an extension is accepted into the Customization Database and can be have less than/greater than comparisons performed against it, running extensions in order of extension ID would basically guarantee dependencies were satisfied.

The exception might be if somebody created a widget extension, then somebody else created a foundation extension to allow creating widget extensions more easily. If the original widget extension author released another version that used the foundation extension, the extension ID check wouldn't work. It would be up to the MOD team to watch out for that and require those to be submitted as new extensions.

I hope that all makes sense. :) And if this has already been considered, sorry -- I just started following this topic and it wasn't specific about how extensions are executed.

Steve
Silicon Valley Pocket PC (http://www.svpocketpc.com)
Creator of manage_bots and spoof_user (ask me)
Need hosting for a small forum with full cPanel & MySQL access? Contact me or PM me.

User avatar
Pony99CA
Registered User
Posts: 986
Joined: Sun Feb 08, 2009 2:35 am
Location: Hollister, CA
Contact:

Re: [RFC|Merged] Extension Admin

Post by Pony99CA » Wed Sep 05, 2012 10:20 pm

oddfish wrote:
Pony99CA wrote:As I suggested, I may not know based on the list screen whether I want to purge or enable the extension, so why shouldn't there be buttons on the details page to allow that?
I see details as, for example, an about page of what it is you are or want to view/install - I have yet to see any suggested buttons on such a page but perhaps changing that might suit some.
It's more than an About box, though -- it contains the description of the extension. Imagine that I have two extensions installed which have similar names. I might not know which one that I want to get rid of, but viewing the description could provide enough information to determine that. It seems that forcing users to go back to the list to perform the desired action is wasted time.

For example, in the ACP Module settings, I can disable modules from the list view or in the settings view. Extensions may not have settings that can be changed, but otherwise they're somewhat similar.

Steve
Silicon Valley Pocket PC (http://www.svpocketpc.com)
Creator of manage_bots and spoof_user (ask me)
Need hosting for a small forum with full cPanel & MySQL access? Contact me or PM me.

User avatar
imkingdavid
Registered User
Posts: 1050
Joined: Thu Jul 30, 2009 12:06 pm

Re: [RFC|Merged] Extension Admin

Post by imkingdavid » Wed Sep 05, 2012 10:26 pm

I'm not sure about extension IDs, I'd assume they would be arbitrary numbers created when the row is inserted into the table (think post ID or topic ID, same thing). I also am not sure if we're going to be enforcing unique extension names in the CDB, though since the extension name is most likely going to be required to include the authors name (e.g. imkingdavid/prefixed, for example), I doubt there will be any conflicts there.

There is a priority setting for events that extension authors can take advantage of, so as long as you know the priority of the extension you want to run first and then give yours a priority to run after, that should achieve what you want. I am not sure, however, if a priority of 1 is before or after a priority of 100 (i.e. is it a rank, where lower numbers are on top, or an order, where the highest number is done first). I'm also not sure what happens when two extensions have the same priority number on the same event.
EDIT: From the Symfony Event Dispatcher page:
An optional priority integer (higher equals more important) that determines when a listener is triggered versus other listeners (defaults to 0). If two listeners have the same priority, they are executed in the order that they were added to the dispatcher.
Also, extensions themselves can create their own events, so you can have a listener that only runs when a certain extension triggers a certain event. That is how I plan to add an optional integration between two of my extensions (if you care, I'm splitting my TMM MOD into a prefixes extension and multi-mod extension, and there will be an event in the multi-mod extension to allow other extensions to add actions, such as changing topic prefixes).

-----

As for the enable/disable/purge from the list page, I'm sure that wouldn't be too difficult to add, and agree that it is a good thing to add. However, your argument that you don't know if you want to install a given extension on the list page is likely not going to come into play until the integration between the Extension Admin and the CDB is done (probably won't be until 3.2). As it is, you have to manually via FTP add the extension package into the ./ext/ directory (hopefully there will be an upload/delete mechanism soon so you don't have to do it via FTP), so I would infer that one would read into the extension prior to adding it to the extension directory, just like you do with a MOD today.
I do custom MODs. PM for a quote!
View My: MODs | Portfolio
Please do NOT contact for support via PM or email.
Remember, the enemy's gate is down.

User avatar
oddfish
Registered User
Posts: 110
Joined: Tue Mar 27, 2007 5:53 am
Location: on my way home
Contact:

Re: [RFC|Merged] Extension Admin

Post by oddfish » Wed Sep 05, 2012 11:35 pm

Pony99CA wrote:It's more than an About box, though -- it contains the description of the extension. Imagine that I have two extensions installed which have similar names. I might not know which one that I want to get rid of, but viewing the description could provide enough information to determine that. It seems that forcing users to go back to the list to perform the desired action is wasted time.

For example, in the ACP Module settings, I can disable modules from the list view or in the settings view. Extensions may not have settings that can be changed, but otherwise they're somewhat similar.
About boxes do contain a description (as short as they are made) for many products. About pages go into more detail (again as informative as they are made to be). The amount of detail in this example is minimal with version numbers and authors, nothing more than an about box. To do more to it in its current form is unnecessary
PhpBB's about page gives a different interpretation of what their product is with no direct link to installing, purging, uploading etc, rather linking to what you want to do (a back button in the example).
imkingdavid wrote:As for the enable/disable/purge from the list page, I'm sure that wouldn't be too difficult to add, and agree that it is a good thing to add. However, your argument that you don't know if you want to install a given extension on the list page is likely not going to come into play until the integration between the Extension Admin and the CDB is done (probably won't be until 3.2). As it is, you have to manually via FTP add the extension package into the ./ext/ directory (hopefully there will be an upload/delete mechanism soon so you don't have to do it via FTP), so I would infer that one would read into the extension prior to adding it to the extension directory, just like you do with a MOD today.
To me this is where the extension management plays it role and not a list? (details?) page. As I know little of this extension feature, could previews be done with this?
Anyway, enough from me on this .. bridges to build.

User avatar
Pony99CA
Registered User
Posts: 986
Joined: Sun Feb 08, 2009 2:35 am
Location: Hollister, CA
Contact:

Re: [RFC|Merged] Extension Admin

Post by Pony99CA » Thu Sep 06, 2012 1:48 am

imkingdavid wrote:As for the enable/disable/purge from the list page, I'm sure that wouldn't be too difficult to add, and agree that it is a good thing to add. However, your argument that you don't know if you want to install a given extension on the list page is likely not going to come into play until the integration between the Extension Admin and the CDB is done (probably won't be until 3.2). As it is, you have to manually via FTP add the extension package into the ./ext/ directory (hopefully there will be an upload/delete mechanism soon so you don't have to do it via FTP), so I would infer that one would read into the extension prior to adding it to the extension directory, just like you do with a MOD today.
Right, but maybe I uploaded and enabled an extension, left it on for a while and users didn't like it. So I go to the Extension Manager and can't remember which one of the 100 extensions it was by name. Or maybe another admin who didn't install it wants to get rid of it because a bug was discovered and I'm on vacation. There are lots of scenarios where the details could help.

It's not a huge deal, but there's really no good reason to not allow it there, is there? (I know you're cool with it, so that's a rhetorical question for you. ;))

Steve
Silicon Valley Pocket PC (http://www.svpocketpc.com)
Creator of manage_bots and spoof_user (ask me)
Need hosting for a small forum with full cPanel & MySQL access? Contact me or PM me.

User avatar
Pony99CA
Registered User
Posts: 986
Joined: Sun Feb 08, 2009 2:35 am
Location: Hollister, CA
Contact:

Re: [RFC|Merged] Extension Admin

Post by Pony99CA » Thu Sep 06, 2012 2:15 am

oddfish wrote:
Pony99CA wrote:It's more than an About box, though -- it contains the description of the extension. Imagine that I have two extensions installed which have similar names. I might not know which one that I want to get rid of, but viewing the description could provide enough information to determine that. It seems that forcing users to go back to the list to perform the desired action is wasted time.

For example, in the ACP Module settings, I can disable modules from the list view or in the settings view. Extensions may not have settings that can be changed, but otherwise they're somewhat similar.
About boxes do contain a description (as short as they are made) for many products. About pages go into more detail (again as informative as they are made to be). The amount of detail in this example is minimal with version numbers and authors, nothing more than an about box. To do more to it in its current form is unnecessary
We disagree (on both the usefulness and whether Details is like an About box) then.
oddfish wrote:PhpBB's about page gives a different interpretation of what their product is with no direct link to installing, purging, uploading etc, rather linking to what you want to do (a back button in the example).
That's a completely different animal. About pages on Web sites are supposed to be descriptive; About dialogs in software generally just give version/build information and intellectual property details (copyrights, trademarks, licensing information, etc.).

I just checked Outlook 2010, IE 8, TestPartner and WinCVS. The most descriptive information was in Outlook 2010, saying that it was part of Office and listing the other programs that it was bundled with, but none of those had a description of what the product did. That makes sense for installable programs because you have to launch the product to get to its About box, so you've already seen a lot of what it does just by looking at the UI. ;)

Extensions are different -- they have no UI (in general) outside of phpBB, so you have to infer what they do when they're running.

Anyway, you may feel the buttons on the Details page are unnecessary, which is fine. And you're right, they aren't really necessary, because you can accomplish the task in another way. However, is there any good reason not to include them there (other than it would take some amount of time to add them)? I've given reasons why they'd be useful in some cases, but you've provided no reasons why they shouldn't be there other than your belief that they're not necessary.

phpBB needs to be able to do things in both list views and details views. Just last week, somebody wanted the ability to moderate posts from the search list without having to go into each topic (the "details" view) and use Quick Mod tools. That seems like a perfectly reasonable thing to me (and, if I recall correctly, something that vBulletin allows ;)).

Steve
Silicon Valley Pocket PC (http://www.svpocketpc.com)
Creator of manage_bots and spoof_user (ask me)
Need hosting for a small forum with full cPanel & MySQL access? Contact me or PM me.

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC|Merged] Extension Admin

Post by MichaelC » Sat Sep 08, 2012 9:51 am

Extension IDs - These are essentially pointless as we already require a unique extension name. And we need to suport extensions that are no inside the Customisation DB.

The extension name already requires it to be vendor/packagename, and yes, this will be forced to be unique in our customisation database but I doubt there will be any clashes. The need to be unique because otherwise when we add composer to install vendor/packagename it won't know which one. :) This functionality has not yet been added to the CDB yet however.
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

Post Reply