Adding a 'extension type' settings screen to a plug-in
Development and Programming
I have a plug-in which I would like to extend to feature a extension style settings screen so that I can have values which the plug-in can be passed optionally stored in a central location.
I’m assuming that I can re work my plug-in as an extension and still call it from my templates to perform a function but I need some guidance in how and whether this is even possible.
I have written a number of plug-ins before but only one extension so my knowledge is only minimal and there doesn’t seem to be a huge amount in the docs RE anything like this…
Any help would be greatly appreciated! 😊
Hi, Nathan,
You would be best to review the documentation on building Modules, as that sounds more along the lines of what you want.
ok, will do… just seems a bit OTT to build it out as a module when all I need is a simple settings screen. I was hoping there might be some way to call a function in an extension from an EE template as you do with a module. :/
Hi Nathan,
I’m pretty sure you can do what you are after with an extension. I’ve only ever made one extension myself but I seem to remember at some point adding in a very simple settings form so that people could change something themselves.
I remember just taking a look at one of the 3rd party extensions that had a settings page and going from there. Looking at the Developer Documentation for extensions though shows some information there about settings. Don’t know if that helps at all.
Myself though I would take a look at an extension that does this and see how they’ve done it, that’s how I got started with plugins anyway.
Best wishes,
Mark
You might want to read this kb article.
Essentially, an extension is there to modify existing behavior (or add to it); if you want to use your own tags in a template, and store settings for that addon, then a module is the way to go. You can make the CP interface very straightforward, but from what you describe, a module is not overkill but the correct avenue to achieve your goals.
Thanks Lisa. I’ve been giving this some thought and after reading your suggestion RE taking the module approach I think that in the long term it may work better anyhow… I can see how the plug-in ‘could’ evolve into a much larger ‘thing’.
So, as I understand it; extensions are only ever called when a hook that they use is referenced (and restricted to the CP side of things), whereas plug-ins and modules are ‘always available and loaded’ once installed. Plug-ins can only effect tempates and cannot have a CP presence whereas modules can. If a module needs to respond to a hook then you’d have to write an extension to accompany that module.
😊
I can see how the plug-in ‘could’ evolve into a much larger ‘thing’.
A module is not neccessarily much larger than a plugin. It only has a de-/installation routine, an at least minimal language file and can have a backend in the CP.
I agree with Lisa, if you want to extend a plugin with a settings page, a module is the way to go.
I just had to turn a plugin into a module. Not because I needed a CP-backend but the new functionality requires an Action ID.
So, as I understand it; extensions are only ever called when a hook that they use is referenced (and restricted to the CP side of things),
Extensions are called via hooks. They can be backend-related but also frontend. It depends on the kind of hook.
whereas plug-ins and modules are ‘always available and loaded’ once installed.
Plugins and Modules are loaded when a template is loaded that contains tags referencing them.
Plug-ins can only effect tempates and cannot have a CP presence whereas modules can. If a module needs to respond to a hook then you’d have to write an extension to accompany that module. 😊
That’s right.