[DEV] Firegraph CMS Version 1.0 [DEV] Reingaffen lohnt sich (ist was neues)!

  • Guten Tag “liebe” Retro Community. Heute moechte ich mein “ach so tolles” Projekt vorstellen.
    Hierbei handelt es sich um ein Retro Content Management System auf eine neue Art. Was da genau neu sein wird erfaehrt ihr gleich aber kurz moechte ich noch sagen bzw. schreiben wie es dazu kam. In der Szene kann man sehr viel nachlesen wo Leute meinen dass mal was neues kommen muss. Also wirklich was neues und nicht die ganze Zeit von Sulake (Habbo) abgeschaut (Bilder ausgeschlossen).

    Aus diesem Grund habe ich angefangen ein CMS zu programmieren. Aber nicht im Habbo Look sondern in einem Flat Desing was von mir gestalltet wurde. Ausserdem arbeitet es mit Media Queries. Das heisst soviel wie “die Web Seite ist auf allen Endgeraeten angepasst”. Schaut doch einfach mal im Spoiler “Wunderkiste” nach, dort findet ihr die ersten Screenshots. Soviel zum Thema Desing.

    Kommen wir nun zum Interessanten Teil, die Technik. Das CMS wird moeglichst professionell programmiert. Also wird Objektorientierte Programmierung (kurz: OOP) angewendet. Als MySQL-Schnittstelle wird PHP DATA Objects (kurz: PDO) verwendet. Ein ausgekluegeltes Template System sowie ein Language System was auf die IP des Besuchers reagiert hat das ganze auch (Sprachen: English, Deutsch und Spanisch! Natuerlich kann man selbst noch mehr Sprachen hinzufuegen). Also recht cool. Gegen Sicherheitskritische Attacken hat es einen guten Schutz. XSS, SQLi, CSRF und Session Fixation sind zu 95% ausgeschlossen. Jeder Input und andere Kritische Stellen werden gefiltert also ist XSS nicht moeglich. Bei SQLi regelt es PDO mit seinem “prepared statement”. Also ist SQLi auch nicht moeglich. Bei CSRF sieht es anders aus. Ich habe mir lange ueberlegt wie ich nun ein Token System mache. Aber um ehrlich zu sein.. Das Token System wurde von mir irgendwie zusammen kopiert Xd. Aber es ist sicher. Gegen Session Fixation wird ganz einfach aber gut “session_regenerate_id()” angewendet. Das ersaetzt die alte Session ID durch eine neue. Das war es auch schon ueber die Technik. Ah genau! Fuer die ganz schlauen! Schaut im Spoiler “Wunderkiste” nach. Dort hat es ein paar Snippets vom CMS.

    Features hat das ganze auchnoch. Wenn ihr jetzt irgendwie Badge Shop etc. erwartet. Schlagt es euch aus dem Kopf.. Das CMS wird mehr Private (nicht oeffentliche) Features besitzten als Public (oeffentliche) Features. Hmm es hat noch garkeine Public Features wenn ich so nachdenke Xd... Aber Private Features hat es schon ein paar. Ich verrate bisher nur ein Feature und zwar waere das automatisches Anpassen der Datenbank fuer den Emulator. Ob Swift, Plus, Butterstorm, Butterfly oder Phoenix Emulator. Stellt man in der Config ein welcher Emulator man anwenden will werden die benoetigten Informationen geupdatet. Und jetzt kommt das beste! Die User Informationen werden mit geupdeaet! Also erspart man sehr viel arbeit! Das wars!

    Zu guter letzt will ich noch sagen bzw. schreiben. Ja ich weiss die “Vorstellung” ist schrecklich geschrieben. Das ist nunmal meine groesste Schwaeche. Was ihr auchnoch wissen solltet! Das ganze ist ein Projekt aus Spass. Zurzeit hab ich daran Spass in PHP zu programmieren. Es bockt jeden Tag mehr. Aber es kann irgendwann mal passieren das ich keine Lust mehr darauf hab. Dann wird nichtmehr (zumindest eine weile lang) nichtmehr daran programmiert.

    Wichtige Informationen:

    Das Frigus Hotel wird das Public Beta Hotel sein vom Firegraph CMS Version 1.0!

    Name des CMS: Firegraph
    Kommende Version: 1.0
    Release Datum: Unknow!
    Public Beta: https://www.facebook.com/Frigushotel

    Liebe Gruesse Equa Shepard

    P.s Klar gibt es bestimmt dinge die man besser programmieren koennte, man kann mich auch gerne darauf ansprechen aber dann bitte NETT und nicht irgendwie tyrannisch! Dankeschoen. Und ja es werden mehr Snippets / Screens kommen. So 1 Screen und 1 Snippet pro Woche.

    Wunderkiste:

    Spoiler anzeigen

    Zurzeit 1 Screen (noch nicht fertig):

    Spoiler anzeigen


    Zurzeit 1 Snippet:

    Spoiler anzeigen
  • Ich weiß nicht, wann die User hier endlich den Sinn von objektorientierter Programmierung verstehen werden.

    Cheers,
    Steve Winfield


    Niemals!
    Das ist leider das Problem. Für die Kiddies hier ist OOP, sobald sie eine Klasse mit Funktionen haben... Egal wie hirnlos die Klasse und dessen Funktionen sind.
    "Hey, ich hab eine ein Klasse "Hotel" mit tausend einzelnen Funktionen..."

    so far
    Yannici

  • Cool wie ihr gleich beurteilt. Habt ihr ueberhaupt schonmal was richtiges vom Code gesehen? Ausser die Login Funktion? Glaube nicht :D Aber na gut danke fuer euer Feedback.

  • Das Problem mit OOP ist, dass viele Programmierer hier denken, dass Klassen Ansammlungen von Funktionen sind.
    So machen sie eine Klasse mit dem Namen User, und machen da alle Funktionen rein, die irgendwas mit Usern machen.

    Eigentlich sollte man sich ein User Objekt so vorstellen, dass ein Objekt einen einzigen User modelliert.
    - __construct($username) - Weist dem Objekt einen Benutzernamen zu
    - addCredits($count) - Fügt Taler einem Benutzer hinzu
    - giveItem(Item $item) - Gibt dem Benutzer ein Item
    - makeFriendRequest(User $to) - Macht eine Freundschaftsanfrage an den Benutzer

    Der Code würde dann am Ende so aussehen

    PHP
    $user = new User("Johnix");
    $user2 = new User("Bob");
    
    
    $user->addCredits(500); // Fügt dem Benutzer Johnix 500 Taler hinzu
    $user->giveItem(new Item(1)); // Gibt dem Benutzer ein Item
    $user->makeFriendRequest($user2); // Sendet eine Freundschaftsanfrage an Bob

    Jetzt hat der Benutzer Johnix 500 Taler mehr, ein Item (mit der ID 1) und hat eine Freundschaftsanfrage an Bob gesendet.
    Man muss dem Objekt hier keine Benutzerdaten übergeben wie z.B.
    $user->addCredits("Johnix",500)
    Da das Objekt von sich aus den Benutzernamen weiß.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!