Search by

seiger / soffers

seiger

Module for records management in the Evolution CMS admin panel.

Package info

github.com/Seiger/sOffers

Type:evolution-cms-module

pkg:composer/seiger/soffers

Statistics

Installs: 25

Dependents: 0

Suggesters: 0

Stars: 3

Open Issues: 0

v1.0.0 2023-06-14 13:07 UTC

This package is auto-updated.

Last update: 2026-11-11 11:09:19 UTC


README

Latest Stable Version CMS Evolution PHP version License Issues Stars Total Downloads Made in Ukraine

sOffers Module for records management in the Evolution CMS admin panel.

Requirements

Install sOffers in an existing Evolution CMS installation. The Composer constraints are Evolution CMS ^3.5.7 and PHP ^8.3. The Evolution CMS 3.5.7 baseline provides the manager APIs and Illuminate 12 components used by this package. sLang is optional.

Install by Artisan package installer

Run these commands from the Evolution CMS core/ directory:

php artisan package:installrequire seiger/soffers "*"

The installer adds the dependency to core/custom/composer.json. Evolution CMS discovers sOfferServiceProvider from the package's extra.laravel.providers metadata.

Publish the configuration and apply the package migrations:

php artisan vendor:publish --provider="Seiger\sOffers\sOfferServiceProvider"
php artisan migrate

Configure

The published core/custom/config/cms/settings/sOffer.php returns the offer field definitions. The manager settings form updates this file.

Manager permissions

The package permission migration adds the following permissions to the shared Seiger packages group (seiger_packages), also used by sTask. Apply the package migrations through the normal CMS upgrade process before opening the updated module. Only administrator role 1 receives the initial grants. Assign other manager roles explicitly and refresh their manager sessions after changing permissions.

Every module action requires an authenticated manager, exec_module, soffers, and the CMS file-module access checks. These are module-wide action permissions; the package does not define per-offer access groups.

The manager GET /soffer entry redirects to the registered file module. Offer editing, deletion and translation forms submit to file-module actions. The obsolete upload, gallery, delete and translation route declarations have been removed.

Permission Allowed operation
soffers Open sOffers and read its offers/features
soffers_create Create offers
soffers_save Edit offers, translations and TV values
soffers_delete Delete offers or explicitly selected features
soffers_publish Change publication state or publication date, including on creation
soffers_features Create/edit/reorder features; explicit deletion also requires soffers_delete
soffers_settings View/save settings and explicitly update feature language columns

All mutating module branches require POST and the CMS manager-session CSRF token. Opening the features tab is read-only; its separate Update feature language columns button performs the settings-authorized schema update through Schema Builder.

Settings definitions keep their existing PHP-array format and use var_export plus same-directory temporary files, a writer lock and atomic rename. The settings directory must be writable by PHP; existing file permission bits are preserved. A resource ID must be 0 (site root) or an existing, non-deleted CMS resource; omitting it preserves the current resource setting. The builder writes the value with bindings.

The form accepts up to 250 field definitions with matching key, name and type arrays. Normalized keys must be nonempty, unique and at most 255 ASCII characters; names allow up to 255 Unicode characters. Supported types are Text, Textarea and RichText. Malformed input is rejected before configuration, database or cache writes.

Database rollback requires a transactional system_settings table. File/database coordination restores the previous file on caught failures; it cannot provide a distributed transaction across a process crash or a lost database commit acknowledgement. The configuration directory must remain trusted and unavailable for writes by other users.

The sOffer model guards all attributes from Eloquent mass assignment. The module sets individual offer and TV attributes after checking the action permission.

Feature editing and languages

Existing features are updated by fid. Renaming or reordering preserves IDs and offer relations. Omitted rows and an empty features array preserve stored records. Only positive IDs explicitly submitted in deleted_features[] delete features; the form records these IDs when an existing row is removed. Deleting also removes its rows from s_offer_features inside the same transaction. Both tables must support transactions.

The server accepts fid, alias, badge, color and configured language fields. Unknown/system fields, mismatched arrays, duplicate IDs/aliases and stale IDs are rejected before writes. Each save accepts up to 250 rows and 250 deletion IDs. Text fields allow 255 Unicode characters; color allows 100. Aliases are slug-normalized and must remain unique; collisions are rejected. Position follows submitted row order, and base mirrors the default-language text. An explicit deletion needs both soffers_features and soffers_delete.

With sLang available, s_lang_config selects codes from sLang::langList(). Codes are trimmed and lowercased. Unknown codes, invalid identifiers, duplicates, empty segments and a default outside the configured list are rejected. Without sLang, sOffers uses base even if multilingual settings remain in the CMS. Correct invalid language configuration through the CMS language settings before opening sOffers.

The explicit language-column action creates only missing allowed columns with empty defaults and preserves existing values. It includes a sole non-base default language. If the default-language value is empty, its form field shows the existing base text so older base-only feature data can be retained when editing. Feature saves require the configured columns to exist and never run DDL themselves. Schema changes have the target database's DDL/locking behavior; a failed schema update may need to be retried. Concurrent edits still depend on the target transaction isolation; per-record version checking is not part of this change.

Manager labels use a separate fixed en/uk/ru file map. The manager session takes precedence over a literal locale read from the CMS cache. Unknown values fall back to English; cache PHP is never evaluated. Resolved translation paths must stay within the package language directory. Missing/invalid localized labels use English, and an unavailable English fallback raises a controlled exception. The package language directory must remain trusted.

Isolated regression checks

Run from the package directory with PHP CLI; no Composer install or CMS bootstrap is needed:

php tests/access-regression.php
php tests/permissions-regression.php

The suites use CMS/DB doubles and disposable config files. Permission registration is tested in memory; no CMS migration runner or real database is used. These checks do not replace integration testing on the target CMS/filesystem.

If an installed Illuminate vendor directory is available, compile and syntax-check the Blade templates without rendering them or bootstrapping the CMS:

php tests/compile-views.php /path/to/cms/core/vendor

The manager, feature and model checks use a fake CMS and SQLite :memory: with installed Illuminate components:

php tests/p1-regression.php /path/to/cms/core/vendor