Willkommen auf der privaten Homepage von Johannes Jarolim, Salzburg, Österreich. Welcome to the private homepage of Johannes Jarolim, Salzburg, Austria, Europe.

Im Rahmen meiner Arbeit ist mir das CMS Pimcore unter die Finger gekommen: Dieses Open Source CMS wurde durch eine für Salzburger Verhältnisse großen Agentur namens Elements entwickelt.

Der erste Eindruck

Mein erster Eindruck ist durchgehend positiv:

Das CMS stellt ein Agentur-Framework für die Entwicklung komplexer Seiten dar: Es basiert zum größten Teil auf dem PHP-Framework Zend, mit dessen Hilfe ein relativ gut durchdachtes MVC-Pattern implementiert wurde. Das CMS basiert (noch?) nicht auf Zend_Application, da dieses zum Entwicklungsstart noch nicht stable zur Verfügung stand.

Im Backend stellt Pimcore einige sehr interessante Feature via ExtJS zur Verfügung, was eine sehr moderne Admin-Oberfläche ermöglicht. Der Entwickler kann zB. via Drag & Drop sehr einfach neue Data Access Objects (DAO) erstellen und untereinander verknüpfen. Diese stellen in Folge die Datenstruktur der Website. Hier bekommen wir die Grundidee von zB. Drupal in einem modernen und durchdachtem neuen Gewand präsentiert.

Das Backend erlaubt out-of-the-box auch die Deklaration von Parent-Klassen für im Backend definierte Klassen: Damit lassen sich mit Hilfe eines guten Programmierers auch komplexe Domains darstellen.

Klassifizierung

Pimcore schätze ich derzeit primär als Agentur-Website-Frameset ein: Es wird auf jeden Fall ein kompetenter PHP-Entwickler benötigt, um Kundenseiten bottom-up aufzubauen.

Hobby-Programmierer haben mit Pimcore weniger Freude, da es erstens idealerweise auf einem dedicated Server läuft, auf dem man zB. benötigte PHP Module deployen kann. Zusätzlich muß man schon für sehr einfache Seiten anfangen, eigene PHP-Controller zu programmieren, bevor irgendwas angezeigt wird: Hier wird out-of-the-box nichts zur Verfügung gestellt.

Hat man diese Ressourcen (PHP-Programmierer) allerdings zur Verfügung und die Hürden der sehr Fachpublikum-orientierten Dokumentation überwunden, kann ich das System auch jetzt schon 100%ig empfehlen: Mit kurzer Einlernzeit durch einen Pimcore-Kundigen lassen sich auch komplexe Themengebiete sehr effizient darstellen.

Gute PHP Programmierer lassen sich definitiv durch das verwendete Zend-Framework und die MVC-Orientierung locken.

Verbesserung möglich und nötig

Grundsätzlich zeichnen sich erfolgreiche Open-Source-Projekte derzeit aus meiner Sicht durch eine möglichst breit gestreute Stakeholder-Gruppe aus: Je weiter die Userbasis, desto mehr Interessenten und Entwickler finden sich, die Bugs und Feature Requests einstellen wie auch analysieren/beheben/programmieren.

Pimcore verschenkt hier aus meiner Sicht derzeit definitv Potential und ist aus Open-Source-Sicht strategisch nicht 100%ig richtig positioniert: Um hier das Momentum einer starken Entwicklergemeinde aufbauen zu können, ist das System meiner Meinung nach noch zu anspruchsvoll bezüglich der Infrastrukturanforderungen.

Zusätzlich bietet es noch nicht den nötigen Level an Trivialisierung, um mäßig ausgebildete PHP-Programmierer anzuziehen.

Senior-PHP-Entwickler als Target Audience?

Die Macher von Pimcore sollten sich meiner Meinung nach etwas mehr Gedanken um die Zielgruppe machen: Wie bekommt das CMS strategisch die meiste Aufmerksamkeit? Wie kann ich möglichst viele Open-Source-Entwickler in das Projekt einbinden? Wie fördere ich auch nicht so begabte/ausgebildete PHP-Prgammierer, ihren Beitrag zu dem Projekt beizutragen?

Ich würde hier Ansätze von Open-Source-Projekten wie zB. WordPress analysieren und implementieren: Diese verstehen es vorzüglich, zB. das Templating vom Kern-System zu trennen und sauber zu Dokumentieren. Das Basis-System selber läuft auf einer möglichst breiten Systemlandschaft und ist sehr einfach zu installieren und aktuell zu halten.

Resultat:

  • Tausende von Programmieren, die täglich neue Plugins/Templates zum Projekt hinzufügen.
  • Millionen von Nutzern; Das CMS wird täglich von unzähligen Nutzern weiter empfohlen, runtergeladen und installiert.
  • Open Source Momentum

Fazit

Schafft es das Entwicklungsteam, die verschiedenen Hebel der Open Source Entwicklung optimal zu bedienen, sollte Pimcore meiner Meinung nach wie eine Atombombe einschlagen: Grundsätzlich bietet das System vieles, was sich ein gut ausgebildeter PHP-Entwickler derzeit nur wünschen kann – Allerdings fehlt noch das richtige Open Source Momentum.

Zehn Antworten

  1. 24. December 2011, 19:30
    Comment by Tim Glabisch
    Ich sehe das völlig anders, Pimcore zu "trivialisieren" macht wenig Sinn. Es hat gute Gründe weswegen man einen guten PHP-Entwickler für einen Aufbau einer Webseite benötigt.

    Pimcore kann nur so effektiv sein, weil es sich an gewisse Standards (u.a. Design Pattern) hält und nicht versucht diese neu zu erfinden. Der 0 8 15 Redakteur ist nicht dafür da um eine Webapplikation aufzubauen, viel mehr sind es Entwickler die Anforderungen der Konzeption, Administration (u.s.w.) umsetzen sollten.

    Sicher benötigt man Know-How um mit dem System umzugehen, nicht aber weil das System sonderlich Komplex ist, sondern weil es davon ausgeht, dass derjenige der es nutzt, dass nötige Wissen hat eine Webseite aufzubauen.

    Das aufgeführte Beispiel Wordpress ist vom Code her fast quasi eine Schande, die Plugins idr. schlecht entwickelt, Architektur hat das System quasi keine. Jeder gute Entwickler wird sicher häufiger tief Luft holen müssen, wenn er sich mit dem Wordpress Core auseinandersetzen muss. Durch dieses "schlechte" Design verstehen auch "nicht-Entwickler" Wordpress relativ schnell, Entwickler jedoch haben Probleme damit effektiv zu arbeiten.

    Keiner würde auf die Idee kommen zu sagen, dass Zend Framework sollte die Zielgruppe ändern, damit jeder DAU damit klar kommt. Viel mehr sollte Pimcore guten Entwicklern, die wissen was sie tun und Erfahrungen mit Frameworks a la symfony, zend framework, ... besitzen, eine gute Hilfe sein, ihre tägliche Arbeit optimal und flexibel zu verrichten.

    Die Pimcore Community scheint auf dem ersten Blick wohl auch kleiner als sie ist.
    Häufig findet man hier größere Agenturen an, die das nötige Know-How haben und nicht das Forum unnötig mit völlig sinnfreien Beiträgen beschandeln. Ein weiterer Grund ist wohl, dass Pimcore das Rad nicht neu erfindet. 95% der Fragen die man zu diesem System wohl stellen kann, sind Fragen welche sich auf das Zend Framework beziehen.
    • 26. December 2011, 12:43
      Comment by Johannes
      Hallo Tim -

      Danke für dein Feedback!

      Aus Entwicklersicht kann ich fast allen deinen Argumenten voll und ganz zustimmen. Große Teile der Codebasis von WordPress ist tatsächlich (mit Vorbehalt: derzeit) nicht weiterzuempfehlen.

      Hier muss man aber definitiv unterscheiden zwischen Systemen, die mit dem Sowtware-Entwicklungs-Know-How von 2009/2010 from the scratch auf funktionierenden, modernen Frameworks aufgebaut wurden und anderen, natürlich gewachsenen. Meiner Einschätzung nach wird sich WordPress auch Architektur-technisch gesehen bald nicht mehr verstecken müssen, soviel wie da derzeit refactored wird. MVC wird es aber wahrscheinlich nicht nutzen.

      Mein Punkt ist: Das Projekt funktioniert offensichtlich und hat eine Menge Momentum. Es hat eine breite Entwicklerbasis, extrem viele Installationen out in the wild, (für ein Open-Source-Projekt) sehr professionalisierte Release-Cycles in sehr kurzen Abständen: Dadurch extrem schnelles Fixing von Schwachstellen und Security Holes. Das sind Stärken, die nicht von selber kommen: Hier hat eine Entwickler-Community konsequent an der Breitentauglichkeit und Professionalisierung des Systems gearbeitet.

      Zur Klarstellung: Ich starte hier *definitiv* keine WordPress/Pimcore Diskussion - Ich weise hier ausschließlich auf Bereiche hin, in denen das Projekt gut aufgestellt ist, und von denen sich andere Open-Source-Projekte meiner Meinung nach etwas abschauen können/müssen:

      (1) Aufbau eines Plugin-Ecosystems, an dem jeder partizipieren kann
      (2) Aufbau eines Theming-Ecosystems (siehe oben)
      (3) Absolute Breitentauglichkeit des Systems durch
      (3.a) Installierbarkeit auf praktisch jedem System
      (3.b) Ein lauffähiges System nach Installation, dass 90% der benötigten Funktionen stellt, dass eine "normale" Seite benötigt

      Das sind die Punkte, die sich auch mit sauberer Grundarchitektur abbilden lassen: Ein Pluginsystem zB. ist ja dafür gedacht, Core-Code nicht zu patchen, sondern peripher zu erweitern, ohne zB. die updatefähigkeit des Systems zu beeinträchtigen. Auch der Auslieferung eines Systems mit 2-3 vorgefertigten Controllern und einem Basis-Layout spricht nichts entegegen - Typo3 macht das zB. mit den Source+Dummy-Packages so, damit ich nicht immer WordPress als Benchmark nenne.

      Der Tonalität deines Posts kann ich allerdings so nicht zustimmen: Jeder, der sich mit dem Framework noch nicht auseinandergesetzt hat ist ein "DAU" und "beschandelt" Foren mit "sinnfreien" Kommentaren? Nee, wirklich nicht. Dass jemand ein Problem aus Programmierersicht nicht richtig formulieren kann, heißt nicht, dass das Problem nicht besteht. Hat der Beteiligte das System nicht richtig verstanden, hat man es selber nicht gut genug erklärt.

      Richtet sich ein Open-Source-Projekt nur an ein eingeschränktes Fachpublikum, ist das auch perfekt OK - Man verspielt sich nur den Open-Source-Community-Hebel, den man mit eigener Arbeitskraft nicht kompensieren kann.
    • 4. April 2012, 11:33
      Comment by Johannes
      Also als kleines Update darf ich zB. die Lektüre der Methode save() der Klasse pimcore/models/Object/Class empfehlen (Pimcore Version 1.4.4, Build: 1780).

      Ein sauberes Model ergibt sich nicht automatisch aus der Verwendung von Zend Komponenten: Alle Programmierer kochen mit Wasser.
  2. 18. January 2012, 15:58
    Comment by Schubie
    Hallo Johannes,

    das meiste deiner Auflistung im letzten Kommentar gibt es doch bereits.

    zu (1): Es gibt ein offenes Plugin System bei dem sich jeder ins Hub mit eigenen Plugins einbringen kann, oder die Vorhandenen nutzen.

    zu (2): Genau dafür sind meiner Meinung nach die Views hier da. Bei PHP an sich handelt es sich doch schon um eine Template-Sprache. Warum HTML Umsetzern noch eine Template-Syntax a la Smarty aufzwingen, wenn doch genau das gleiche, genau so leicht direkt mit PHP bewirkt werden kann. Bei uns klappt das ganz gut, wenn ich den Umsetzern sage: "Hier, im Ordner Website/Views kannst du dich austoben.

    zu (3): Hier kann man geteilter Meinung sein. Ich empfinde es gerade als Stärke, dass das System nach der Installation gerade "nichts" kann und sich das auch so in der Admin-Oberfläche wieder spiegelt. Genau dadurch bekommt der Kunde, zumindest im professionellem Bereich genau das, was er haben möchte, wenn wir Webseite für ihn umsetzen, im Gegensatz zu Joomla, Typo3 und Co, wo zwar fast jeder das System installieren kann, aber dann durch die mittlerweile ausufernde Vielfalt im Admin-Bereich erschlagen wird. Schulungen für den Kunden sind da bei Pimcore einfach angenehmer. Hier wird man nicht durch die Eier-legende-Woll-Milch-Sau abgeschreckt ;)

    Ok, der Preis dafür ist, es kann nicht durch jeden nur mal zum Spaß betrieben werden, aber ich denke, in vielleicht 1,5-2 Jahren wird sich das auch ändern.

    Man könnte überlegen neben dem System wie es jetzt ist, einen weiteren Zweig herauszubringen, der das wichtigste für den Betrieb einer einfachen Seite schon fertig mitbringt, der Import der Demo-Daten ist ja schon ein Schritt in die Richtung.
    • 19. January 2012, 11:49
      Comment by Johannes
      Hi Schubie -

      Danke für dein Feedback!

      Zu (1) kann ich dir gerade nix intelligentes sagen - Das möchte ich mir vorher besser anschauen ;-)

      Zu (2): Ich habe mit Templatingsystem nicht die Einführung von Smarty, Savant und Konsorten gemeint - Da stimmt ich dir 100%ig zu - PHP ist da völlig ausreichend, sofern das Caching der Inhalte (falls benötigt) an anderer Stelle abgehandelt ist.

      Unter Templating System verstehe ich mehr das Skinning einer Seite mit einem bestimmten Grundset an Funktionalitäten, das auch durch nicht so erfahrene PHP-Programmierer durch Bereitstellung einer guten Dokumentation und simpler PHP-API erledigt werden kann. Da spielt wohl Punkt 3.b mit hinein: Die Bereitstellung eines Systems, dass schon einige Grundfunktionalitäten bietet.

      Bzgl. Views gebe ich dir recht - Allerdings greifen die noch etwas kurz - Diese müssen ja schließlich zuerst vorbereitet und programmiert werden. Danach muß man den HTML/CSS-Künstler erst einweisen, was er wo findet und welche Variablen er aus dem Modell weitergereicht bekommt: Wir befinden uns hier naturgemäß weit im Gebiet der Individual-Programmierung... Wenn auch mit dem Standard Zend-Framework im Rücken.

      Meine Frage ist, ob man nicht mit 3.a und 3.b einen Bereich des Systems vorliefert, den ich persönlich nicht zum hundertausendsmal wieder neu erfinden möchte:

      - Eine default Startseite
      - Default-Contentseiten-Objekte mit schönen mod-rewrite Links (+ WYSIWYG Komponente im Backendobjekt)
      - Menufunktionalität mit einem einfachem Templatebefehl
      - News-Objekte/bereich mit chronologisch angezeigten News
      - Ein Template-Befehl, um diese auf der Startseite anreissen zu können
      - Ein Downloadbereich (Objekte + vorgefertigte Templates/Views)
      - Ein Standard-Response-Formelement

      Dazu noch die 2-3 Controller und Path-Mappings, die man braucht und schon man hat man mit einer Default-Installation eine Menge Seiten fast ohne weitere Programmierung umgesetzt: Allerdings auf einer sauber erweiterbaren Infrastruktur.

      So eine Infrastruktur mit einem Basis-Templateset kann praktisch jeder neu skinnen und so ein Set an Skins anderen zur Verfügung stellen.

      Meiner Meinung nach könnte man 3.b so wie das Typo3-Package als Dummy-Site-Zusatz-Installationspackage lösen: Dann verbaut man nichts für Entwickler, die alles selber machen wollen. Da braucht es imho keinen Branch, der eventuell irgendwann vertrocknet, sondern kann super nebenbei mitlaufen.

      Die Verbreiterung der Installationsbasis durch runterschrauben der Infrastrukturanforderungen ist allerdings ein Must-Have aus meiner Sicht.
    • 11. October 2012, 08:55
      Comment by Johannes
      Hallo Schubie -

      Späte Antwort, aber trotzdem: Nach der Programmierung von ein paar Agentur-internen pimcore Erweiterungen kann ich nur sagen, dass das noch nicht so wirklich lässig umgesetzt ist.

      Dadurch, dass pimcore (noch?) nicht auf Zend_Application mit entsprechendem Bootstrap basiert, muss man teilweise sehr unschöne Pfade beschreiten, um aus einem Plugin beispielsweise einen View- oder ActionHelper zu registrieren.

      Die System-Grundstruktur ist da teilweise etwas eigen - und so wird es auch für die Core-Programmierer recht schwierig/aufwendig sein, das sauber für Plugins zu öffnen.

      Das hat derzeit alles so den Nimbus einer Achttausender Erstbesteigung - besonders mit der zur Verfügung gestellten Dokumentation ;-)

      just my 50 cents,
      mfG aus Salzburg!

      - johannes
  3. 11. April 2012, 09:58
    Comment by Stefan
    Ich hab letztens gesehen das es bald ein Demo Projekt geben wird, wo es gewisse Standard Views und so weiter geben soll.

    Ich finde es super für Anfänger oder um ein paar Sachen zu testen.
    Ein Programmierer wird es eher nicht nutzen, aber ich werde es definitiv mal ansehen um mich weiterbilden zu können.

    Somit wäre der einstieg in Pimcore um ein paar stufen niedriger.
    • 11. April 2012, 11:36
      Comment by Johannes
      Also das ist aus meiner Sicht ein wichtiger Schritt. Und wenn man bei Installation des Testpakets schon ein paar sinnige, grundlegende Sachen zur Verfügung gestellt bekommt: Warum nicht benutzen?

      Es geht ja darum, dass man das Rad nicht jedesmal neu erfindet.

      Ich denke, wir sind nicht die einzigen, die sich eine Grundinstallation des Systems mit diversen Grundfunktionalitäten / Plugins erstellt haben, von dem man dann die Entwicklung neuer Seiten startet.
  4. 27. September 2012, 15:46
    Comment by webdepp
    Hi,

    beim Lesen fällt mir irgendwie auf, dass ihr euch auch mit Vergleichen immer im WCMS Rahmen bewegt.

    _pim_core ist ja eben nicht nur ein reines WCMS, sondern hat auch ein gewaltiges Augenmerk auf die PIM-Funktionalität gerichtet.
    Da muss man mit zweierlei Maß messen!
    • 11. October 2012, 08:24
      Comment by Johannes
      Hi webdepp -

      Ich finde die dynamische Erstellung von Klassen und Objekten via extJS im Backend auch sehr gelungen - Das Konzept der Trennung der Assets von Dokumenten ist allerdings nichts Neues. Aber das kritisiere ich im ursprünglichen Artikel auch nicht.

      Ich gebe darin Feedback, dass das System meiner Meinung nach noch zu spezialisiert ist und dadurch wertvolle Zielgruppen verliert - Die es aber locker erreichen könnte.

      Ansonsten ist pimcore meiner Meinung nach keine "Kategorie für sich", sondern muss sich sehr wohl mit anderen CMS am Markt messen lassen. Hier rede ich ganz konkret von den Themen Community-Größe, Dokumentation, Sicherheit, Update-fähigkeit und Systemanforderungen.

      So sind mir in der täglichen Arbeit und im täglichen Betrieb von pimcore-Sites in den letzten Monaten definitiv noch Punkte aufgefallen, die auch durchaus gegen die Nutzung von Pimcore sprechen.

      Mein Gesamteindruck ist aber nach wie vor positiv: Und andere sehen das offensichtlich genauso, da das CMS ja einen Preis nach dem anderen abräumt.

      mfG aus Salzburg!

Hier können Sie eine Antwort hinterlassen

CAPTCHA Image
Reload Image