Please allow plugins to add extensions

[Marcher Technologies]

Per title.

Without them, you are basically feature-freezing the core app extensions to third party developers.

For example, there is no real way for me to update my pages comments/follow mod for 4, because I can neither add the Notifications extension, nor can I add the MemberSync extension to handle merges/deletes via plugin. The latter I can hook around, sure. The former I cannot, and this is but one example, I'm certain there are many more.

 

That is by no means an application, nor should it be.

Just to head off the reply that if I need an extension it should be an app.

[Daniel F]

Couldn't you create a hook to override the Application::extensions class to add your own extensions?:)

 

But i agree, it would be nice if plugins would be more powerful, ATM they can't include extensions, emails and some other stuff...
I've already created some internal suggestions

[teraßyte]

I totally agree with this suggestion

[SJ77]

Couldn't you create a hook to override the Application::extensions class to add your own extensions?:)

 

But i agree, it would be nice if plugins would be more powerful, ATM they can't include extensions, emails and some other stuff...
I've already created some internal suggestions

​Wouldn't adding this additional power come at a cost? Seems like there is a trade off here. Allowing more control for developers might open the possibility for poor quality apps that can destroy core functionality. I kind of like the Apple principle, no way to screw up core stuff. Phones calls should always work. So in our world, core stuff like forum posts etc should always work. I don't know, I might be way off base but I am just trying to make sure all sides are considered.

[Marcher Technologies]

​Wouldn't adding this additional power come at a cost? Seems like there is a trade off here. Allowing more control for developers might open the possibility for poor quality apps that can destroy core functionality. I kind of like the Apple principle, no way to screw up core stuff. Phones calls should always work. So in our world, core stuff like forum posts etc should always work. I don't know, I might be way off base but I am just trying to make sure all sides are considered.

​Plugin hooks are sandboxed. Similar could be done for the extensions. Please do not let poor quality app developers stymie the good ones.

[Daniel F]

I love ips4 because of the autoloader - hooks -extension combination.
This makes it really a powerful system with almost no limitations. In theory you can change & customize whatever you want with this.

Removing this ability would make many plugins impossible, but it wouldn't stop (bad) coders to destroy your forum.

[Mark]

Yeah, good point.

In the back of my mind, I would like to one day to make applications and plugins the same thing.

[SJ77]

Yeah, good point.

In the back of my mind, I would like to one day to make applications and plugins the same thing.

Dumb question, but I am still kind of new to IPB. Can you explain the difference? I hear, "mods", "hooks", "apps" and "plugins" floating around and I think I am getting it all mixed up in my head.

[Mark]

Dumb question, but I am still kind of new to IPB. Can you explain the difference? I hear, "mods", "hooks", "apps" and "plugins" floating around and I think I am getting it all mixed up in my head.

Good question.

• The IPS Community Suite is made up of applications. Forums is an application, Gallery is an application, Commerce is an application. The controllers of an application are grouped into modules though in practice only the "core" application (which has modules for profiles, search, the messenger, etc.) and Commerce (which has modules for the store, support requests and the client area) have more than one module - all other 1st party applications have only one. Developers can create whole new applications - for example, there are 3rd party applications to add a portal or a simple CMS.
• A plugin modifies the behaviour of an application in some way by adding new features or changing existing ones. For example, there are plugins to add a group legend or a popup to inform users about cookies.
• Both applications and plugins share certain features, both can add:
  • Hooks which are a way to directly override any PHP class (either belonging to another application or even the framework itself) or HTML template.
  • Settings in the Admin CP
  • Tasks which are pieces of code that run at set intervals (for example, Forums uses a task to run RSS imports every day)
  • Widgets which are the blocks that you can add to the sidebar and the header/footer of any page
  • HTML Templates
  • CSS files
  • JavaScript files
  • Theme Resources which usually means images but could also be fonts, etc.
  • Language strings which are just the phrases used throughout the suite but abstracted so anything can be translated into another language (or even multiple languages on the same community)
  • Both also manage their own versions and have their own install and upgrade routines
• Some features are unique to applications - only applications can create:
  • Modules, as explained above, and their accompanying friendly URL structure
    
  • Extensions which are a way for applications to communicate with one another through channels they define. For example, the "core" application is responsible for creating and displaying the "Create" menu at the top of every page. Any application can add to this menu using an extension. Other examples include extensions that allow applications to add settings when editing a member or group, creating notification types (which users can then set a preference for how to receive from the central notification settings page) or adding content to the sitemap. In practice, almost all extensions are defined by "core" application. The only exception at the moment is Commerce which provides an extension to allow other applications to sell items through it, which is used by Downloads. However, any application (even 3rd party applications) can create extensions for other applications to use.
  • Email Templates
  • Their own Database Schema (i.e. tables in the database)
  • New areas in the Admin CP, and manage them with Admin CP restrictions. (As an aside, adding areas to the ACP is done through something called "ACP Modules" which is actually a misleading term and exists only because of legacy and the term doesn't appear outside of the developer centre and developer documentation - ACP modules are just a way of grouping controllers and have no real meaning, unlike "regular" modules which have special significance).
  • Theme Settings which are settings that can be modified per-theme
  • Also, only applications can distribute arbitrary PHP files with them
• Mods or modifications is a generic term which refers to any 3rd party application or plugin. We avoid the term - it is not used in the IPS Community Suite or in our documentation - but you will hear people say it.

 

As a slight curve-ball, in 3.x, the term hook was ambiguous and referred to both to what we now call plugins and what we now call hooks. For this reason, you may see some people incorrectly use the terms hook and plugin interchangeably. 

[Joel R]

Good question.

• The IPS Community Suite is made up of applications. Forums is an application, Gallery is an application, Commerce is an application. The controllers of an application are grouped into modules though in practice only the "core" application (which has modules for profiles, search, the messenger, etc.) and Commerce (which has modules for the store, support requests and the client area) have more than one module - all other 1st party applications have only one. Developers can create whole new applications - for example, there are 3rd party applications to add a portal or a simple CMS.
• A plugin modifies the behaviour of an application in some way by adding new features or changing existing ones. For example, there are plugins to add a group legend or a popup to inform users about cookies.
• Both applications and plugins share certain features, both can add:
  • Hooks which are a way to directly override any PHP class (either belonging to another application or even the framework itself) or HTML template.
  • Settings in the Admin CP
  • Tasks which are pieces of code that run at set intervals (for example, Forums uses a task to run RSS imports every day)
  • Widgets which are the blocks that you can add to the sidebar and the header/footer of any page
  • HTML Templates
  • CSS files
  • JavaScript files
  • Theme Resources which usually means images but could also be fonts, etc.
  • Language strings which are just the phrases used throughout the suite but abstracted so anything can be translated into another language (or even multiple languages on the same community)
  • Both also manage their own versions and have their own install and upgrade routines
• Some features are unique to applications - only applications can create:
  • Modules, as explained above, and their accompanying friendly URL structure
  • Extensions which are a way for applications to communicate with one another through channels they define. For example, the "core" application is responsible for creating and displaying the "Create" menu at the top of every page. Any application can add to this menu using an extension. Other examples include extensions that allow applications to add settings when editing a member or group, creating notification types (which users can then set a preference for how to receive from the central notification settings page) or adding content to the sitemap. In practice, almost all extensions are defined by "core" application. The only exception at the moment is Commerce which provides an extension to allow other applications to sell items through it, which is used by Downloads. However, any application (even 3rd party applications) can create extensions for other applications to use.
  • Email Templates
  • Their own Database Schema (i.e. tables in the database)
  • New areas in the Admin CP, and manage them with Admin CP restrictions. (As an aside, adding areas to the ACP is done through something called "ACP Modules" which is actually a misleading term and exists only because of legacy and the term doesn't appear outside of the developer centre and developer documentation - ACP modules are just a way of grouping controllers and have no real meaning, unlike "regular" modules which have special significance).
  • Theme Settings which are settings that can be modified per-theme
  • Also, only applications can distribute arbitrary PHP files with them
• Mods or modifications is a generic term which refers to any 3rd party application or plugin. We avoid the term - it is not used in the IPS Community Suite or in our documentation - but you will hear people say it.

 

As a slight curve-ball, in 3.x, the term hook was ambiguous and referred to both to what we now call plugins and what we now call hooks. For this reason, you may see some people incorrectly use the terms hook and plugin interchangeably. 

This should be in the docs.  Or in a blog post.  Or framed in gilded gold for posterity.  Or something.  

This wins the community award for best detailed answer for today.  

[SJ77]

fantastic answer Mark. Thank you so much!!

[Mark]

This should be in the docs.  Or in a blog post.  Or framed in gilded gold for posterity.  Or something.  

This wins the community award for best detailed answer for today.  

​Feel free to frame in gilded gold anything I say  

[NewRockRabbit]

This should be in the docs.  Or in a blog post.  Or framed in gilded gold for posterity.  Or something.  

This wins the community award for best detailed answer for today.  

​Really, Mark's post MUST go into the docs, its essential background stuff which will simply become 'lost' in the forums.

[CodingJungle]

maybe i missed it in the docs for plugins, but can we also work towards theme settings for plugins as well

 

[Daniel F]

Plugins can also manipulate the database ( via install.php and uninstall.php)