[RFC|Merged] Extension Admin

[MichaelC]

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.

[Pony99CA]

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

[oddfish]

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.

[Pony99CA]

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

[Pony99CA]

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

[imkingdavid]

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.

[oddfish]

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).

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.

[Pony99CA]

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

[Pony99CA]

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.

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

[MichaelC]

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.