Module vs plugin, additional resources for modules

Questions
#1

Hi guys,

I would like to have more information about october cms modules.
What are the differences between plugin and module?
Does anyone have something to read for me, about this topic (links, docs)?

Of course I already checked out the source code of a module. I can see what is possible.
But feel free to give me any links, information, resources about this topic.

Also I would like to have some more explanation about this in the docs.

all the best :slight_smile:

#2

Hi @alexwenzel

It is a good question, modules and plugins are mostly the same. The following document describes some differences:

In short:

  • Modules are OEM packages, where the author is October CMS
  • Modules are enabled by config
  • Plugins are disabled by config

Let me know if you have any other questions.

#3

Hi @daft,

Thank you for your first answer. It already helped me.

But I have a more concrete question regarding this topic:

At the moment I am coding a website system, which will serve 10 different websites.
They all share most parts of the logic, they only will be different in some plugins.

I started to write a core plugin, and some example plugins (which contains the website data).

plugins/acme/core
plugins/acme/website1
plugins/acme/website2
plugins/acme/...

My current plan is, to toggle projects via the .env file:

  • which will enable/disable the plugins
  • which choose themes

Also all projects are build out of one codebase at the moment.

  1. Now I am asking myself, what would be the best design decision.
  2. Do I have disadvantages, when I put all my business logic into a plugin?
  3. Which way gives me flexibility to change behaviour of october cms

EDIT:

  1. Can I make use of the typical laravel directory structure?

// alex

#4

Your current plan sounds good. There is indeed an “app” directory that you can use that works just like a plugin and resembles the Laravel directory structure.

So this approach would be:

  • Different app for every customer/website for unique logic and requirements
  • Shared plugins for them all, enabled or disabled depending if they want it or not
  • Different theme for every customer/website, perhaps as a child theme for shared logic
1 Like