Add-on modules are features that are not part of every CoreInto installation. Each one is a folder under modules/ next to app/, with its own code, pages and README. A module does nothing until it is activated, and it can be turned off again at any time; its settings and data are kept while it is off.
CoreInto comes with two modules, both off until you activate them: Gateway Fee and Renewal Pricing. Other modules, such as PKNIC for .pk domains, are supplied separately.
Settings > Add-on Modules
Settings > System > Add-on Modules (/admin/settings/addon-modules) lists every module found in the modules folder, with its title, version, author, a short description and its state:
| State | Meaning |
|---|---|
| Active | The module is on: its pages, menu items and hooks work. Configure opens its settings page when it has one. |
| Inactive | The files are on the server but the module is off. Activate turns it on and prepares its tables. |
| Files missing | The module is marked active but its folder is no longer on the server. Nothing of it runs. Copy the folder back, or Deactivate it. System Health warns about this too. |
Activating and deactivating need the permission "Configure add-on modules" (settings.addon_modules); using a module's pages needs "Use add-on modules" (addon_modules). Both are recorded in the activity log. The pages of active modules appear in the Add-ons menu, which also links to this page.
Installing a module supplied separately
- Unzip the module's package. It holds a folder named after the module, for example
pknic. - Upload that folder into the
modulesfolder of your CoreInto installation, so thatmodules/pknic/module.phpexists. - Open Settings > Add-on Modules and press Activate next to the module.
- Follow the module's README for its own set-up.
Updating a module is the same: replace its folder with the new one. When the version in the files is newer than the one that was activated, CoreInto prepares the module again the next time it is activated or when Database Update runs.
The modules folder is never served to browsers (the .htaccess rules refuse it, as they refuse app/ and storage/). On nginx, add modules to the same location rule that denies app and storage.
Gateway Fee
Charges clients a fee for paying with a particular payment method. Activate it, then press Configure (or open Add-ons > Gateway Fees). The page lists every active payment gateway; for each one choose the fee type (None, Percentage, Fixed amount, or Percentage plus fixed), the percentage (up to three decimals), a fixed amount per currency (invoices are in the client's currency), an optional minimum and maximum per currency, the text of the invoice line (default "Payment processing fee (%s)", where %s is the gateway's name) and whether tax is charged on the fee.
The fee is its own invoice line, worked out on the total of the other lines including tax. It follows the invoice's payment method while the invoice is unpaid: it is added when the invoice is made and replaced or taken off when the client picks another way to pay, pays with a kept card of another gateway, or staff change the method in the invoice options or charge a kept card. The client's "Pay with" list shows each method's fee, such as "Card (Stripe) + 3%". Paid, cancelled and refunded invoices, and invoices that already have a payment, are never changed, and staff can edit or delete a fee line by hand. A payment recorded by staff with another method keeps the fee of the method chosen on the invoice, so change the method first if the fee should follow. Add-funds invoices get a fee too, while the credit added stays the amount asked for; a mass payment charges one fee on the whole, less the fees already on the included invoices. Deactivating stops new fees; lines already on unpaid invoices stay.
Renewal Pricing
Changes what products, services and domain extensions renew at, and carries the new price into unpaid renewal invoices that are already out. Activate it and open Add-ons > Renewal Pricing. It has three tabs, each for one currency at a time:
| Tab | What it shows and changes |
|---|---|
| Products | Every product by group, with per billing cycle the catalogue price, how many active or suspended services renew on it and at what amounts, and a box for the new renewal price. Two switches: "Also use this price for new orders" (changes the catalogue price, setup fee kept) and "Update the renewal price of existing services" (on by default). |
| Services | A searchable list of services with client, product, domain, cycle, renewal amount, next due date and status, and a box to set one service's renewal amount. |
| Domain extensions | Every extension with its renew price per number of years, how many domains renew on it, and the same two switches. |
Product and extension changes go through Preview changes, which lists exactly what will change, then Save these changes. A service renews at the new price times its quantity plus its configurable options; a domain at the new renew price plus the yearly price of its extras. Services and domains renewing for free stay free.
On invoices that are unpaid or draft, the renewal lines of the changed services and domains get the new amount and the totals and tax are worked out again; with Gateway Fee active, its fee follows. First payments, setup fees, domain registrations and transfers, and lines on an order's invoice are never changed. Lines that no longer hold the old renewal amount (prorated, discounted or edited by hand), invoices with a payment or credit on them, and invoices in payment pending or collections are left alone and listed as skipped. After saving, a summary shows what changed with links to the updated invoices; it is kept under Recent changes and written to the activity log. Permissions: "Use add-on modules" to see and save, "Configure add-on modules" for the Options card that sets how the two switches start.
PKNIC (.pk domains)
Supplied separately. It adds the PKNIC registrar module (registration, nameservers, sync and the domain list through the member's PKNIC dashboard), the .pk extension presets, and WHOIS for .pk and its second-level extensions, which asks PKNIC's public lookup page, then the member's own domain record when the registrar is set up, and adds the nameservers from DNS. Its README describes the set-up. A site that already used the PKNIC registrar before it became a module keeps it marked active: copy the module's folder into modules/ with the update and it carries on. While the folder is missing, domains with the PKNIC registrar show "registrar not available", their commands become staff tasks, and Add-on Modules and System Health say the files are missing.
For developers: how a module is built
A module folder contains:
| File | Purpose |
|---|---|
module.php | Returns the manifest: name (the folder name), title, version, description, author, class (the module class) and namespace (the prefix of its classes, loaded from src/). |
src/Module.php | The module class, extending CoreInto\Addons\Addon. |
templates/ | Its pages, rendered as @name/page and wrapped in the admin shell like CoreInto's own pages. |
README.md | What it does and how to set it up. |
The class overrides only the hooks it needs: activate() and deactivate() (create its tables with CREATE TABLE IF NOT EXISTS), adminRoutes() (pages under /admin, each with a permission), menu() (items in the Add-ons menu), configRoute() (its settings page), registrars() (registrar modules it brings), whois() and whoisTlds() (WHOIS answers for extensions it handles), and events() (methods called when something happens: invoice.created, invoice.gateway when an invoice's payment method changes). Its configuration is stored with conf() and saveConf(). Its texts go through t() like CoreInto's, so the language files translate them too.