So we have modules, plugins, rather recently extensions, and now—expansions. Is there any development info on them? Is the MSM a one-of-a-kind add-on that onle EllisLab could pull off, or would it be possible for third-party developers to develop their own? does it need support in the EE core code? (I suppose so.)

In a word, what makes an expansion unique, how does it differ from, say, a module? Any more info would be greatly appreciated.

Plugin - Has its own tags, modifies or outputs text in template or custom field (formatting).  Does not require installation.

Module - Has its own tags, typically has database tables, has form actions.  Needs to be installed through Modules tab.

Extension - Modifies how ExpressionEngine’s underlying code works using extension hook(s).  Does not have actions, can have its own database tables.  Must be enabled in Extensions Manager.

Expansion - Expands what is currently possible in ExpressionEngine.  Think of an expansion pack for a video game.  Same game, but new abilities and powers expanding on what is already there.

To expand on what Paul wrote (I know… bad pun…):

It’s not impossible for a third-party to develop an Expansion with the creative use of extensions and modules, but since Expansions are broader in scope, touching more areas of the core application, it will be a more challenging proposition then it is for us, since we can alter the fundamental code as needed.

What Rick has said is fundamentally correct.

Ok, I’m new around here and digging for everything I can find to help overcome the learning curve; hence I’m picking up this dated discussion.

Module - Has its own tags, typically has database tables, has form actions.  Needs to be installed through Modules tab.

So, is the Pages module really a module?

I was looking into how it does what it does and found that yes it does have it’s form actions and it needs to be installed and it does have a configuration table; but, it definitely doesn’t have it’s own tags.  It looks to me to be more of a hack in the core.system.php that intercepts ee’s normal /template group/template/ structure and then calls the template specified to be used with the page.

Then it uses the weblog module to do all the work.

Am I missing something?  Do we plan to clean this process up in ee 2.0?

Just for the record, and to put things into perscpective: when I started this thread I was not an employee of EllisLab, but I am now. The pages module is definitely a module. When Paul (CTO at the time) said that modules had their own tags, this is typically the case, of course, but there are exceptions. The pages module, the blacklist module, the referrer module… they all make do without tags of their own, while still being modules.

What exactly do you mean by cleaning up the process? The distinction between the various add-ons really makes a lot of sense once you get used to the underlying structure and data model.

And contrary to any third party addons a first party (EllisLab) module may of course come along with accompanying code in the core. Hence you cannot unconditionally compare it. Just think of the Weblog Module…

I stand corrected then.

I’m still trying to wrap my head around what and how ee does what it does so I can effectively adapt it to some very special objectives and don’t mean to come across as hyper-critical of the product.  To the contrary, it is a wonderfully elegant product which seems to be adaptable to anything and only limited by my own creativity.

My objective is to be able to let ee do all the heavy lifting in the core while still getting done what I want.  I’m still going through a paradigm shift and my apparent frustration is driven by my own limitation; not the products.

What exactly do you mean by cleaning up the process? The distinction between the various add-ons really makes a lot of sense once you get used to the underlying structure and data model.

I’m not sure.  It just seems like the cart is pulling the horse in pages.

Herb - 27 July 2008 06:30 AM

My objective is to be able to let ee do all the heavy lifting in the core while still getting done what I want.  I’m still going through a paradigm shift and my apparent frustration is driven by my own limitation; not the products.

Just a side note. Hacking the core too much can really become a pain when it comes to regular updates so it’s probably best advice to keep your code separately.

Just a side note. Hacking the core too much can really become a pain when it comes to regular updates so it’s probably best advice to keep your code separately.

silenz you are 100% dead-on.  I want to be able to use the core “as is”, tapping into its strengths and using its built-in scalability to reach my intended goals.  Hacking always creates more work in the long run.

My intention is to never hack the core, or for that matter any modules either.  I was actually trying to figure out how the pages module does what it does, so I could figure out how to write module that can accomplish a somewhat similar objective as the pages module.  In other words build a module that works hand-in-hand with mod.weblog, but toward a different goal.