Ankündigung

Einklappen
Keine Ankündigung bisher.

Eigenes CMS - Werkzeugkasten

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Eigenes CMS - Werkzeugkasten

    Guten Abend/Morgen (?) liebe PHP.de Community.


    Ich fange demnächst mit der Umsetzung eines eigenen CMS an.

    Hierfür möchte ich mir nun einen Plan erstellen, über die Voraussetzungen um die einfache Erweiterbarkeit, Wartbarkeit und Sicherheit der Applikation zu gewährleisten um dann richtig loslegen zu können.

    So nun habe ich mich ebend von 1 Uhr bis ebend (2:52) fix auf die Suche gemacht um alles was ich bisher weiß und denke zu benötigen zusammenzutragen.

    Die Buchlinks stehen für die Werke, welche ich kaufe/gekauft habe um die Kenntnisse zu erlangen, welche man benötigt.

    _______________________________________________

    Benötigte Kenntnisse:

    MVC/TemplateEngines (Wahrscheinlich darf man nicht beides in einen "Topf" werfen ?)
    PHP Design Patterns (Oreilly, Buch überhaupt empfehlenswert für die o.g. Themen ?)

    Objectorientiertes PHP
    PHP & MySQL von Kopf bis Fuß (Oreilly)
    PHP Design Patters (Oreilly)

    SQL (MySQL)
    SQL von Kopf bis Fuß (Oreilly)

    Sicherheit
    Sichere Webanwendungen: Das Praxisbuch (Galileo Computing)

    Zum Escapen von Daten, die in Mysql gespeichert werden sollen nutzt man mysql_real_escape_string, und das macht man ganz genau im Querystring.

    htmlspecialchars wird genutzt, um Daten, die aus der Datenbank kommen im HTML-Umfeld auszugeben. Das Behandeln des $_POST-Arrays mit htmlspecialchars ist Unsinn.
    Ajax Security Tokens
    ________________________________________

    Worum es mir hauptsächlich geht:

    1.) Worauf sollte man besonders achten bei einem CMS (im Programmierstil)?
    Umfassen die Bücher alle "normalen" Themenaspekte um ein CMS "gut wartbar, erweiterbar und sicher" zu programmieren ?
    [Stichworte: objectorientierte Programmierung, PDO (Welches kein Buch umfasst ?)]


    2.) Was könnt ihr noch für allgemeine Tipps gebe, worauf es gerade bei einem CMS ankommt ?
    Dinge wie z.B. "Schreibe dir eine Klasse welches die Usereingaben verifiziert/xyz macht" oder "Schreibe besonders im Stil von xyz/achte auf xyz, es wird dir später sehr weiterhelfen".



    Ich weiß dass die Fragen etwas schwammig formuliert sind, dies ist jedoch der Tatsache geschuldet dass ich nicht weiß WAS mir genau noch fehlt.

    Momentan schreibe ich z.B. die Querys fast manuell mit mysql_query("Select..."), was ich bei dem CMS durch einen objektorientieren Stil vermeiden sollte.
    Bzgl. PDO habe ich keine Erfahrung, ich habe nur einiges dazu hier im Board gelesen.

    Danke im voraus für das Zeit nehmen, denn dieses Thema ist mir sehr wichtig.

    Dreamcatcher

  • #2
    Da könnte man vom Hundersten ins Tausendste kommen. Gerade CMS sind besonders umfangreich im Spektrum, weil sie im Idealfall ja auch flexibel auf viele Anwendungen passen sollen, einfach pflegbar und erweiterbar sein sollen. Installationsassistent, multiple Plattformen mit multiplen Voraussetzungen (zieh Dir mal die Pre-Checks und Konfigurationen von Typo3 rein!), Semantik, Grafikverarbeitung, Usability-Aspekte, Multi-User-Umgebung mit verschiedenen Berechtigungsstufen, ...
    [COLOR="#F5F5FF"]--[/COLOR]
    [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
    [COLOR="#F5F5FF"]
    --[/COLOR]

    Kommentar


    • #3
      ... multi-serverfähigkeit, Context/Host-Unabhängigkeit ( SaaS,... ), soll es ein Integrationsinterface für 3rd Party Produkte besitzen, wenn ja wo setzt die Integration an ( eher Content gebundenes Reading oder Applikationsintegration ), Content-Typ Transformation ( RSS -> HTML, ATOM -> PDF, XSLX -> HTML, XML -> Y ) von Hause aus, to be continued...

      zu 1:
      Bei den Fragen wäre es sicher grundlegend zu wissen ob...
      • Du das CMS vorerst für deine private Nutzung entwirfst, du also auf lange Sicht der Entwickler bleibst, oder...
      • Das CMS von mehreren Leuten aufgebaut wird, und...
      • Du Erfahrungen mit bzw. die Absicht hast Frameworks wie APF, ZF oder sonstwas zu benutzen.

      Wartbarkeit und hohe Flexibilität in der Erweiterungsfähigkeit haben zwar nichts mit dem aktuellen Entwickler zu tun, aber je nach "Skills" des Entwicklers werden sie realisiert. Du wirst sicher nicht jeden Aspekt deiner Anwendung "best Practise" umsetzen. Ganz einfach weil dir da vorerst die Kenntnis zu fehlen wird. ( Ich behaupte fast mal das kann keiner zu 100% )

      PDO / ADOdb halte ich für eine guten Ansatz.

      zu 2:
      • Benutzbarkeit, auch bei vielen Features. Nach einer Erweiterung: Erweiterungen werden integriert, nicht als Untermenü igrendwo angeklebt. Excel ist soo cool, ich hab letztens ein Feature gesucht, dann kam nen Update rein, und eh ich es fand hat Microsoft es rausgepatcht..
      • Geschwindigkeit, auch bei hohem Daten-Stamm und hoher Belastung. Benchmarks, dein Feind und Tadel. Wo hast du die schönsten Flaschenhälse im Core ? Welche Erweiterungsports sind am anfälligsten für Geschwindigkeitseinbuße, wie reduziere ich das auf ein tolerierbares Minimum ?
      • Flexibilität: Wo sind die Grenzen in der Anwendung ?
      • Modularität: Ist alles austauschbar ? Was ist austauschbar ?
      [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

      Kommentar


      • #4
        Frage dich zunächst einmal, warum du eigentlich ein eigenes CMS von Grund auf programmieren willst und ob das wirklich notwendig ist. Also was sind deine Bedürfnisse, was fehlt dir an den vielen verfügbaren Open Source CMS oder geht es lediglich darum, ein Übungsprojekt zum lernen zu haben, was nicht unbedingt produktiv eingesetzt werden muss?

        Wie nikosch schon angedeutet hat, ein wirklich brauchbares CMS ist nicht mal eben alleine gestemmt nachdem man ein paar Bücher gelesen hat, da verschätzt du dich vielleicht etwas...
        [IMG]https://g.twimg.com/twitter-bird-16x16.png[/IMG][URL="https://twitter.com/fschmengler"]@fschmengler[/URL] - [IMG]https://i.stack.imgur.com/qh235.png[/IMG][URL="https://stackoverflow.com/users/664108/fschmengler"]@fschmengler[/URL] - [IMG]http://i.imgur.com/ZEqflLv.png[/IMG] [URL="https://github.com/schmengler/"]@schmengler[/URL]
        [URL="http://www.schmengler-se.de/"]PHP Blog[/URL] - [URL="http://www.schmengler-se.de/magento-entwicklung/"]Magento Entwicklung[/URL] - [URL="http://www.css3d.net/"]CSS Ribbon Generator[/URL]

        Kommentar


        • #5
          Bevor Du Dir um so deteillierte Probleme Gedanken machst, solltest Du Dir klar machen, _Was_ das CMS erfüllen soll. Unglaublich umfangreiche CMSe gibt es ja zur Genüge. Da kannst Du Dir eigentlich alles abgucken. Ich denke, mal, Du willst spezielle Anforderungen erfüllen?

          Geplant werden sollte das wie eine Applikation. Ich vermute anhand der Fragestellung, dass Du nicht allzuviel Erfahrung hast. Daher prognostiziere ich mal, dass Du min. 4x alles umschmeißt und neu anfängst, bevor Du die ersten bewährungsfähigen Versionen zusammen bekommst. Und an dieser Stelle wirst Du dann Threads wie diesen nicht mehr brauchen

          EDIT: fab hat mir die Worte aus dem Mund genommen..

          Kommentar


          • #6
            Das wichtigste Grundprinzip:

            - Egal was du an einem Modul / Bereich deines Systems änderst, der Kern muss davon immer unberührt bleiben.

            Befolgst du das Prinzip nicht, hast du bei jeder Webseite einen anderen Kern und hinterher Wartungs-Horror.


            Und auf jeden Fall PDO mit Prepared Statements verwenden. mysql_* sollte bei Neuentwicklungen nicht mehr verwendet werden.

            Kommentar


            • #7
              CMS war ein zu "umfassender" Begriff, welchen ich hier in die Runde warf.
              Es wird ein CMS, aber eher ein CMS light, d.h. vom Funktionsumfang von z.B. Typo3 weit entfernt und doch mehr.

              @xm22
              Nach mehreren Tagen der Planung, kann ich deine Einschätzung nun bestätigen.
              Nun, nachdem der Plan steht ist die Planung deutlich leichter da ich weiß was zum Core gehört und was als Extension zählt.

              @nikosch
              Der Pre-Check bei Typo3 hat mir super geholfen die Voraussetzungen abzustecken und einen umfassenderen Blick zu gewinnen.
              Danke dir ebenfalls für das hervorheben der Semantik, welche bei mir eher im Hintergrund stand bzw. in der Planung unzureichend geplant wurde.

              @tr0y
              Ich glaube ich hatte es dir schon einmal gesagt, trotzdem:
              Es ist super dass du hier im Board deinen "Senf" dazu gibst.
              Ich freue mich über jeden Post von dir, da ich einfach immer extrem viel mitnehme und von deine Erfahrung profitieren kann.
              Dein Name in einem Thread ist quasi ein Gütesiegel für gute Qualität des Threads

              Es wäre sinnlos zu sagen was ich aus deinem Post mitnehmen konnte, da ich mir den _gesamten_ Inhalt mehrmals zu gemüte gezogen haben.

              @mquadrat
              Sehr wichtiger Ratschlag, welchen ich mir ganz oben auf die Planung geschrieben habe:
              "Egal was du an einem Modul / Bereich deines Systems änderst, der Kern muss davon immer unberührt bleiben"

              @fab
              Ich habe mich anfang etwas verschätzt bzgl. der Zeiteinschätzung.
              Nach der detaillierteren Planung (Danke nochmal an alle Poster), kam dann eine klarere Sicht auf Was/Wie/Wo zustande.

              Kommentar

              Lädt...
              X