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 akey,label,descriptionand optionalmail_template. They appear on the notification preferences page and are accepted byNotificationHelper::send().- Notification types are no longer passed around as an enum.
NotificationTypeimplements the newApp\Services\Notifications\Contracts\NotificationKind, which is whatNotificationHelper::send()andUser::wantsNotification()take and whatUserNotification::$typeandNotificationPreference::$typeread back.NotificationTypeRegistrylists every type and resolves one by key. - The notification preferences page renders the types the controller passes as
$notificationTypes. A user theme still callingNotificationType::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/lightstoreinrequiremust 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.
"require": {
"php": ">=8.4.0",
"nortexdev/lightstore": ">=24.0"
"nortexdev/lightstore": "^25.0"
}Continue with v25 -> v26.