Heute haben wir wieder mal ein kleines Goodie für die Community - und zwar eine komplette Modulverwaltung für den Oxid Shop. Derzeit ist es ja so dass alle Module manuell installiert werden müssen, also ungefähr so:
So nun stellt euch vor Ihr müsstet nur noch das Paket hochladen und den changed_full manuell abgleichen - das macht unser neuer Modulmanager für Oxid! Doch nicht nur das er bietet darüber hinaus auch noch eine komfortable Oberfläche um Moduleinträge zu pflegen (nicht diese schreckliche Texteingabebox). [B]Und das allerbeste an der Sache ist - er ist kostenlos[/B]!
Das ganze Paket ist noch zum Testen gedacht also nicht unbedingt für Live Shops und alle Module geeignet, die Modulverwaltung an sich funktioniert aber garantiert schon gut genug für live shops.
Das Archiv hänge ich an diesen Beitrag, wenn ein paar Leute es getestet und für gut befunden haben stelle ich das ganze in den Exchange (ja auch da als GPL for free).
Künftig werden alle unsere Module diesen Manager unterstützen sodass eine Modulinstallation nur noch den Bruchteil der Zeit benötigt.
Die Installation ist kinderleicht, einfach die Dateien auf den Server kopieren - den tmp Ordner leeren und schon kann es los gehen.
Ich war ja längere Zeit nicht aktiv hier. Hatte ein paar kleinere Framework Projekte.
Nun ist es wieder so weit, ich beschäftige mich mit Oxid und vermisse ein paar Sachen die bei modernen Frameworks normal sind… besonders Moduleinbindung.
Von da her sitze ich an etwas ähnlichen…
[ul]
[li]Jedes Modulverzeichenis (/modules/moduleName) soll die gleiche Verzeichnisstruktur haben wie Oxid selber (admin, core, views, out, modules).
[/li][li]Dementsprechend sollen die Klassen auch hier autom. geladen werden. Dank spl_autoload_register kein Problem.
[/li][li]Auch die Templates sollen automatisch geladen werden. Folgende Reihenfolge: Subtemplate, Maintemplate (basic), Moduletemplate.
[/li]Dies geht, bei den Modulen leider nur mit relativen Pfaden.
[li]Auch i18n ist kein Problem.
[/li][li]Das definieren des Adminmenus geht dank der menu.xml schon sehr gut… Könnte aber auch durch Konvention im Bezug auf Klassen und deren Methoden automatisiert werden.
[/li][/ul]
Soweit so gut. Über das einbinden von Oxid-Klassenerweiterungen habe ich mir so direkt noch keine Gedanken gemacht.
Mir geht es erstmal darum, dass ich beim Entwickeln ein eigenes Hauptverzeichnis habe und meine Dateien nicht zwischen massig oxid-Dateien suchen muss.
Aber Gutding will weile haben und alles muss noch auf verschiedenen Umgebungen getestet werden.
Willst du das ganze jetzt selber nochmal bauen oder wie? Ich denke wir könnten gut und gerne auf dieser Basis arbeiten denn das ganze ist auch für bereits vorhandene Module geeignet und auch für Shops die noch die Versionen ohne spl_autoregister einsetzen. Mit etwas Anpassungsarbeit könnte man eventuell sogar die changed_full Sachen automatisch einspielen (eine art diff machen, oder angleichen mit einem Script das beide Dateien anzeigt zum abgleichen).
Bei Joomla hat man noch erweitert Steuerungsmöglichkeiten mit einer XML Datei, auch das wäre hier denkbar. Egal wie, eine Struktur muss her die für alle Module identisch ist da hast du wohl recht.
Ich finde das Modul grundsätzlich klasse. Danke dafür! An solchen automatisierten Prozessen stört mich eigentlich nur etwas. Treten Fehler auf, weiss man nicht, was genau gemacht wurde und kann es daher meistens auch nur mit viel Aufwand beheben. Magento verfügt auch über einen Modulmanager. Beim rumspielen mit Magento kam es öfters vor, dass nach Modulupdates der Shop nicht mehr funktionierte. Danach war dann mühsame Fehlersuche angesagt. Ein Fallback auf die letzte Version war teilweise leider auch nicht möglich. Daher wäre es natürlich optimal, wenn es im Modulmanager eine Funktion geben würde, damit man die letzten Änderungen rückgängig machen könnte.
Da gebe ich dir natürlich Recht, generell wird im Moment schon alles geloggt und es wird auch genau angezeigt was passiert ist nachdem ein Modul installiert wurde. Ein Fallback ist noch nicht drin, das wäre aber nur dann wirklich ordentlich möglich wenn es nicht nur eine install.sql Datei sondern auch eine uninstall.sql gäbe (wäre ja kein Problem). Eventuell ein komplettes DB Backup mit machen … mal gucken - aber danke fürs Feedback.
[QUOTE=roland76;31012]Ich finde das Modul grundsätzlich klasse. Danke dafür! An solchen automatisierten Prozessen stört mich eigentlich nur etwas. Treten Fehler auf, weiss man nicht, was genau gemacht wurde und kann es daher meistens auch nur mit viel Aufwand beheben. Magento verfügt auch über einen Modulmanager. Beim rumspielen mit Magento kam es öfters vor, dass nach Modulupdates der Shop nicht mehr funktionierte. Danach war dann mühsame Fehlersuche angesagt. Ein Fallback auf die letzte Version war teilweise leider auch nicht möglich. Daher wäre es natürlich optimal, wenn es im Modulmanager eine Funktion geben würde, damit man die letzten Änderungen rückgängig machen könnte.[/QUOTE]
Ich fürchte, das kann man mit einem Modul-Manager nicht beheben…
Wenn man OXID erfolgreich per Modul-Installation “auf’s Kreuz” gelegt hat, ist ja oft auch die Admin-Oberfläche tot…
Könnte/Müsste man evtl über ein Stand-Alone Recovery-Modul lösen…
Ich denke da wäre eine extra File nicht verkehrt die unabhängig von Oxid läuft, denn irgendwie muss man den safemode ja aktivieren/deaktivieren können. Ja so viel input so wenig zeit
[QUOTE=aggrosoft;31018]Ich denke da wäre eine extra File nicht verkehrt die unabhängig von Oxid läuft, denn irgendwie muss man den safemode ja aktivieren/deaktivieren können. Ja so viel input so wenig zeit :)[/QUOTE]
Mal 'ne dumme Frage…
Ich habe das installiert: wo finde ich denn den Modulmanager jetzt im Admin?
[QUOTE=aggrosoft;31018]Ich denke da wäre eine extra File nicht verkehrt die unabhängig von Oxid läuft, denn irgendwie muss man den safemode ja aktivieren/deaktivieren können. [/QUOTE]Der [B]Safemode [/B]wird über den Parameter “?safemode=true” aktiviert.
[QUOTE=aggrosoft;31010]Willst du das ganze jetzt selber nochmal bauen oder wie? Ich denke wir könnten gut und gerne auf dieser Basis arbeiten denn das ganze ist auch für bereits vorhandene Module geeignet und auch für Shops die noch die Versionen ohne spl_autoregister einsetzen. Mit etwas Anpassungsarbeit könnte man eventuell sogar die changed_full Sachen automatisch einspielen (eine art diff machen, oder angleichen mit einem Script das beide Dateien anzeigt zum abgleichen).
Bei Joomla hat man noch erweitert Steuerungsmöglichkeiten mit einer XML Datei, auch das wäre hier denkbar. Egal wie, eine Struktur muss her die für alle Module identisch ist da hast du wohl recht.[/QUOTE]
Naja, nennt man glaube ich kollektives Unterbewusstsein.
Bin da nicht erst seit gestern dran und eigentlich schon fertig.
Habe dies im laufe meines aktuellen Kundenprojekts begonnen… und bereits meine vorhandenen Module angepasst. Es fehlen halt noch einige Tests im Echtbetrieb und auf anderen Servern.
Auf SPL möchte ich nicht verzichten. Um den Classloader so zu machen wie ich es mir vorstelle, geht das nur mit SPL oder fiese Hacks im Oxid-Core.
Meine Angriffspunkte sind:
spl_autoload_register
eine intelligente Sprachdatei, welche Modulsprachen nachlädt.
meine Views haben eine eigene Template-Such-Funktion, welche relative Pfade zum Modulverzeichnistemplate berechnet. Leider gehen absolute Pfade nicht… ich glaube da prüft Oxid, ob die Datei existiert und setzt den absoluten Pfad nochmal davor…
changed_full zu automatisieren halte ich für… sehr komplex.
Man weiß nie wie ein Custom-Template aussieht… uU. nur wenn sauberes xhtml benutzt wurde, schade das xhtml fast tot ist. Per xslt oder Dom/xquey ließe sich dann was machen.
Per Regex oä. nur beim Basic-Template.
Wenn Oxid (habe ich schon mehrmals erwähnt) einzelne Bereiche (Boxen usw.) in eigene Dateien auslagern würde, könnte man das Smarty include-plugin [{include file=“bla.tpl”}] ein wenig anpassen und hätte pro include 2 Hooks (vor und nach den include). Diese kann man dann wieder im Modul ‘registrieren’. Dann währe das ohne große Seiteneffekte machbar.
Ok, das kann man jetzt schon so machen, aber leider reichen die paar includes bei weiten nicht aus.
Aber gerne können wir unsere Arbeiten zusammenfließen lassen.
Mir geht es Hauptsächlich um die Verzeichnisstruktur und dadurch resultierende ‘Konvention statt Konfiguration’.
Das klingt ja alles schon gut, ich denke wenn wir diese beiden Module zu einem verbinden sind wir der Sache schon um einiges näher. Würdest du dich bereit erklären das ganze mit beizusteuern? Wenn ja dann häng doch mal ein bisschen code an.
[QUOTE=aggrosoft;31025]Guck mal auf den ersten Screenshot, bei Grundeinstellungen hast du nen neuen Tab “Module”.[/QUOTE]
Kaum installiert man es richtig, schon funktioniert’s…
Gehe ich recht in der Annahme, dass man in “docs/modules.txt” die Befehle einträgt, die man normalerweise in die Modulbox eingibt?
Damit müsste man doch dann auch mehrere Module auf einmal installieren können?
Wir haben nämlich Funktionen, für die mehr als eine Klasse überladen werden muss, und für die auch mehrere Dateien aus verschiedenen Verzeichnissen geladen werden müssen.
Also die Klasse geht so vor dass er diese Moduleinträge auseinander pflückt und richtig mit verkettet. Haben das in unserem Shirtnetwork Modul ungefähr so:
Die werden richtig mit eingetragen, auch wenn schon ein overload für oxorder vorhanden ist werden diese mit angehängt. Er prüft auch immer vorher ob ein Eintrag bereits vorhanden ist sodass nichts doppelt reingehangen wird.
Und wegen diesen einträgen - es ist eine entweder oder regelung, wenn du etwas in die box eingibst dann nimmt er das ansonsten sucht er nach einer modules.txt mit den einträgen.
