PHP: Creazione di un sistema CMS estensibile

Question

Mi è stato assegnato un nuovo compito dal client, che fondamentalmente sta creando un CMS per attori/cantanti e simili che il cliente venderà a loro.

Fondamentalmente sarà un pacchetto e funzionerà out-of-box in modo molto simile a WordPress, è sufficiente consegnarlo a chi lo acquista ma ovviamente questa non sarà una piattaforma di blogging. Esso permetterà agli sviluppatori di:

• Aggiungere plugins/widgets
• aggiungere modelli/temi

ho pensato Observer Patten possono essere utili, ma non sono così sicuro a questo proposito. Quello che voi ragazzi potrebbe suggerire per creare ad esempio/estendibile CMS flessibile in termini di:

• Possibilità di aggiungere plug-in (ad esempio come WordPress)
• Possibilità di aggiungere temi/templates (per esempio come WordPress)
• design pattern
• Cosa non (non sono sicuro - aperto a suggerimenti)

Grazie per le vostre idee e aiuto.

Answer 1

L'osservatore sta bene, ma dovrai considerare di andare oltre lo schema di base. Il modello canonico Observer/Subject invia solo l'oggetto Subject all'Observer, nient'altro, nemmeno perché viene notificato.

Inizialmente, la soluzione potrebbe sembrare includere anche il motivo della notifica all'Observer, ma in questo caso si potrebbe finire con la notifica agli Osservatori a cui non interessano determinate notifiche. Una soluzione migliore potrebbe richiedere agli osservatori di chiedere anche un elenco di notifiche che vorrebbero ricevere.

Ma questo presenta anche un problema. Affinché gli Osservatori si attacchino effettivamente ai Soggetti, devono essere istanziati. Ogni singola volta. Anche se non sarebbero mai necessari. Quello è sciocco.

Quindi, abbiamo rapidamente raggiunto una delle canoniche implementazioni PHP dei plugin: "hook". Gli hook usano lo stesso concetto di Observer/Subject, ma l'implementazione è diversa in un modo molto importante: gli Observers reali non vengono istanziati per osservare i soggetti. Invece, i soggetti inviano una notifica a qualche varietà di repository centrale. Questo repository è configurato con un elenco di tutti i installati e attivati ​​con i plug-in (Observers) e contiene un elenco di tutti gli eventi che ciascun plug-in desidera ricevere. Ogni plug-in e informato solo quando l'evento ha luogo, spesso attraverso un metodo statico piuttosto che creando un'istanza del plugin e notificandolo. call_user_func_array e un buon caricatore automatico lo rendono incredibilmente semplice.

È quindi possibile creare un'interfaccia semplice per tutti i plugin da implementare. Metodi che è necessario includere ma non sono limitati a:

• Qualcosa per recuperare dati sul plug-in, ad esempio nome, autore, sito Web ufficiale, versione, ecc. Informazioni consumabili dall'utente.
• Un metodo che restituisce gli eventi a cui il plug-in desidera iscriversi.
• Un metodo di installazione, per le cose che il plugin deve fare per installarsi, come manipolare il database.
• Un metodo di disinstallazione potrebbe essere utile pure.
• Il metodo (probabilmente statico) che riceverà le notifiche degli eventi e restituirà tutti i dati necessari.

A seconda di quanto si prende il concetto di plug-in, si potrebbe finire con plugin che hanno opzioni configurabili dall'utente. Potrebbe essere necessario tenerne conto. In fondo a questa strada giace la follia e i sistemi di configurazione.

Per rendere efficaci i plug-in, è necessario posizionare i ganci ovunque e spesso lavorare con gli utenti finali per aggiungere nuovi ganci laddove sono necessari.

I widget possono facilmente funzionare in modo simile, come i plugin che vengono chiamati prima del rendering della pagina.

---

Temi/modelli, oh mio. Probabilmente hai due grandi opzioni.

1. Smarty, o un motore modello simile. O il tuo motore di template non-PHP.
2. modelli PHP.

Questa decisione sarà guidata dai vostri utenti finali. Smarty è incredibilmente limitante, ma se vuoi assicurarti che solo un codice approvato venga eseguito in un modello, potrebbe essere un'opzione valida. Inoltre, non è pericoloso consentire la modifica dei modelli Smarty direttamente nell'applicazione stessa.

D'altra parte, uno dei motivi per cui i modelli di Wordpress funzionano così bene è che sono puro PHP. Possono chiamare qualsiasi metodo esposto nell'API di Wordpress e persino fare la propria logica interessante. Se ti aspetti che i tuoi utenti finali siano tecnicamente preparati, o almeno tecnicamente competenti, i modelli PHP sono la strada da percorrere. D'altra parte, consentire la modifica di modelli PHP all'interno dell'applicazione può aprire un enorme potenziale buco di sicurezza se un utente malintenzionato entra nei bit di amministrazione. Probabilmente vuoi limitare la modifica al filesystem.

Mentre questo riguarda la creazione di HTML, è necessario tenere in considerazione anche i CSS. I tuoi utenti finali saranno in grado di manipolare i CSS direttamente? Lo vorranno? Se i tuoi modelli predefiniti includono abbastanza classi semantiche, possono probabilmente fare moltissimo stile senza troppo sforzo, se sanno cosa stanno facendo. D'altra parte, gli utenti finali potrebbero non sapere cosa sia il CSS, quindi potrebbero volere, oh, dire, selettori di colori e schemi di colori predefiniti, un selettore di combinazioni di colori e altre cose fastidiose da compilare. Probabilmente è meglio pensare a quegli orrori ora.

---

Varie cose.

Nessun CMS sarebbe completo senza il concetto di bozze e stati di pubblicazione. Non ho alcun consiglio per voi qui, a parte il codice questo primo. Se il cliente o gli utenti finali desiderano archiviare documenti storici, meccanismi di approvazione manageriale o qualsiasi altra cosa che rende la bozza/pubblicazione nulla tranne un semplice campo di stato, è necessario conoscere molto presto. (Sono stato morso orribilmente da questo.Avevamo progettato l'intero sistema attorno a un semplice modello pubblicato/non pubblicato e ottenuto circa 9/10 attraverso la creazione di specifiche e il relativo codice prototipo quando ci siamo resi conto che non avrebbe funzionato e avremmo dovuto fare qualcosa di molto, molto di più complesso per soddisfare effettivamente le esigenze dei clienti. La ricostruzione del piano di massima è stata la più grande perdita di tempo che abbiamo incontrato finora.)

Utilizzerai un ORM? In caso contrario, assicurarsi di utilizzare una libreria di interfaccia di database appropriata. PDO, o forse qualcosa da PEAR, o forse Zend_Db. Avrai inevitabilmente un cliente che, , insisterà sul che il codice gira su Oracle o MSSQL. O SQLite. Sarebbe bello dire loro che si può fare (con qualche sforzo). Gli autori di plugin ti ringrazieranno per la sanità mentale. Non effettuare il rollover.

(Poi di nuovo, con il tuo livello di ripetizione, mi aspetto che tu abbia già familiarità con praticamente tutto quello che ho detto. Ah, le cose che faccio per distrarmi mentre penso al mio set di problemi di codifica .. .)