Light Services
Addon Migration Guides

v24 -> v25

Addon API changes in the v25 releases, and what each one means for an addon you maintain.

Changes listed here affect code an addon is written against: the StoreAddon class, the contracts and services it calls, and the data it reads back. Store-side changes with no addon-facing surface are left out.

For the current manifest format and the conventional layout, see Addon Development.

v25.0.0 changes

  • StoreAddon::getNotificationTypes() lets an addon add notification types, each a key, label, description and optional mail_template. They appear on the notification preferences page and are accepted by NotificationHelper::send().
  • Notification types are no longer passed around as an enum. NotificationType implements the new App\Services\Notifications\Contracts\NotificationKind, which is what NotificationHelper::send() and User::wantsNotification() take and what UserNotification::$type and NotificationPreference::$type read back. NotificationTypeRegistry lists every type and resolves one by key.
  • The notification preferences page renders the types the controller passes as $notificationTypes. A user theme still calling NotificationType::cases() works, but leaves addon types out.
  • StoreAddon::getMailTemplates() lets an addon ship mail templates, seeded when the addon is enabled. An existing key is left alone, so an upgrade never overwrites a reworded template.

v25.1.0 changes

  • nortexdev/lightstore in require must pin one store major as a caret constraint, such as ^25.0. The installer refuses >=, wildcards, ranges spanning majors and a missing constraint, so an addon built for v25 can no longer be installed on v26. The addon API has never been backwards compatible across majors, and the constraint now says so.
composer.json
"require": {
	"php": ">=8.4.0",
	"nortexdev/lightstore": ">=24.0"
	"nortexdev/lightstore": "^25.0"
}

Continue with v25 -> v26.

On this page