The core is a frame: the import pipeline, events, storage, the template engine and the interface shell. It has almost no product features of its own — everything the store sees comes from plugins. So writing your own is not working around the architecture, it is the way it was meant to be used.
What it is
A folder in custom/Plugins with a Plugin class. The class declares a name, a description and the section its tab belongs to. Nothing needs registering: the program finds the folder itself.
Where it can step in
A plugin subscribes to pipeline events by declaring a method with the right name. Between reading the feed and writing to the store it can:
- change the price, title, description or attributes;
- replace or further process images;
- hide an item so it never reaches the store;
- keep a log of its own.
What a plugin gets
- its own tables in the database;
- its own settings page in the panel;
- the same storage the core uses.
What not to do
Write into the store database directly. That is the driver’s job: it knows the tables of a particular CMS, and only because of that does one plugin work across different engines. A plugin decides what to do with a product; how to write it is the driver’s business.
Tying a plugin to a single engine or even a single store is normal and does happen. Such a plugin is still a plugin, and the core is left alone.
If there is nobody to write it
Describe the task and we will quote it separately. Often that is quicker than working it out yourself.