[CMS] Instalator rozszerzeń, Jak rozwiązać problem? Opcje

[WebCM]

Tworzę nowy instalator rozszerzeń do systemu CMS, który ma za zadanie instalować, usuwać i aktualizować je. Teraz pytanie, czy:

1. Wprowadzić plik ze strukturą
Przykład: http://www.unit1.pl/pb-911
Plik zawiera informacje na temat tabel i pól, bloków menu, plików konfiguracyjnych... z uwzględnieniem zmian w kolejnych wersjach. Tylko czy w ten sposób nie ograniczę zakresu działań instalatora? Na podstawie tych informacji CMS instaluje, usuwa lub aktualizuje rozszerzenie z uwzględnieniem różnic w bazach danych. Zaletą jest to, że proces instalacji jest pod większą kontrolą.

2. Udostępnić uniwersalne API
Rozszerzenia zawierają 3 funkcje: Install(), Uninstall() i Update(). W CMS-ie są zdefiniowane stałe: DB_TYPE (MySQL lub SQLite), PLUGIN_VERSION (aktualna wersja rozszerzenia)... CMS udostępnia też trochę funkcji, np. do dodawania elementów do menu albo tworzenia plików konfiguracji.

PS. CMS obsługuje MySQL i SQLite

Ten post edytował WebCM 2.11.2008, 22:11:48

[bim2]

Byłbym za opcją 2 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Tylko trzeba robić bardzo uniwersalne pluginy (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

[Riklaunim]

Popatrz sobie na Wordpressa czy inne skrypty. W przypadku WP masz coś w stylu 2, lecz o znacznie większych możliwościach (a wykonanie takiego mechanizmu nie jest łatwe/szybkie) - pozwalające na tworzenie rozszerzeń nie będących "księgą gości", czy "forum", ale działających w tle lub np. integrujących WP z innymi skryptami.
Na początek starczy 1. wrzuć katalog wtyczki, w Panelu uruchom i gotowe. Wtyczka ma opis, funkcję instalująca i deinstalująca plus funkcję konfiguracji + jej standardowe elementy (gdzie wtyczka to "forum", czy "księga gości")

[WebCM]

Przejrzałem rozwiązania w kilku skryptach. W większości rozszerzenia mają funkcje: instalującą i dezinstalującą. W PhpBB 3 wszystko oparte o XML i automatyczne podmianki kodu w plikach .php, ale chyba nie wykonuje zapytań do bazy. We wtyczce `blog` znalazłem informację: "Go to yoursite/blog/install.php (...)"

Sprawa skomplikowała się po dodaniu obsługi SQLite. Trzeba wykryć typ bazy i pisać oddzielne zapytania, gdyż np. w SQLite - zamiast auto_increment pisze się autoincrement. Jest też trochę innych drobnostek. Właściwie dla zaawansowanych to nie problem, ale czytelność takiego kodu nie będzie zbyt duża. Mogą też powstać dodatkowe komplikacje. Dochodzi jeszcze kwestia aktualizacji rozszerzeń, dodawania linków do menu, itd.

A. Zostawić tak, jak jest. Niech wtyczkopisarze martwią się o wszystko.

B. Opisać strukturę bazy danych, bloki menu, linki, itd. w pliku XML, jak w przykładzie: http://www.unit1.pl/pb-931 Znikają problemy z kompatybilnością baz danych, ale możliwości są ograniczone. CMS nadzoruje proces instalacji, co pozwala dostosować opcje (np. gdzie dodać link) przez użytkownika i bezpiecznie aktualizować rozszerzenia.

C. Informacje na temat bloków menu, linków, itd. w pliku XML lub INI, natomiast zapytania do bazy w plikach .sql, np. mysql.sql, sqlite.sql.

D. Plik .php z informacjami w zmiennych / stałych (podobnie jak w B). Zagrożenie wykonania dowolnego kodu.

Ten post edytował WebCM 8.12.2008, 00:19:45

[Riklaunim]

Sprawa skomplikowała się po dodaniu obsługi SQLite. Trzeba wykryć typ bazy i pisać oddzielne zapytania, gdyż np. w SQLite - zamiast auto_increment pisze się autoincrement.

Od tego są ORMy, żeby nie pisać różnych SQLek dla różnych typów baz danych (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)



Na początek zrób to proste na zasadzie znajdź i zamień, czy też prostych funkcji wykonujących odpowiednie zapytania (stworzenie tabel, dodanie do menu itp.).

[WebCM]

Odświeżę temat. Sprawa instalacji rozszerzeń została na koniec. Zostawię na razie XML-owe struktury w spokoju. Mam kilka koncepcji, jak powinien wyglądać plik instalacyjny rozszerzenia. Oto one: A, B1, B2. Zależy mi na tym, aby twórcy rozszerzeń nie mieli problemu ze stworzeniem pliku instalacyjnego bądź nie pogubili się.

W przypadku koncepcji A twórca musi zająć się wszystkimi operacjami: dodaniem tabel, danych, pliku konfiguracji, linków w menu... - koniecznie sprawdzić, który silnik bazy (SQLite, MySQL) jest używany i który język (PL, EN).

W przypadku koncepcji B1 twórca definiuje zapytania i przekazuje inne informacje w tablicach. Odczytuje je moduł odpowiadający za instalację rozszerzeń i na ich podstawie wykonuje odpowiednie akcje.

Koncepcja B2 jest podobna z tą różnicą, że w kluczach tablic określamy typy zapytań oraz nazwy tabel. Zmiana może dotyczyć też np. dodawania konfiguracji, linków, itd.

[erix]

Hmm, jest jeszcze inne rozwiązanie. W np. SimpleMachines Forum został IMHO bardzo ciekawie zaprojektowany system instalacji modyfikacji. Tworzony jest bardzo przystępny XML - http://docs.simplemachines.org/index.php?topic=506

Ale to i tak tylko namiastka; pogrzeb w dokumentacji i ściągnij parę rozszerzeń.