.IM-CMS ver. 1.0

Koncepcja, geneza, motywacja

Pierwsze przemyślenia i fundamentalne założenia, które przyświecały mi podczas ustalania wymagań projektowych dla nowego systemu CMS (jeszcze nazwa nie była sprecyzowana) zaczęły się już w roku 2017. Główna idea pojawiła się w momencie realizacji jednego z projektów. Jakia to idea? Podział na sekcje, obiekty, typy, właściwości. Cztery hermetyczne, abstrakcyjne definicje...
Od roku 2009, projektowałem własny system CMS, wdrażałem go do wielu projektów. Zdobył on uznanie naprawdę wielu użytkowników. Poczynając od właścicieli: księgarni (API), biura obrotu nieruchmościami, systemu doradczego, a kończąc na "zwykłych" stronach wizytówkowych. Po tych 10 latach zorientowałem się, że zacząłem za dużo poprawiać, "łatać", jednym słowem kombinować, żeby mój CMS sprostał coraz to większym wymaganiom...
W końcu powiedziałem: STOP. Pora na zmiany i to drastyczne...
Wracając do sekcji, obiektów, typów i właściwości, o których wspomniałem wcześniej.
Otóż, zasada podczas projektowania serwisu internetowego jest następująca: każda strona/podstrona WWW jest w systemie tzw. sekcją (takich sekcji możemy tworzyć dowolną ilość i układać w dowolnej hierarchii - rodzice i potomkowie). Każdy element na stronie (sekcji) jest tzw. obiektem, obiekt "aktualność", obiekt "slider główny", obiekt "menu" - to my tworzymy obiekty...
I teraz, każdy taki obiekt musi mieć jakieś właściwości, czyli być jakiegoś typu. Gdzie typ to właśnie zestaw określonych właściwości, czyli np.: opis, zdjęcie, data, nazwa, odsyłacz, itd. To my ustalamy jakie właściwości będzie miał dany typ, i w końcu ustalamy jakiego typu będzie obiekt, i to w danej sekcji...
Opisana koncepcja zapewnia niesamowitą elastyczność twórcy, logicznie wydziela każdy element składający się na budowę serwisu/portalu, daje czyste i klarowne podejście do pracy w panelu zarządzania treścią.
W to wszystko wplotłem jeszcze jedno ciekawe rozwiązanie, mianowicie: "wielodomenowość". Jak to działa? Jeżeli więcej niż jedna domena prowadzi do systemu (na poziomie root), to możemy utworzyć dedykowane katalogi w systemie dla każdej domeny. W takim katalogu zawiera się layout, pliki graficzne, parametry połączenia z bazą danych, pliki js czy less-css. Dodatkowo to w panelu admina wybieramy jaką domeną zarządzamy.
Sam silnik pracuje tak samo dla każdej domeny, to katalog danej domeny definiuje dedykowane dane i preferowane zdarzenia po stronie klienta (tylko jeden katalog). Złota zasada programisty DRY (nie powtarzaj się) zachowana w pełni.
Co jeszcze, moduł tłumaczeń. W systemie jesteśmy w stanie przetłumaczyć wszystko co znajduje się w bazie danych. W jaki sposób? Silnik, aby przetłumaczyć dany tekst, potrzebuje z bazy danych: nazwę tabeli, pola i nr ID rekordu, które ma przetłumaczyć. IM-CMS uruchamiając moduł tłumaczeń ma te 3 rzeczy zdefiniowane.
A teraz o motywacji krótko. Asumpt, który wpłwał znacząco na postępy prac to byli tak naprawdę sami użytkownicy i ich pomysły...pomysły, które bardzo chciałem je urzeczywistnić...
A teraz trochę technicznie...

Struktura silnika, kod źrółowy

Przebudowałem tu wszystko: model bazy danych, kod źródłowy, layout panelu administratora. Baza danych to tabele przechowujące dane na temat właśnie: sekcji, obiektów, typów i właściwości. Wszystko połączone odpowiednimi relacjami (tu też zasada DRY jest jak najbardziej wymagana). Do tego zaprojektowałem jeszcze tabele, które przechowują dane na temat ustawień, tłumaczeń językowych, etykiet (każda sekcja ma etykiety, czyli miejsca na stronie do którego są podłączone obiekty), kategorii (zastaw obiektów jednego typu, przyczepionych do tej samej etykiety można wyłuskać wybierając kategorię z listy rozwijanej - pajawią się obiekty podczepione do wybranej kategorii).
Kod po stronie serwera to bardzo dużo obiektowości. Struktura w skrócie: "systemy domenowe", klasa "obiekt" - serce, katalog z właściwościami, katalog na rozszerzenia "composer", katalog z modułami, katalog "ajax", katalog realizujący żądania po stronie serwera...
Czystość i logiczna izolacja...
Co zapewnia takie utrzymanie infrastruktury kodu:
  • Proces projektowania jest bardziej odporny na błędy,
  • Każde późniejsze zmiany są stosunkowo łatwe do wdrożenia,
  • Aktualizacja poszczególnych elementów odbywa się w sposób bezpieczny,
  • Prostota zarządzania.
Podstawowe technologie:
  • Środowisko PhpStorm z pakietami Composer.
  • Bootstrap 4.3.1.
  • Fontawesome PRO - 5.11.
  • LESS-CSS (kompilator lokalny)
  • Interpreter: PHP-OOP 7.x
  • Relacyjna baza danych: MySQL 5.7.
  • Moduły: jQuery, Nice-Select, etc.
Moje marzenie, powoli się spełnia...

Live DEMO

Zapraszam do przetestowania.
Wersja sandbox: demo (demo@demo, demo)

2019 - Internet.Media - Damian Krawiec, Zielona Góra, Lubuskie
m(at)internet.media.pl