cmsPRO/docs/plans/2026-02-28-update-channels-design.md

Design: Dwukanałowy system aktualizacji + zarządzanie licencjami

Data: 2026-02-28 Status: Zatwierdzony

Kontekst

cmsPRO jest używany przez wielu klientów. Celem jest wprowadzenie dwustopniowej dystrybucji aktualizacji:

• Kanał beta — tylko wybrane testowe instalacje (1–2 strony dewelopera)
• Kanał stable — wszyscy pozostali klienci

Zarządzanie odbywa się z panelu admina na cmspro.project-dc.pl (ten sam serwer i DB co serwer aktualizacji).

Kluczowe ograniczenie: nowy moduł admina oraz nowe tabele DB nigdy nie trafiają do paczek aktualizacyjnych wysyłanych klientom.

---

Sekcja 1: Baza danych

Dwie nowe tabele tworzone ręcznie tylko na serwerze dewelopera. Nie mogą pojawić się w żadnym SQL migracyjnym dla klientów.

CREATE TABLE pp_update_licenses (
  id               INT AUTO_INCREMENT PRIMARY KEY,
  `key`            VARCHAR(64) NOT NULL UNIQUE,
  domain           VARCHAR(255) NOT NULL,
  valid_to_date    DATE NULL,
  valid_to_version VARCHAR(10) NULL,
  beta             TINYINT(1) NOT NULL DEFAULT 0,
  note             TEXT NULL,
  created_at       DATETIME DEFAULT CURRENT_TIMESTAMP,
  updated_at       DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

CREATE TABLE pp_update_versions (
  id           INT AUTO_INCREMENT PRIMARY KEY,
  version      VARCHAR(10) NOT NULL UNIQUE,
  channel      ENUM('beta','stable') NOT NULL DEFAULT 'beta',
  created_at   DATETIME DEFAULT CURRENT_TIMESTAMP,
  promoted_at  DATETIME NULL
);

Dane z updates/versions.php (tablica $license) migrujemy jednorazowo do pp_update_licenses.

---

Sekcja 2: Plik updates/versions.php

Plik zostaje w tym samym miejscu, zmienia się tylko logika (hardkodowane tablice zastępowane odczytem z DB).

Nowy przepływ:

1. require_once '../config.php' → dostęp do $mdb (Medoo)
2. Skan filesystem — lista istniejących ZIPów (jak dotychczas)
3. Auto-discovery: każdy ZIP nieobecny w pp_update_versions → INSERT IGNORE z channel='beta'. Wrzucenie nowego ZIPa na serwer automatycznie rejestruje go jako beta — bez zmian w build-update.ps1.
4. Walidacja klucza z pp_update_licenses (zamiast $license[...])
5. Filtrowanie wersji według kanału:
   • klient z beta=1 → wersje gdzie channel IN ('beta','stable')
   • klient z beta=0 → tylko channel='stable'
6. Dalsze filtrowanie po valid_to_date i valid_to_version (bez zmian)
7. Wypisanie listy wersji (jak dotychczas)

---

Sekcja 3: Nowy moduł admina Releases

Nowa nazwa Releases (odróżnienie od istniejącego modułu Update używanego przez klientów do aktualizacji własnej instalacji).

Zakładka "Wersje"

• Tabela z pp_update_versions + status istnienia ZIPa na dysku
• Kolumny: wersja, kanał, data dodania, data promocji
• Akcje: Promuj do stable / Cofnij do beta

Zakładka "Licencje"

• Tabela z pp_update_licenses
• Kolumny: domena, klucz (skrócony hash), ważna do daty, ważna do wersji, beta (toggle), notatka
• Pełny CRUD: dodaj / edytuj / usuń
• Szybki toggle flagi beta bezpośrednio z listy

Pliki modułu

Wszystkie wykluczone z paczek ZIP dla klientów:

autoload/admin/controls/class.Releases.php
autoload/admin/factory/class.Releases.php
autoload/admin/view/class.Releases.php
admin/templates/releases/main-view.php
admin/templates/releases/licenses-view.php

---

Sekcja 4: Wykluczenie z aktualizacji klientów

Pliki PHP

W build-update.ps1 — dodanie powyższych ścieżek do listy wykluczeń.

Tabele DB

pp_update_licenses i pp_update_versions nigdy nie pojawiają się w:

• plikach _sql.txt dołączanych do paczek
• sekcji sql w plikach _manifest.json

Tabele tworzone jednorazowo ręcznie na serwerze dewelopera.

---

Migracja danych

Jednorazowy skrypt PHP (uruchamiany ręcznie na serwerze) przenosi dane z $license[...] z versions.php do pp_update_licenses. Po migracji tablica $license w versions.php jest usuwana.