Skip to content
V
For developers
Architecture, conventions, the core and security
Modules / Module overview

Modules#

The system's domain modules. Each has its part in every section — app/UI/{Front,Api,Admin,Cron}/<Module>/.

Module Domain Entities Chapter
System users, payments, settings, code lists, assets 90
Eshop goods, cart, orders, complaints, feeds 84 E-shop
Bazaar classifieds 34 Classifieds
Comcat company catalogue 33 Company catalogue
Blog articles, news, events, galleries, guestbook 29 Blog
Invoicer invoicing 28 Invoicing
Company the operator's own business — presentation, appointments, jobs 25 My company
Base shared — comments, ratings, polls, newsletter, ad slots 22
Store warehouse 13 Warehouse
Discussion forum 13 Discussion

The counts are Api entities — ls app/UI/Api/<Module>/Models/Entities/*.php | wc -l. Exactly one module has no Front section: Invoicer, because documents are never shown to a visitor on their own, only as a file to download from an order.

Where to start#

I want Start here
to get my bearings in the modules for the first time Blog — the smallest of the "ordinary" ones and a reference model at the same time
to write a new search source ArticleDocumentSource.php from the blog
to understand dynamic fields Classifieds
to understand money and states E-shopWarehouseInvoicing, in that order

Shared patterns#

Most modules share the same patterns — recognise them in one and you recognise them everywhere:

Pattern Where it appears Where it is described
dynamic parameters instead of fixed columns Bazaar, Comcat, Eshop Classifieds
tree categories (nested set) Bazaar, Comcat, Discussion, Eshop, Blog, Company Classifieds
a denormalised counter plus a cron recount everywhere there is a tree Classifieds
tariffs and payment items Bazaar, Comcat, Discussion Discussion
time-limited highlighting (toped_until) Bazaar, Comcat, Discussion Classifieds
a state machine with action flags Eshop (orders, complaints) E-shop
a document as a snapshot Invoicer, Store Invoicing
an Elasticsearch source Blog, Bazaar, Comcat, Discussion, Eshop Elasticsearch

Comcat and Company are two different modules, not two halves of one

Comcat is a catalogue of other people's businesses (a copy of Bazaar), Company is the operator's own business. They share not a single table and have no common ancestor — only the name is similar. A fix in one has no effect in the other, so a report of "the company thing is broken" always has to be sorted out first.

Comcat was created as a copy of Bazaar

They are very similar. When solving something in one, check whether it is not in the other too — and whether the fix is not missing there. The note about its creation is in docs/comcat-copy-from-bazaar.md.

Similarity is not sameness, though

Comcat has no price, no sold and no followers, and its generated active column has one condition fewer. A copied SQL query or PHP getter can therefore fail — the list of differences is in Company catalogue.

Shared elements from Base#

Comments, ratings, polls, the newsletter and ad slots are one implementation for every module (app/UI/Api/Base/).

Fixing a shared component affects every module at once

A change in ratings shows up on products, adverts, companies and posts alike. Walk through all of them, not just the one you are fixing it for — and expect that three out of four will go untested unless you say so yourself.

Where to look#

I want Where
the shared entities app/UI/Api/Base/Models/Entities/
the modules' shared base entities app/Core/Base/Shared/<Module>/Models/Entities/
a module's cron tasks app/UI/Cron/<Module>/Presenters/
the search sources app/UI/Api/<Module>/Models/Search/

Follow-up chapters: Five-layer model · Project structure · Elasticsearch · Scheduled tasks