Auf jeden Fall hat es riesig viel Spaß gemacht mein eigenes CMS zu entwickeln und dazu eine kleine Dokumentation zu schreiben. Auch wenn ich wiedermal den Aufwand, gerade für das Schreiben der Dokumentation, unterschätzt habe.

Ich hoffe euch, meine Leser, hat das Lesen meiner Artikel auch Freude bereitet und ihr habt vielleicht zusätzlich auch noch was neues gelernt.

Nun wünsche ich euch ein besinnliches Weihnachtsfest und einen guten Rutsch ins neue Jahr.

Zum Abschluss meiner REDcms Dokumentation bekommt ihr natürlich auch nochmal den gesamten REDcms 17, einschließlich dem Datenbank-Backup.

Ähnliche Beiträge

• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design
• Tag 19 – Formulare
• Tag 18 – HTML-Vorlagen

Mehrbenutzer-System

Um in meinem System auch mit mehreren Benutzern Arbeiten zu können, sollte natürlich als erstes die Anmeldung am System und damit verbunden die Verwaltung der Benutzer geändert werden.

Zur Zeit wird die Anmeldung, also der Benutzername und das Kennwort innerhalb der „Login“-Klasse verwaltet. Wenn es jetzt mehrere Benutzer geben soll, dann wäre es sinnvoller die Benutzernamen und Passwörter in die Datenbank auszulagern. Wenn sich dann ein Benutzer am System anmelden möchte wird in der Datenbank nachgesehen ob es den Benutzer mit dem dazugehörigen Passwort auch gibt. Falls ja können zum Beispiel dann weitere Informationen aus der Datenbank geladen werden, wie bspw. der Vor- und Zuname des Benutzers. So können die Benutzernamen Nicknamen, also fiktive Name, sein und der Benutzer wird trotzdem mit seinem richtigen Namen angesprochen. Auch könnte dann automatisch beim Schreiben neuer Seite bzw. neuer Boxen der Name des Redakteurs eingetragen werden und nicht wie zur Zeit von Hand.

Das schöne an der OOP ist das die „Login“-Klasse in ihrer Benutzung wahrscheinlich nicht geändert werden bräuchte, denn auch weiterhin wird man sich darüber an- und abmelden können. Selbst die Anfrage ob der Benutzer schon angemeldet ist, die von den verarbeitenden Klasse an die „Login“-Klasse gestellt wird, wird bleiben. Hinzukommt eigentlich nur, dass in der Session zusätzliche Angaben, wie den Vor- und Zunamen, hinzugefügt werden.

Rechte-System

Auch die Erweiterung meines REDcms mit einem Rechte-System wird aller Voraussicht nach gar nicht so schwer. Ich könnte mir bei der Rechtevergabe zwei Funktionsarten vorstellen.

Auf der einen Seite wäre da die individuelle Rechtevergabe für jeden einzelnen Benutzer des Systems. Der Vorteil wäre die völlig freie Einstellbarkeit der Rechte für jeden Benutzer. Aber das kann gerade bei sehr vielen Benutzern schnell auch sehr aufwendig werden. Vor allem wenn ständig die Berechtigungen der Benutzer sich ändert.

Auf der anderen Seite könnte die Rechtevergabe gruppenspezifisch geschehen, dass heißt jeder Gruppe bekommt individuelle Berechtigungen und jeder Benutzer kann dann einer oder mehreren Gruppen zugewiesen werden. Aber auch dieses Vorgehensweise hat Nachteile. Zum einen ist der Aufwand zum Erstellen eines solchen Systems viel höher und zum anderen müssen gerade bei vielen individuellen Benutzereinstellungen jedes mal eine neue Gruppe angelegt werden. Was den Aufwand schnell wieder hoch treibt.

Ich werde mich aber wahrscheinlich für die letztere Möglichkeit entscheiden, da sie aus meiner Sicht heraus am praktikabelsten ist.

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design
• Tag 19 – Formulare
• Tag 18 – HTML-Vorlagen

Datei-Upload

In meinen verwendeten Online-Editor gibt es eine nette Erweiterung mit deren Hilfe man Bild, Flash-Dateien und andere Format auf den Server hochladen kann. Da diese Erweiterung für kommerzielle Projekte nicht kostenlos ist, könnte ich mir vorstellen in einer der nächsten Versionen die Möglichkeit des Uploads selber zu schreiben und in das System zu integrieren. So wäre ich davon unabhängig. Auch den Editor könnte ich in diesem Zuge selber erstellen, aber ich habe mich schon mehrfach daran gesetzt dies zu machen und habe es wegen des Aufwandes immer wieder abgebrochen. Naja vielleicht klappt es doch noch.

RSS-Feeds

RSS-Feeds sind zwar nicht die neue Form von Newsletter, aber man könnte sie damit vergleichen. Auf der eigenen Website gibt man den Besucher die Möglichkeit einzelne Seiten bzw. die gesamte Website als RSS-Feed zu abonnieren. Wenn dann Änderungen an diesem Feed entstehen werden diese in einer separaten XML-Datei abgespeichert.

Mit einer geeigneten Software, ich benutze dazu „Windows Live Mail“ kann man dann die Abos anfordern und bekommt die neuen Meldungen angezeigt. Das Praktische als Besucher der Website daran ist, dass man seinen Email-Account nicht veröffentlichen muss, denn man selber stellt dieses Abo in seiner Software ein. So ist auch das Abbestellen kinderleicht, denn man löscht ganz einfach in seiner Software das Abo und schon bekommt man keine Neuigkeiten mehr.

In einer der nächsten Überarbeitungen meines REDcms möchte ich diese Erweiterung des Abonnierens mit anbieten. Dass heißt das beim Anlegen und Ändern von Seite und Boxen die XML-Datei geändert werden muss. Dabei gibt es aber folgendes zu beachten. Was passiert wenn der Administrator des Systems eine Box von der Seite 1 in die Seite 2 verschiebt? Bekommen dann die Abonnenten die komplette Überarbeitung der XML-Datei zugeschickt?

Also gerade bei späteren Änderungen von abonnierten Informationen sollte ich mir genauere Gedanken machen. Vielleicht könnt ihr als Leser meines RSS-Feeds mir dabei helfen und ein paar Tipps im Kommentar hinterlassen.

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 20 – CSS-Design
• Tag 19 – Formulare
• Tag 18 – HTML-Vorlagen

Also wenn man z.B. eine neue Seite hinzufügen möchte, sollte nicht eine neue Browser-Seite geladen werden, wie es zur Zeit der Fall ist, sondern besser wäre es wenn über die Thickbox-Erweiterung das Formular innerhalb einer darübergelegten Ebene angezeigt wird. Eigentlich könnte jede Modifikation am System damit erweitert werden. So auch eine Zwischenabfrage vor dem Löschen eines Menüpunktes, einer Box oder gar einer gesamten Seite – auch könnten verlinkte Bilder in dieser neuen Ebene angezeigt werden.

So schön dies klinkt, einen kleinen Nachteil hätte diese Erweiterung allerdings doch. Wenn JavaScript deaktiviert ist, könnte es zu Problemen kommen, da ja AJAX bekanntlich auf JavaScript aufbaut. Aus diesem Grund empfehle ich bewusst zur Zeit solche Erweiterungen nur im kontrollierten Rahmen anzuwenden. In meinem Fall wäre das der Administrationsbereich. Hier sollte JavaScript schon aus dem Grund aktiviert sein, um den Online-Editor zu benutzen. Im Frontend-Bereich wo jeder Besucher die Links benutzen möchte, ist es vielleicht zu viel verlangt.

Auch habe ich zur Zeit die Thickbox-Erweiterung nicht mit integriert, um die Übersichtlichkeit und damit die Verständlichkeit nicht zu gefärhden.

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design
• Tag 19 – Formulare

Screen-Design

Das Design besitzt den klassischen Aufbau eines 2spaltigen Layouts mit einem Kopfbereich und einer Fußzeile. So können alle wichtigen Informationen übersichtlich untergebracht werden.

+------------------------------------+
| Website-Titel                      |
| Slogan                             |
+---------------+--------------------+
| Seitentitel   | Sidebar            |
| Einführung    | +----------------+ |
| +-----------+ | | Navigation     | |
| | Box-Titel | | +----------------+ |
| | Box-Text  | | +----------------+ |
| +-----------+ | | Administration | |
|               | +----------------+ |
+---------------+--------------------+
| Copyright                          |
+------------------------------------+

Reset-Datei

Um die unterschiedlichen CSS-Werte der verschiedenen Browser besser in den Griff zu bekommen, wird als erstes eine Reset-Datei geladen die alle wichtigen Style-Angaben für mich vordefiniert.

1. body, div, dl, dt, dl, ul, ol, li, h1, h2, h3, h4, h5, h6,
2. pre, form, fieldset, input, p, blockoute, th, td {
3. margin:0;
4. padding:0;
5. }
7. h1, h2, h3, h4, h5, h6 {
8. font-size:100%;
9. }
10. ol, ul {
11. list-style:none;
12. }
13. adress, caption, cite, code, dfn, em, strong, th, var {
14. font-style:normal;
15. font-weight:normal;
16. }
17. table {
18. border-collapse:collapse;
19. border-spacing:0;
20. font-size:100%;
21. }
22. fieldset, img {
23. border:0;
24. }
25. caption, th, td {
26. text-align:left;
27. vertical-align: top;
28. }
29. q:before, q:after {
30. content:”;
31. }

Bei umfangreicheren Designs im Webbereich hat sich weiterhin eingebürgert, dass man das Layout der Site vom Design getrennt behandelt. Auch ich habe zwei separate Datei („layout.css“ und „design.css“) dazu erstellt.

Layout-Datei

Als Erstes möchte ich das Layout erklären. Um die Website zu zentrieren, habe ich um den gesamten Inhaltsbereich eine „div“-Container erstellt. Somit kann ich alles gut mittig mit einer Breite von 720 Pixeln platzieren.

1. body {
2. margin: 0;
3. padding: 0;
4. text-align: center;
5. }
6. #page {
7. width: 720px;
8. margin: 0 auto;
9. text-align: left;
10. }

Die Überschriften innerhalb meines Kopfbereichen sind jetzt sehr nah am Rand weswegen ich ihnen etwas Abstand gegeben habe.

1. #branbing {
2. padding: 5px;
3. }

Im Prinzip werde ich jedem „div“-Container diesen Abstand geben. Ich habe ihn bewusst in die Layout-Datei und nicht in die Design-Datei geschrieben, weil er die Breiten der „div“-Container beeinflusst.

Um die zwei Spalten zu platzieren, habe ich beide per „float“-Befehl angeordnet, ihnen Breiten und Abstände gegeben.

1. #content {
2. float: left;
3. width: 500px;
4. margin-right: 10px;
5. padding: 5px;
6. }
7. #sidebar {
8. float: left;
9. width: 190px;
10. padding: 5px;
11. }

Damit der Fußbereich dann auch wieder unterhalb dieses Bereiches weiterläuft, habe ich auch ihn in der Layout-Datei ein paar Werte gegeben.

1. #copyright {
2. clear: both;
3. padding: 5px;
4. }

Zum Schluss habe ich noch den Inhalt der Administrationsbox layoutet. Dabei rücke ich den Code per Tab weiterein je tiefer die Verschachtelung ist.

1. #content .adminBox {
2. font-size: 0.8em;
3. }
4. #content .adminBox p {
5. margin: 0;
6. }
7. #content .adminBox li {
8. display: inline;
9. }
10. #content .adminBox li a {
11. float: left;
12. display: block;
13. }

Design-Datei

Zur Zeit habe ich nur wenige design-technische Änderungen vorgenommen. Als erstes habe ich allgemeinen Definitionen erstellt.

1. body {
2. color: #FFF;
3. background-color: #CCC;
4. font: 14px/1.4em “Trebuchet MS”, Arial, Helvetica, sans-serif;
5. }
7. input:focus, textarea:focus, select:focus {
8. color: #000;
9. background: #fff;
10. border: 1px solid red;
11. }

Div-Page

Der „page“-Container bekommt zusätzlich noch eine kleine Überarbeitung.

1. #page {
2. color: #000;
3. background-color: #FFF;
4. }

Div-Branding

Da in meinem Fall der Kopfbereich nur Angaben über das Projekt enthalten soll besteht dieser nur aus zwei Überschriften.

1. <div id="branding">

2. 	<h1>RE-Design</h1>

3. 	<h2>REDcms Advents</h2>

4. </div>

In der CSS-Datei wird dann folgende Formatierung darauf angewendet:

1. #branding {
2. background-color: #333;
3. color: #FFF;
4. font-family: Georgia,”Time New Roman”, Times, serif;
5. font-style: italic;
6. }
7. #branding h1 {
8. font-size: 3em;
9. line-height: 1em;
10. }
11. #branding h2 {
12. font-size: 1.5em;
13. line-height: 1em;
14. color: #3C0;
15. }

Div-Content

Als nächstes werden alle wichtigen Tags im „content“-Container definiert.

1. #content h2, #content h3, #content h4, #content h5, #content h6 {
2. font-family: Georgia,”Time New Roman”, Times, serif;
3. font-style: italic;
4. line-height: 1em;
5. margin-bottom:0.5em;
6. }
7. #content h2 {
8. font-size: 2em;
9. }
10. #content h3 {
11. font-size: 1.4em;
12. }
13. #content h4 {
14. font-size: 1.2em;
15. }
16. #content h5 {
17. font-size: 1.1em;
18. }
19. #content h6 {
20. font-size: 1em;
21. }
22. #content p {
23. margin-bottom: 1em;
24. text-align: justify;
25. }

Zusätzlich werden noch die Listen der Metaangaben gestylt.

1. #content ul.meta {
2. font-size: 0.8em;
3. }
4. #content ul.meta li {
5. margin-bottom: 0.5em;
6. }

Auch die angezeigten Formulare sind nicht von der Überarbeitung durch das Design-CSS verschont geblieben.

1. #content .add fieldset {
2. border: 1px solid #333;
3. padding: 5px;
4. margin-bottom: 1em;
5. }
6. #content .add legend {
7. border: 1px solid #333;
8. background-color: #CCC;
9. padding: 0 1em;
10. }
11. #content .add label {
12. font-size: 0.8em;
13. }
14. #content .add label.before {
15. display: block;
16. }
17. #content .add input,
18. #content .add textarea {
19. width: 470px;
20. font-family: sans-serif;
21. font-size: 1em;
22. padding: 5px;
23. }
24. #content .add option:hover {
25. background-color: #CCC;
26. }

Div-Sidebar

Da in der Sidebar mehrere Boxen existieren können, habe ich als erstes grundlegende Einstellungen vorgenommen.

1. #sidebar .box {
2. border:1px solid;
3. margin-bottom: 1em;
4. }
5. #sidebar .box h4 {
6. background-color:#333;
7. color: #FFF;
8. text-align: center;
9. margin-bottom: 0.2em;
10. }

Für die Navigation gab es dann noch separate Einstellungen.

1. #sidebar #navigation {
2. }
3. #sidebar #navigation ul {
4. margin: 5px 5px 1em 5px;
5. }
6. #sidebar #navigation ul ul {
7. margin: 0 0 0 1.5em;
8. }

Ebenso für den Login bzw. das Logout und die Box „über mich“.

1. #sidebar #login {
2. }
3. #sidebar #login p {
4. font-size: 0.8em;
5. margin: 5px;
6. }
7. #sidebar #login legend {
8. font-style: italic;
9. margin: 0;
10. padding: 0;
11. text-transform: uppercase;
12. }
13. #sidebar #login strong {
14. font-weight: bold;
15. text-transform: uppercase;
16. }
17. #sidebar #login ul {
18. margin: 5px;
19. }
20. #sidebar #login a {
21. padding-left: 20px;
22. }
23. #sidebar #login .page {
24. background: transparent url(“/REDcms/templates/images/icons/page.png”) no-repeat;
25. }
26. #sidebar #login .box {
27. background: transparent url(“/REDcms/templates/images/icons/box.png”) no-repeat;
28. border: none;
29. }
30. #sidebar #login .menu {
31. background: transparent url(“/REDcms/templates/images/icons/menu.png”) no-repeat;
32. }
33. #sidebar #about_us {
34. }
35. #sidebar #about_us p {
36. font-size: 0.8em;
37. margin: 5px;
38. }

Div-Footer

Was noch fehlt, ist der Fußbereich. Hier sind nur die Farben geändert worden.

1. #copyright {
2. background-color: #333;
3. color: #FFF;
4. }
5. #copyright a {
6. color: #FFF;
7. }

Div-Debug

Eine kleine Besonderheit habe ich meinen Debugging gegeben. Jedes mal wenn die allgemeine Funktion „code()“ aufrufe, erzeuge ich eine „div“-Container mit der Klasse „debug“.

1. function code($msg, $code=HTML_CODE)
2. {
3. $msg = print_r($msg, true);
5. if($code == HTML_CODE)
6. {
7. $msg = htmlentities($msg);
8. }
10. echo ‘<div class=”debug”><pre>’.$msg.‘</pre></div>’;
11. }

Zusätzlich designe ich per CSS das dieser Container über allem anderen angezeigt werden soll. Somit sehen ich ihn immer.

1. .debug {
2. position:absolute;
3. width: 300px;
4. height: 400px;
5. overflow: auto;
6. text-align: left;
7. padding: 5px;
8. color: #FFF;
9. background-color: #300;
10. border: 1px solid #000;
11. }

Print-Design

Eigentlich wollte ich eine spezielle Druckversion per CSS für die Ausgabe erstellen – doch leider fehlte mir dafür die Zeit. Da sie aber auch schon auf meiner ToDo-Liste steht, wird sie bestimmt im nächsten Release vorhanden sein.

Ich hoffe ihr habt Verständnis dafür.

Downloads

• REDcms_16.zip
• Layout.txt

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 19 – Formulare
• Tag 18 – HTML-Vorlagen

Page-Formular

Als erstes möchte ich das „Page“-Formular beschreiben. Wie schon im Artikel über die „Page“-Klasse geschildert werden nicht viele Information, die sich in 2 Gruppen unterteilen, vom Benutzer verlangt.

Im Inhaltsbereich wird der Titel der Seite, der Name des Autors und der Einführungstext angegeben, wobei nur der Titel als Pflicht verlangt wird. Da der Einführungstext sehr umfangreich sein kann, habe ich mich hier entschlossen einen online WYSIWYG-Editor einzubinden.

In den 2. Teil des Formulars werden vom Benutzer Zusatzinformationen für die Seite abgefragt. Als erstes ist das der Dateiname des zu verwendenden Templates. Mit der Select-Box kann der Veröffentlichungszustand der Seite angegeben werden. Die letzte Angabe, das Berechtigungslevel, wird zwar zur Zeit noch nicht benötigt, weshalb der Wert Null ist, kann aber später für bestimmte Zugangsberechtigungen dienen. So können später die einzelnen Seiten über verschiedene Level vor nicht berechtigten Besuchern geschützt werden.

Menu-Formular

Ähnlich wie das „Page“-Formular braucht auch das „Menü“-Formular nicht wirklich viele Angaben. Im Gegensatz zum „Page“-Formular sind die Eingaben aber in 3 Bereiche untergliedert.

Im ersten werden Angaben über den Namen des Menüpunktes und seinen Titel, er ist optional, verlangt.

Im zweite Teil des Formulars werden die Verbindungsangaben benötigt. Da der Benutzer beim Anlegen einer neuen Seite nicht direkt mitangeben muss wie sie im System verlinkt ist, kann er dies nun nachholen. Auch ist es so möglich mehrere Menüpunkte auf eine Seite zu verlinken oder er kann Seiten anlegen, die gar nicht verlinkt sind, wie z.B. Fehlerseiten.

Der letzte Bereich ist, ähnlich wie bei dem „Page“-Formular, wieder mit den Meta-Angaben über den Menüpunkt bestückt.

Box-Formular

Das letzte Formular in diesem Artikel ist das „Box“-Formular. Es ist wohl das umfangreichste von den Drein. Auch hier sind die Angaben in 3 Bereiche unterteilt.

Der Inhaltsbereich verlangt wieder nach einem Titel und nach einem Einführungstext, wie beim „Page“-Formular. Zusätzlich kann aber optional auch noch ein weiterführender Text mit angegeben werden. So ist es später möglich Übersichtsseiten mit nur den Einführungstexten der Boxen zu erstellen und über einen Link zu den weiterführenden Informationen zu gelangen.

Da jede Box zu einer Seite zugewiesen werden muss, wird im zweiten Teil des Formulars nach der Seite für die Box gefragt.

Wie bei den beiden vorhergehenden Formularen werden auch hier, im dritten Teil des Formulars werden vom Benutzer Angaben über das zu verwendende Template, über den Veröffentlichungsstatus und dem Zugriffslevel verlangt.

Donwloads

• Bilder.zip
• REDcms_15.zip

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design
• Tag 18 – HTML-Vorlagen

Index-Seite

In der Index-Seite steht das gesamte Grundgerüst. Neben dem allgemeinen Aufbau der HTML-Seite werden hier auch alle CSS-Dateien und JavaScript-Dateien geladen.

1. <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
2. <html xmlns=“http://www.w3.org/1999/xhtml” xml:lang=“de” lang=“de”>
3. <head>
4. <meta http-equiv=“Content-Type” content=“text/html; charset=utf-8″ />
5. <title>##TITLEBAR##</title>
6. <link rel=“stylesheet” href=“##BASEURL##/templates/styles/reset.css” />
7. <link rel=“stylesheet” href=“##BASEURL##/templates/styles/layout.css” />
8. <link rel=“stylesheet” href=“##BASEURL##/templates/styles/design.css” />
9. <script type=“text/javascript” src=“##BASEURL##/templates/scripts/script.js”></script>
10. <style type=“text/css”></style>
11. </head>
12. <body lang=“de” dir=“ltr”>
13. <div id=“page”>
14. <div id=“branding”>
15. <h1>##WEBSITETITLE##</h1>
16. <h2>##TAGLINE##</h2>
17. </div>
18. <div id=“main”>
19. <div id=“content”>
20. ##CONTENT##
21. </div>
22. <div id=“sidebar”>
23. ##SIDEBAR##
24. </div>
25. </div>
26. <div id=“copyright”>
27. <p>&copy; 2008 &ndash; <a href=“http://www.re-design.de”>RE-Design</a></p>
28. <ul class=“valid”>
29. <li><a href=“http://validator.w3.org/check?uri=referer”><img src=“http://www.w3.org/Icons/valid-xhtml10″ alt=“Valid XHTML 1.0 Transitional” height=“31″ width=“88″ /></a></li>
30. <li><a href=“http://jigsaw.w3.org/css-validator/”><img style=“border:0;width:88px;height:31px” src=“http://jigsaw.w3.org/css-validator/images/vcss” alt=“CSS ist valide!” /></a></li>
31. </ul>
32. </div>
33. </div>
34. </body>
35. </html>

In dieser Datei gibt es eigentlich nur zwei Schlüsselworte die durch neue Schnipsel ersetzt werden: ##CONTENT## und ##SIDEBAR##. Die restlichen Schlüsselworte werden direkt in der „Application“-Klasse mit Inhalt gefüllt.

Content-Bereich

Da der Content-Bereich sehr viele verschiedene Aufgaben erfüllen muss, gibt es auch sehr viele verschiedene Code-Schnipsel die an diesem Platz eingesetzt werden:

• page.tpl.html
• page.form.tpl.html
• menu.form.tpl.html
• box.form.tpl.html

Der wohl wichtigste Bereich in diesem System ist die „page.tpl.html“-Datei, weswegen ich sie hier auch näher mal beschreibe.

Page-Bereich

Der „Page“-Vorlage wird von der „Page“-Klasse benutzt und mit Inhalt gefüllt. Aber zusätzlich wird in der „Page“-Klasse auch die Inhalte für die einzelnen Boxen gesammelt. Deshalb wird das „##BOXES##“-Schlüsselwort nicht direkt von der „Page“-Klasse gefüllt.

1. <div class=“page” id=“page_##ID##”>

2. <h2>##TITLE## ##ADMIN##</h2>
3. <ul class=“meta”>
4. <li>##AUTHOR##</li>
5. <li>##MODIFIED##</li>
6. </ul>
7. <div class=“teaser”>
8. ##TEASER##
9. </div>
10. <div class=“boxes”>
11. ##BOXES##
12. </div>
13. </div>

Box-Bereich

Wie gerade beschrieben, füllt die „Box“-Klasse die „Box“-Vorlage und gibt sie dann an die „Page“-Klasse weiter, die diese dann an den richtigen Platz innerhalb der „Page“-Vorlage einsetzt.

1. <div class=“teaserbox” id=“box_##ID##”>
2. <h3>##TITLE## ##ADMIN##</h3>
3. <ul class=“meta”>
4. <li>##MODIFIED##</li>
5. </ul>
6. <div class=“teaser”>##TEASER##</div>
7. <div class=“body”>##BODY##</div>
8. </div>

Sidebar-Bereich

Auch die „Sidebar“-Vorlage wird von eine Klasse benutzt. Allerdings gibt es hier keine eigene Klasse sondern es ist die gleiche wie schon bei der „Index“-Vorlage. Es ist die „Application“-Klasse.

1. <h3>Sidebar</h3>
2. <div class=“box” id=“navigation”>
3. ##NAVIGATION##
4. </div>
5. <div class=“box” id=“login”>
6. ##LOGIN##
7. </div>
8. <div class=“box” id=“about_us”>
9. <h4>Über das Projekt</h4>
10. <p>Die ist nur ein kleines CMS-Beispiel. Ich hoffe ihr habt Spaß dieses zu benutzen. Falls ihr Fehler findet dann schreibt eine Nachricht an: <a href=“mailto:enrico@re-design.de” class=“nowrap”>enrico@re-design.de</a></p>
11. </div>

Die „Application“-Klasse füllt dabei 2 Schlüsselworte mit Inhalt. Auf der einen Seite (##NAVIGATION##) ist es die Menüstruktur und auf der anderen Seite (##LOGIN##) der Administrationskasten. Zusätzlich ist hier auch noch ein fester Kasten eingetragen. Er kann später entweder mit mehr, bzw. anderen Inhalt gefüllt oder gelöscht werden.

Downloads

• REDcms_13.zip

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design
• Tag 19 – Formulare

Deshalb haben Software-Programmierer Werkzeuge entwickelt in denen man relativ einfach seinen Text schreiben kann und über spezielle Buttons dann nach seinen Wünschen formatieren. Die Software übernimmt dann die Formatierung. Das macht das Arbeiten mit HTML-Quellcode recht simple. Trotzdem sollte man immer wissen was man tut. Schließlich herrschen im Internet ein paar andere Regeln als im alt geliebten Druck.

FCKeditor

Ich habe mich bei REDcms für den FCKeditor entschieden. Er ist sehr einfach an die speziellen Bedürfnisse anzupassen, bietet aber trotzdem einen sehr großen Funktionsumfang.

Der Editor wurde mit JavaScript umgesetzt und ersetzt ein Eingabefeld durch den im iframe befindlichen Editor. Das Einbinden kann über verschiedene Sprachen geschehen. In meinem Fall ist das PHP 5. Die Syntax zum Einbinden des Editors bzw. die Verwendung der „Editor“-Klasse sieht dann wie folgt aus:

1. $teaser = new FCKeditor(‘teaser’);
2. $teaser->Value = ‘<p>Anzuzeigender Text</p>’;
3. $teaser->Create();

Der übergebene Parameter beim Instanziieren der „Editor“-Klasse ist die ID des „textarea“-Tags der ersetzt werden soll. Um den Editor an den Browser zu senden kann man benutzen. In meinem Fall benutze ich die „CreateHTML()“-Methode der „Editor“-Klasse, um sie individuell in mein System einzusetzen.

Konfiguration

Die Konfiguration des Editors ist recht simple, da fast alle wichtigen Einstellungen schon vorgegeben sind. Da ich aber in meinem Fall ein paar Änderungen bzw. Anpassung vornehmen wollte, habe ich die „FCKeditor“-Klasse mit meiner „Editor“-Klasse erweitert.

Der Editor geht als erstes davon aus im Stammverzeichnis der Domain abgespeichert zu sein. Da ich mein System aber flexibel halten wollte, habe ich die „BasePath“-Eigenschaft angepasst. Auch habe ich die „ToolbarSet“-Eigenschaft auf „REDcms“ geändert. So kann ich in der Konfigurationsdatei des Editors meine eigenen Menüleisten erstellen. Auch empfand ich die Höhe des Eingabebereiches als zu klein, weswegen ich die „Height“-Eigenschaft auf 400 Pixel gesetzt habe. Zum Schluss passte ich die Konfiguration selbst mit 3 Einstellungen noch ein wenig an. Als erstes habe ich den Pfad zur Konfigurationsdatei geändert. Dann die Spracheinstellung auf deutsch geändert und zum Schluss die Verwendung des „LinkBrowsers“ aktiviert.

1. class Editor extends FCKeditor
2. {
3. function __construct( $instanceName )
4. {
5. parent::__construct( $instanceName );
7. $this->BasePath = BASEURL.‘/fckeditor/’;
8. $this->ToolbarSet = ‘REDcms’;
9. $this->Config["CustomConfigurationsPath"] = BASEURL.“/templates/scripts/myEditorConfig.js”;
10. $this->Config['DefaultLanguage'] = ‘de’;
12. $this->Height = 400;
14. $this->Config['LinkBrowser'] = true;
15. }
17. function __destruct(){}
18. }

myEditorConfing.js

Alle weiteren Einstellungen für die Inbetriebnahme des Editors habe ich dann in die „myEditorConfig.js“-Datei ausgelagert. So kann auch später noch relativ schnell Anpassungen vorgenommen werden.

Als erstes habe ich, wie oben schon beschrieben, meine neuen Menüleisten konfiguriert.

1. FCKConfig.ToolbarSets["REDcms"] = [

2. ['Source','-','Templates'],
3. ['Cut','Copy','Paste','PasteText','PasteWord','-','SpellCheck'],
4. ['Undo','Redo','-','Find','Replace','-','SelectAll','RemoveFormat'],
5. ‘/’,
6. ['Bold','Italic','Underline','StrikeThrough','-','Subscript','Superscript'],
7. ['OrderedList','UnorderedList','-','Outdent','Indent','Blockquote'],
8. ['JustifyLeft','JustifyCenter','JustifyRight','JustifyFull'],
9. ['Link','Unlink','Anchor'],
10. ['Image','Flash','Table','Rule','Smiley','SpecialChar','PageBreak'],
11. ‘/’,
12. ['Style','FontFormat'],
13. ['FitWindow','ShowBlocks','-','About'] // No comma for the last row.
14. ] ;

Als nächstes habe ich die URLs des „LinkBrowser“ angepasst. Damit habe ich die Möglichkeit Links auf Dateien, wie z.B. Bilder, Flash-Dateien oder ähnliches, schnell und komfortabel zu regeln.

1. FCKConfig.LinkBrowserURL = ‘/REDcms/ckfinder/ckfinder.html’;

2. FCKConfig.ImageBrowserURL = ‘/REDcms/ckfinder/ckfinder.html?type=Images’;
3. FCKConfig.FlashBrowserURL = ‘/REDcms/ckfinder/ckfinder.html?type=Flash’;
4. FCKConfig.LinkUploadURL = ‘/REDcms/ckfinder/core/connector/php/connector.php?command=QuickUpload&type=Files’;
5. FCKConfig.ImageUploadURL = ‘/REDcms/ckfinder/core/connector/php/connector.php?command=QuickUpload&type=Images’;
6. FCKConfig.FlashUploadURL = ‘/REDcms/ckfinder/core/connector/php/connector.php?command=QuickUpload&type=Flash’;

CKfinder

Um aber auch den „LinkBrowser“ benutzen zu können, habe ich die Erweiterung „CKfinder“ des FCKeditor mit in mein System installiert. Sie erweitert den Editor um die Möglichkeit komfortabel Dateien die verlinkt werden sollen, zu managen. Die Erweiterung ist so eingestellt dass sie automatisch im Unterordner „userfiles“ des REDcms-System nach Dateien sucht. Auch hier gibt es eine Konfigurationsdatei „config.php“, aber die Anpassungen sind hier mit einer kleinen Änderung schnell erledigt. Geändert werden muss nämlich nur wieder einmal die „$baseUrl“.

1. $baseUrl = ‘/REDcms/userfiles/’;

Leider konnte ich hier nicht mit meiner Konstanen „BASEURL“ arbeiten, da diese Datei separat aufgerufen wird und nicht direkt ins System eingebunden ist. Vielleicht werde ich später noch eine Routine dafür schreiben.

Downloads

• REDcms_12.zip

Ähnliche Beiträge

• Tag 16 – Zusatzklassen
• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design

Date Class

Als erstes nun die „Date“-Klasse. Sie hat im gesamten System die wohl kleinste Rolle, denn sie managt die Konvertierung von einer internationalen Schreibweise der Zeit (YYYY-MM-DD HH:MM:SS +00:00) in eine deutsche Schreibweise. Dabei unterscheide ich 2 verschiedene Ausgaben. Einmal ist das die Kurzschreibweise des Datums (DD. MM. YYYY) und dann noch die umfangreichere Schreibweise (Tag. Monatsname Jahr).

1. class Date
2. {
3. static $formatShort;
4. static $formatLong;
6. static function setShortFormat($format)
7. {
8. self::$formatShort = $format;
9. }
10. static function setLongFormat($format)
11. {
12. self::$formatLong = $format;
13. }
15. static function getShortFormat($date)
16. {
17. $ts = strtotime($date);
18. return strftime(self::$formatShort, $ts);
19. }
21. static function getLongFormat($date)
22. {
23. $ts = strtotime($date);
24. return strftime(self::$formatLong, $ts);
25. }
26. }

Um die Darstellung des Formates schnell ändern zu können wird diese in der Konfiguration abgespeichert und kann dadurch jeder Zeit geändert werden.

1. [Application]
2. dateformatlong = “%d. %B %Y”
3. dateformatshort = “%d. %m. %Y”

Ich habe mich bewusst hier für statische Methoden entschieden, um schneller auf die Konvertierungen zuzugreifen. So bekomme ich mit dem Befehl „Date::getLongFormat()“ und dem übergebenen Zeitstempel direkt die deutsche Schreibweise.

Editor Class

Um die Texte online besser editieren zu können habe ich mich für FCKeditor als WYSIWYG-Editor, also als Online-Editor entschieden. Dadurch wird den Redakteuren die Arbeit mit REDcms erleichtert. Wobei man nicht vergessen darf dass es nur ein Hilfsmittel ist. Die Kenntnisse über HTML wird trotzdem vorausgesetzt.

In der „Editor“-Klasse, die die „FCKeditor“-Klasse des Online-Editors erweitert, wird nur während der Instanziierung verschiedene Einstellungen schon mal mit geladen. Wie z.B. wo der Editor gespeichert ist, wo die Konfiguration zu finden ist, bzw. welche Sprache der Editor benutzen soll.

1. class Editor extends FCKeditor
2. {
3. function __construct( $instanceName )
4. {
5. parent::__construct( $instanceName );
7. $this->BasePath = BASEURL.‘/fckeditor/’;
8. $this->ToolbarSet = ‘REDcms’;
9. $this->Config["CustomConfigurationsPath"] = BASEURL.“/templates/scripts/myEditorConfig.js”;
10. $this->Config['DefaultLanguage'] = ‘de’;
12. $this->Height = 400;
14. $this->Config['LinkBrowser'] = true;
15. }
17. function __destruct(){}
18. }

Downloads

• REDcms_11.zip

Ähnliche Beiträge

• Tag 17 – WYSIWYG-Editor
• Tag 15 – Login Class
• Tag 14 – Template Class
• Tag 13 – Content Class
• Tag 10 – Request Class

Sie regelt das An- und Abmelden am System. Um die angemeldeten User verwalten zu können, nutze ich Sessions. Deshalb wird im Konstruktor mit der „session_start()“-Funktion eine Verbindung zur Session aufgebaut.

1. function __construct()
2. {
3. session_start();
4. }

Nach einer erfolgreichen Anmeldung z.B. werden in einer Session-Variablen „$_SESSION['REDcms']“ die Werte des Benutzers abgespeichert. Das geschieht in der „checkLogin()“-Methode. Sie prüft ob innerhalb der globalen Variablen „$_POST“ die korrekten Angaben sich befinden, die in der Klasse selbst abgespeichert sind.

1. public function checkLogin()
2. {
3. if($_POST['user'] == self::$user && $_POST['password'] == self::$password)
4. {
5. $_SESSION['REDcms'] = array();
6. $_SESSION['REDcms']['user'] = $_POST['user'];
7. $_SESSION['REDcms']['access'] = 0;
8. }
10. header(‘Location: ‘.$_POST['request']);
11. exit();
12. }

Natürlich gibt es auch die „logout()“-Methode, die die gespeicherten Werte aus der Session wieder löscht.

1. public function logout()
2. {
3. $_SESSION['REDcms'] = array();
4. unset($_SESSION['REDcms']);
6. header(‘Location: ‘.$_POST['request']);
7. exit();
8. }

So kann über die „isLogged()“-Methode relativ einfach überprüft werden ob der Benutzer angemeldet ist oder nicht. Das ist besonders bei den Verarbeitungsmethoden der „Page“-, „Box“- und „Menu“-Klasse wichtig.

1. public function isLogged()
2. {
3. if(isset($_SESSION['REDcms']) && $_SESSION['REDcms']['user'] == self::$user)
4. {
5. return true;
6. }
7. return false;
8. }

Als letztes gibt es noch die „getAdminBox()“-Methode. Sie hat die Aufgabe bei nicht angemeldeten Benutzern das Anmelde-Formular, bzw. bei angemeldeten Benutzern eine zusätzliches Menü anzuzeigen.

1. public function getAdminBox()
2. {
3. $content = ‘<h4>Administration</h4>’;
5. $tpl = new Template(TEMPLATEPATH);
7. if(empty($_SESSION['REDcms']))
8. {
9. $tpl->load(‘login.tpl.html’);
10. $tpl->set(‘##URL##’, BASEURL.‘/login.php’);
11. }
12. else
13. {
14. $tpl->load(‘logout.tpl.html’);
15. $tpl->set(‘##URL##’, BASEURL.‘/logout.php’);
16. $tpl->set(‘##URLPAGE##’, BASEURL.‘/page/0/add’);
17. $tpl->set(‘##URLBOX##’, BASEURL.‘/box/0/add’);
18. $tpl->set(‘##URLMENU##’, BASEURL.‘/menu/0/add’);
19. $tpl->set(‘##USERNAME##’, $_SESSION['REDcms']['user']);
20. }
22. if(isset($_SERVER['REDIRECT_URI']))
23. {
24. $tpl->set(‘##REQUEST##’, $_SERVER['REDIRECT_URL']);
25. }
26. else
27. {
28. $tpl->set(‘##REQUEST##’, BASEURL);
29. }
30. $content .= $tpl->get();
32. return $content;
33. }

Um die An- und Abmeldung relativ einfach zu machen, habe ich für jeden Prozess eine eigene PHP-Seite erstellt. Der Inhalt dieser Dateien ist sehr überschaubar.

1. <?php
2. error_reporting(E_ALL | E_WARNING);
4. require_once ‘includes.php’;
6. $login = new Login();
7. $login->checkLogin();
8. ?>

1. <?php
2. error_reporting(E_ALL | E_WARNING);
4. require_once ‘includes.php’;
6. $login = new Login();
7. $login->logout();
8. ?>

Zu einem späteren Zeitpunkt werde ich wahrscheinlich diese separaten Dateien mit in die „index.php“-Datei integrieren.

Downloads

• REDcms_10.zip

Ähnliche Beiträge

• Tag 16 – Zusatzklassen
• Tag 14 – Template Class
• Tag 13 – Content Class
• Tag 10 – Request Class
• Tag 9 – Application Class

Als erstes wird im Konstruktor festgelegt wo die Vorlagen zu finden sind, dazu wird ihn der Pfad mit übergeben. Zusätzlich wird die „value“-Eigenschaft mit einem leeren Array vorbereitet.

1. public function __construct( $path )
2. {
3. $this->path = $path.‘/’;
4. $this->values = array();
5. }

Um aber auch eine konkrete Vorlage zu laden, gibt es in der „Template“-Klasse die „load()“-Methode. Ihr wird der Dateiname übergeben. Die geladene Datei wird als String in die „source“-Eigenschaft abgelegt. Zusätzlich wird die „reload()“-Methode aufgerufen.

1. public function load( $file )

2. {
3. $this->source = file_get_contents( $this->path.$file );
4. $this->reload();
5. }

Sie kopiert den geladene String in die „template“-Eigenschaft. So muss nicht beim wiederholten Aufrufen der gleichen Vorlage immer wieder erst die Datei von der Festplatte geladen werden.

1. public function reload()
2. {
3. $this->template = $this->source;
4. }

Über die „set()“-Methode werden die Werte mit ihren Schlüsselworten in die Klasse geladen. Dabei werden 2 Parameter erwartet: der Schlüssel mit folgender Schreibweise „##SCHLÜSSELNAME##“ (Name in Großbuchstaben) und optional ein Wert.

1. public function set( $key, $value=” )
2. {
3. $this->values[$key] = $value;
4. }

Neben der „set()“-Methode gibt es natürlich auch die „get()“-Methode. Sie hat als Aufgabe aus dem Template einen brauchbare Quellcode für den Browser zu generieren. Dabei prüft sie als erstes ob überhaupt das Template schon geladen wurde. Danach ruft sie die „parse()“-Methode auf, um das Template mit den Werten zu verarbeiten. Falls der Methode über der „sourcecode“-Parameter der statische Wert Template::DISPLAY_CODE mitgegeben wurde, wird die Ausgabe in lesbaren HTML-Code konvertiert.

1. public function get( $sourcecode=true )
2. {
3. if( $this->source==null || $this->source==” )
4. {
5. return null;
6. }
8. $this->parse();
10. if( !$sourcecode )
11. {
12. $out = ‘<pre>’;
13. $out .= htmlentities( $this->template );
14. $out .= ‘</prev>’;
15. }
16. else
17. {
18. $out = $this->template;
19. }
20. return $out;
21. }

Die „parse()“-Methode hat nun die Aufgabe die Schlüsselworte innerhalb der Vorlage durch die Werte innerhalb der „values“-Eigenschaft zu ersetzen. Dabei prüft sie als erstes ob überhaupt das Template schon geladen ist. Danach ersetzt sie alle Werte. Zum Schluss werden noch alle nicht ersetzten Schlüsselworte in der Vorlage gelöscht, um unschöne Darstellungen zu vermeiden.

1. private function parse()
2. {
3. if( $this->source == null || $this->source==” )
4. {
5. die(‘TPL-Error: file not loaded!’);
6. }
8. foreach ( $this->values as $key => $value )
9. {
10. $this->template = str_replace( $key, $value, $this->template );
11. }
13. $this->template = ereg_replace( ‘##[A-Za-z0-9_]+##’, ”, $this->template);
14. }

Als letzte Methode innerhalb der „Template“-Klasse gibt es noch die „write()“-Methode. Sie macht im Grunde genau das was die „get()“-Methode auch macht, nur gibt sie das Ergebnis direkt an den Browser weiter.

1. public function write( $sourcecode=true )
2. {
3. echo $this->get( $sourcecode );
4. }

Wie schon eingangs erklärt, ist diese Klasse eine meiner ersten Klassen die ich konstant in meinen Projekten einsetze. Die Verwendung ist dabei sehr einfach. Als erstes erstellt man eine Vorlagendatei mit folgenden exemplarischen Quellcode:

1. <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
2. <html xmlns=“http://www.w3.org/1999/xhtml”>
3. <head>
4. <meta http-equiv=“Content-Type” content=“text/html; charset=utf-8″ />
5. <title>##TITLEBAR##</title>
6. </head>
7. <body lang=“de”>
8. <div id=“page”>
9. <div id=“branding”>
10. <h1>##WEBSITETITLE##</h1>
11. <h2>##TAGLINE##</h2>
12. </div>
13. <div id=“main”>
14. <div id=“content”>
15. ##CONTENT##
16. </div>
17. <div id=“sidebar”>
18. ##SIDEBAR##
19. </div>
20. </div>
21. <div id=“copyright”>
22. <p>&copy; 2008 &ndash; <a href=“http://www.re-design.de”>RE-Design</a></p>
23. </div>
24. </div>
25. </body>

26. </html>

Um diese Vorlage verwenden zu können muss man in PHP nur folgendes schreiben:

1. <?php

2. include_once ‘core/Template.php’;
4. $tpl = new Template(‘./templates/layouts’);
5. $tpl->load(‘index.tpl.html’);
7. $tpl->set(‘##TITLEBAR##’, ‘RE-Design - Beispiel-Template-Code’);
8. $tpl->set(‘##WEBSITETITLE##’, ‘RE-Design’);
9. $tpl->set(‘##TAGLINE##’, ‘Template-Klassen-Beispiel’);
10. $tpl->set(‘##CONTENT##’, ‘<p>Lorem ipsum dolor sit amet, … et netus et malesuada fames ac turpis egestas.</p>’);
11. $tpl->set(‘##SIDEBAR##’, ‘<div class=”box”><h2>Autor</h2><p>Enrico Reinsdorf</p></div>’);
13. echo $tpl->get(Template::DISPLAY_HTML);
14. ?>

Downloads

• REDcms_09.zip

Ähnliche Beiträge

• Tag 16 – Zusatzklassen
• Tag 15 – Login Class
• Tag 13 – Content Class
• Tag 10 – Request Class
• Tag 9 – Application Class

1. require_once (‘DB.php’);
2. class Database extends DB
3. {
4. }

Wichtig aus dieser Klasse ist einmal die „connect()“-Methode, die als ersten Parameter die Verbindungsangaben für die Datenbank als String erfordert. Der Rückgabewert dieser Methode ist dann das Datenbank-Objekt.

Mit diesem Objekt können dann alle SQL-Anfragen abgewickelt werden. Hier kein kleines Beispiel :

1. $query = ‘SELECT * FROM page’;
2. $res =& $db->query($query);
3. if (PEAR::isError($res)) {
4. die($res->getMessage());
5. }
6. while ($res->fetchInto($page))
7. {
8. array_push($pages, $page);
9. }

Downloads

• REDcms_07.zip

Ähnliche Beiträge

• Tag 7 – Datenbankstruktur
• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design

Allerdings hat die Vorgehensweise auch Nachteile. Da diese besondere Datei nicht vor fremden Augen geschützt ist, kann sie jeder leicht einsehen, der die URL kennt. Um das Ausliefern der Datei von Apache zu verhindern, habe ich die „.htaccess“-Datei angepasst.

1. <Files ~ “.(ini)$”>
2. Order allow,deny
3. Deny from all
4. </Files>

Kommen wir jetzt zur Konfigurationsdatei. Sie ist in 3 wichtige Bereiche eingeteilt. Der erste Bereich enthält Angaben die für die Webapplikation wichtig sind. Hier ist es z.B. die beiden Datumsformate um eine Kurz- und Langschreibweise des Datums festzulegen.

1. [Application]
2. dateformatlong = “%d. %B %Y”
3. dateformatshort = “%d. %m. %Y”

Im zweiten Bereich werden alle wichtigen Zugangsdaten für die Datenbank hinterlegt. In meinen Fall ist das die Serveradresse (host), der Benutzername (user), das dazugehörige Kennwort (password) und der Datanbank-Name (db)

1. [Database]
2. host = “localhost”
3. user = “demouser”
4. password = “password”
5. db = “redcms_advent”

Im letzten Bereich werden Informationen abgespeichert, die für das Anzeigen der Website wichtig sind. Da ich zur Zeit nur den Website-Titel und die Tagline brauche, habe ich auch das dort hingeschrieben.

1. [Website]
2. Title = “RE-Design”
3. Tagline = “REDcms Advents”

Was muss nun die „Configuration“-Klasse nun alles machen? Im Grunde genommen nur diese „INI“-Datei in einen zweidimensionalen Array laden und Methoden anbieten auf die Werte der Konfiguration zuzugreifen.

Das Laden der Konfigurationsdatei geschieht im Konstruktor. Mit der Methode „getValue()“ und ihrem 2 Parametern für die Sektion und dem Schüssel bekommt man den entsprechenden Wert zurück. Falls man statt einen einzelnen Wert die gesamte Sektion als Array bekommen möchte, so kann man mit der „getSection()“-Methode dies tun.

1. class Configuration
2. {
3. public $version = 1.0;
4. private $file;
5. private $config;
6. public function __construct($file) {
7. $this->file = $file;
8. try {
9. $this->config = parse_ini_file($file, true);
10. } catch (Exception $e)
11. < {
12. die(‘Config-Error parseIni: ‘.$e.‘: ‘.$file);
13. }
14. }
15. public function __destruct() {}
16. public function getValue($key, $section) {
17. return $this->config[$section][$key];
18. }
19. public function getSection($section) {
20. return $this->config[$section];
21. }
22. }

Um die „Configuration“-Klasse nicht versehentlich mehrmals zu laden, könnte man sie innerhalb eines Updates als Singelton-Pattern anlegen und benutzen. Auch wäre später das Ändern von Konfigurationseinstellungen möglich, womit man dann schnell im Administrationsbereich das System anpassen könnte.

Downloads

• REDcms_06.zip

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design
• Tag 19 – Formulare

Die wichtigste Verarbeitung findet innerhalb des Konstruktors statt. Dem Konstruktor werden 2 Arrays als Parameter mit übergeben, wobei z.Z. nur der Erste wichtig ist. Es handelt sich hierbei um die „GET“-Werte der URL. Da ja per „mod_rewrite“ und „.htaccess“ Anhänge an die „index.php“-Datei gemacht werden.

Als erstes wird der Modus gesetzt, dabei kommen die 4 Klassenkonstanten Request::MODE_PAGE, Request::MODE_BOX und Request::MODE_MENU zum Einsatz.

Als nächstes wird die ID ausgelesen. Falls sie nicht vorhanden ist wird ihr Wert auf 1 gesetzt.

Zum Schluss wird versucht die Aktion aus dem „GET“-Wert zu ermitteln. Falls keiner vorhanden ist, wird standardmäßig die Aktion „show“ benutzt. Auch hier kommen wieder Klassenkonstanten zu Einsatz. Diesmal sind es aber 5 Stück: Request::ACTION_ADD, Request::ACTION_EDIT, Request::ACTION_UPDATE, Request::ACTION_DELETE und Request::ACTION_SHOW.

1. function __construct($get, $request)
2. {
3. $this->request = $request;
5. if (!empty($get['mode'])) {
6. switch ($get['mode']) {
7. case self::MODE_BOX:
8. $this->mode = self::MODE_BOX;
9. break;
10. case self::MODE_MENU:
11. $this->mode = self::MODE_MENU;
12. break;
13. default:
14. $this->mode = self::MODE_PAGE;
15. }
16. } else {
17. $this->mode = self::MODE_PAGE;
18. }
20. if (!empty($get['id']) && !is_nan($get['id'])) {
21. $this->id = $get['id'];
22. } else {
23. $this->id = 1;
24. }
26. if(!empty($get['action'])){
27. switch ($get['action']) {
28. case self::ACTION_ADD:
29. $this->action = self::ACTION_ADD;
30. break;
31. case self::ACTION_EDIT:
32. $this->action = self::ACTION_EDIT;
33. break;
34. case self::ACTION_UPDATE:
35. $this->action = self::ACTION_UPDATE;
36. break;
37. case self::ACTION_DELETE:
38. $this->action = self::ACTION_DELETE;
39. break;
40. case self::ACTION_SHOW:
41. default:
42. $this->action = self::ACTION_SHOW;
43. }
44. } else {
45. $this->action = self::ACTION_SHOW;
46. }
47. }

Warum arbeite ich nicht mit Strings sondern mit Konstanten, die ja auch Strings beinhalten? Durch die Verwendung von Konstanten gewährleiste ich, dass die Werte unverändert eingesetzt werden können. Ohne Angst haben zu müssen, dass sie versehentlich überschrieben werden. Auch kann ich so später aus den String-Konstanten relativ schnell z.B. Integer-Konstanten machen und die Verwendung bleibt gleicht.

Die restlichen Methoden dieser Klasse sind ausschließlich die „Getter“- und „Setter“-Methoden von Mode, ID und Action.

Downloads

• REDcms_05.zip

Ähnliche Beiträge

• Tag 16 – Zusatzklassen
• Tag 15 – Login Class
• Tag 14 – Template Class
• Tag 13 – Content Class
• Tag 9 – Application Class

Wie funktioniert nun so was? Eigentlich recht simple. Die „index.php“-Datei, die automatisch bei jedem Request, also beim Aufrufen einer Seite, gestartet wird, initialisiert die „Application“-Klasse und speichert sie in der Variable $app ab. Somit habe ich die Möglichkeit jeder Zeit weitere Methoden dieser Klasse aufzurufen. Obwohl, eigentlich brauche ich nur 2 Stück, und auch die könnten rein theoretisch reduziert werden.

„init()“-Methode

Was passiert bei der Instanziierung? Der Konstruktor ruft die private Methode „init“ auf und diese lädt die zusätzlich benötigten Objekte. Zuerst wird aber das Datumsformat mit „setlocale(LC_ALL, ‘de’);“ gesetzt.

Danach wird in die „config“-Variable die „Configuration“-Klasse instanziiert. Diese lädt die Konfiguration, die in der „configuration.ini“-Datei hinterlegt ist. Um später auch eine HTML-Ausgabe benutzen zu können, wird die „Template“-Klasse anschließend in die „tpl“-Variable geladen. Ihr wird die Konstante mit dem Pfad zum Template-Ordner übergeben.In einer lokalen Variablen wird aus der Konfiguration der Array mit den Verbindungsangaben für die Datenbank geladen. Und in einer 2. lokalen Variablen wird der String vorbereitet der später für den Aufbau einer Datenbank-Verbindung wichtig ist. Nun wird die Verbindung zur Datenbank hergestellt und in der „db“-Variable abgespeichert. Nach einer Fehlerüberprüfung ob die Verbindung zum Datenbankserver hergestellt werden konnte, werden zum Schluss die Datumsformate auf der Konfiguration in das System integriert.

private function init()

{

setlocale(LC_ALL, ‘de’);

$this->config = new Configuration(‘./configuration.ini’);

$this->tpl = new Template(TEMPLATEPATH);

$db = $this->config->getSection(‘Database’);

$dsn = ‘mysql://’.$db['user'].‘:’.$db['password'].‘@’.$db['host'].‘/’.$db['db'];

$this->db = Database::connect($dsn);

$this->db->setFetchMode(DB_FETCHMODE_OBJECT);

if($this->db->isError($this->db))

{

die($this->db->getMessage());

}

Date::setLongFormat($this->config->getValue(‘dateformatlong’, ‘Application’));

Date::setShortFormat($this->config->getValue(‘dateformatshort’, ‘Application’));

}

„main()“-Methode

Nach der Initialisierung wird über die „index.php“-Datei die „main()“-Methode aufgerufen. Als erstes in dieser Methode wird die „Request“-Klasse in die „request“-Variable geladen. Ihr werden die globalen Variablen $_GET und $_REQUEST übergeben. Dies wird benötigt um anschließend über eine „switch“-Verzweigung zu entscheiden welche Informationen in die Klassenvariable „content“ geladen werden. Zum Schluss wird in die Klassenvariable „sidebar“ die Informationen zum Anzeigen der Sidebar gespeichert.

public function main()

{

$this->request = new Request($_GET,$_REQUEST);

switch ($this->request->getMode())

{

case Request::MODE_BOX:

$this->content = $this->getBox($this->request->getId());

break;

case Request::MODE_MENU:

$this->content = $this->getMenu($this->request->getId());

break;

case Request::MODE_PAGE:

default:

$this->content = $this->getPage($this->request->getId());

break;

}

$this->sidebar = $this->getSidebar($this->request->getId());

}

„getBox()“-, „getMenu()“-, „getPage()“-Methode

Alle drei Methoden besitzen den gleichen Aufbau, weshalb ich hier nur die „getPage()“-Methode erklären möchte.

Als erstes wird die passende Klasse in eine Klassenvariable geladen. Ihr wird die Verbindung zum Datenbankserver mitgegeben. Als nächstes wird über die „request“-Variable und ihrer „getAction()“-Methode entschieden, welche Aktion nun folgen soll. Dabei gibt es 4 zur Auswahl.

• hinzufügen
• ändern
• löschen
• anzeigen

Wobei die letzte Aktion generell immer aufgerufen wird, wenn keine Aktion vorhanden sein sollte. Die habe ich mit eingefügt, falls das System mal keine Aktion in der „request“-Variable findet. Anschließend wird aus der jeweiligen Klasse der Titel für die Titelleiste des Browsers angefordert um ihn später mit dem Titel des Systems zu kombinieren.

private function getPage($id=1)

{

$this->page = new Page($this->db);

$content = ”;

switch ($this->request->getAction()) {

case Request::ACTION_ADD:

$content = $this->page->add();

break;

case Request::ACTION_EDIT:

$content = $this->page->edit($id);

break;

case Request::ACTION_DELETE:

$content = $this->page->delete($id);

break;

case Request::ACTION_UPDATE:

$content = $this->page->update();

break;

case Request::ACTION_SHOW:

default:

$content = $this->page->get($id);

break;

}

$this->titlebar = $this->page->getTitle();

return $content;

}

private function getBox($id=1)

{

$this->box = new Box($this->db);

$content = ”;

switch ($this->request->getAction()) {

case Request::ACTION_ADD:

$content = $this->box->add();

break;

case Request::ACTION_EDIT:

$content = $this->box->edit($id);

break;

case Request::ACTION_DELETE:

$content = $this->box->delete($id);

break;

case Request::ACTION_UPDATE:

$content = $this->box->update();

break;

case Request::ACTION_SHOW:

default:

$content = $this->box->get($id);

break;

}

$this->titlebar = $this->box->getTitle();

return $content;

}

private function getMenu($id=1)

{

$this->menu = new Menu($this->db);

$content = ”;

switch ($this->request->getAction()) {

case Request::ACTION_ADD:

$content = $this->menu->add();

break;

case Request::ACTION_EDIT:

$content = $this->menu->edit($id);

break;

case Request::ACTION_DELETE:

$content = $this->menu->delete($id);

break;

case Request::ACTION_UPDATE:

$content = $this->menu->update();

break;

case Request::ACTION_SHOW:

default:

$content = $this->menu->get($id);

break;

}

$this->titlebar = $this->menu->getTitle();

return $content;

}

„getSidebar()“-Methode

In der „getSidebar()“-Methode wird als erstes in der lokalen Variable „login“ die Anzeigebox für die Sidebar gespeichert. Danach wird das selbe mit der Navigationsbox gemacht.

Zum Schluss wird dann mit Hilfe der Variable „tpl“ ein Template gefüllt und an die „main()“-Methode zurückgegeben.

private function getSidebar($id=1)

{

$login = Login::getAdminBox();

$navi = $this->getMenuBox(0);

$this->tpl->load(‘sidebar.tpl.html’);

$this->tpl->set(‘##NAVIGATION##’, $navi);

$this->tpl->set(‘##LOGIN##’, $login);

return $this->tpl->get($id);

}

„getMenuBox()“-Methode

Hier wird einfach nur mit der „Menu“-Klasse der Navigationsbaum erstellt und an die „getSicebar()“-Methode zurückgegeben.

private function getMenuBox($page_id=1)

{

$content = ‘<h4>Navigation</h4>’;

$menu = new Menu( $this->db );

return $content.$menu->getTree( $page_id );

}

„display()“-Methode

Die letzte Methode innerhalb der „Application“-Klasse ist die „display()“-Methode. Auch diese wird ähnlich wie die „main()“-Methode von der „index.php“-Datei direkt aufgerufen. Hier laufen dann alle vorherigen Verarbeitungen zusammen.

Als erstes wird der Website-Titel aus der Konfiguration geladen. Danach wird dieser mit dem Seitentitel kombiniert.

Zum Schluss wird das Template geladen, mit den Informationen gefüllt und dann an die „index.php“-Datei zurückgegeben. Diese zeigt den Inhalt schließlich an.

public function display()

{

$website = $this->config->getSection(‘Website’);

$this->titlebar = $website['Title'].‘ – ‘.$this->titlebar;

$this->tpl->load(‘index.tpl.html’);

$this->tpl->set(‘##BASEURL##’, BASEURL);

$this->tpl->set(‘##TITLEBAR##’, $this->titlebar);

$this->tpl->set(‘##WEBSITETITLE##’, $website['Title']);

$this->tpl->set(‘##TAGLINE##’, $website['Tagline']);

$this->tpl->set(‘##CONTENT##’, $this->content);

$this->tpl->set(‘##SIDEBAR##’, $this->sidebar);

return $this->tpl->get();

}

Downloads

• REDcms_04.zip

Ähnliche Beiträge

• Tag 16 – Zusatzklassen
• Tag 15 – Login Class
• Tag 14 – Template Class
• Tag 13 – Content Class
• Tag 10 – Request Class

Klassenübersicht

In den folgenden Tagen werde ich die einzelnen Klassen näher erklären. An dieser Stelle möchte ich euch erstmal nur eine kleine Übersicht über die verwendeten Klasen geben.

• Application
• Request
• Configuration
• Database
• Content
  • Page
  • Box
  • Menu
• Template
• Login
• Editor
• Date

Ich habe versucht möglichst wenige Klassen zu benutzen, um den Überblick bei der Entwicklung nicht zu verlieren. Wobei die „Application“-Klasse hier ein sehr zentrale Rolle spielt. Weitere wichtige Klassen sind „Page“, „Box“ und „Menu“. Sie beinhalten die eigentliche Verarbeitung der einzelnen Bereiche.

In der „Request“-Klasse werden die Angaben der URL, also der Adressierung verarbeitet. Um REDcms schnell anpassen zu können, habe ich mich für die Verarbeitung von einer externen INI-Datei entschieden. So bekommt der Administrator einen schnellen Zugriff auf die wichtigsten Einstellmöglichkeiten ohne großartig in den einzelnen Klassen suchen zu müssen.

Um eine einfache Trennung zwischen der Programmierung und den HTML-Dateien zubekommen benutze ich eine eigenen „Template“-Klasse. Sie stellt mir alle wichtigen Funktionen für das Verarbeiten zur Verfügung.

Mit der „Login“-Klasse wird die An- und Abmeldung am System geregelt. Weiterhin kann darüber geprüft werden ob ein Benutzer berechtigt, also angemeldet, ist eine Seite bzw. deren Informationen einzusehen.

Um die Datumsausgabe besser zu verarbeiten, habe ich mir eine Hilfsklasse „Date“ erstellt. Damit bin ich in der Lage den Timestamp in ein deutsche Datumsformat zu konvertieren.Und ich habe noch zwei weitere Hilfsklassen erstellt. Wobei ich bei der „Database“-Klasse nur eine Ableitung der „DB“-Klasse des PEAR-Framework und bei der „Editor“-Klasse eine Ableitung des FCKeditors.

Ähnliche Beiträge

• Tag 16 – Zusatzklassen
• Tag 15 – Login Class
• Tag 14 – Template Class
• Tag 13 – Content Class
• Tag 10 – Request Class

Da mein System zur Zeit noch sehr einfach strukturiert ist, reichen mir 3 Datenbank-Tabellen: Page, Box und Menu.

Page-Tabelle

Page Tabelle

In dieser Tabelle werden alle Informationen abgespeichert die für das Anzeigen einer einzelnen Seite wichtig sind. Wobei nur Basisinformationen abgespeichert werden, denn jede Seite kann ja beliebig viele zusätzliche Boxen haben.

Was wird also nun in dieser Tabelle abgespeichert? Natürlich erstmal die ID der Seite, die für die Adressierung wichtig ist. Weiterhin der Seitentitel, um auch dem Besucher der Website einen aussagekräftige Namen zu präsentieren. Auch habe ich mir überlegt das jede Seite die Möglichkeit hat einen Einführungstext abzuspeichern, sowie den Namen des Autors.

Um die einzelne Seite individuell zu gestalten, wird zusätzlich der Dateiname eines Templates mit abgespeichert.

Box-Tabelle

Box Tabelle

Zunächst einmal wird in jeder Box neben der eigenen ID auch die ID der Seite abgespeichert. Weiterhin gibt es auch die Möglichkeit einen Titel, einen Einführungstext und einen Haupttext abzuspeichern. Während der Titel und der Haupttext zwingend notwendig sind, ist der Einführungstext optional. So habe ich mir die Möglichkeit offen gehalten später Übersichtsseiten in mein REDcms hinzuzufügen.

<!– @page { margin: 2cm } P { margin-bottom: 0.21cm } –>Auch wird hier wieder eine Template-Datei gefordert, um die Gestaltung individuell anzupassen. Zusätzlich wird noch die Sortierung der einzelnen Boxen innerhalb der Seite mit abgespeichert. Diese Sortierung wird aber in der derzeitigen Version (1.0) noch nicht mitberücksichtigt. Ich habe aber vor in eine der nächsten Versionen auch die Sortierung mit zu implementieren.

Menu-Tabelle

Menü Tabelle

Getrennt von den einzelnen Seiten speichere ich die Menüstruktur ab. Das hat den Vorteil, dass ich so Seiten anlegen kann, die nicht direkt in der Website erscheinen sollen, wie z.B. Übersichtsseiten mit Suchergebnissen oder die Folgeseite eines Formulars oder Fehlerseiten (404-Error, etc.). Auch kann ich so mehrere Menüpunkte auf ein und die selbe Seite verlinken, wenn es nötig sein sollte das der Inhalt öfters angezeigt werden soll.

Hier wird also, wie bei der Box neben der eigen ID auch die ID der Seite abgespeichert. Zusätzlich wird aber auch der anzuzeigende Name des Links und optional ein Titel abgespeichert.

Downloads

• REDcms 03.zip

Ähnliche Beiträge

• Tag 12 – Database Class
• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design

„include“-Datei

Zu einem ist das die „include“-Datei. Sie lädt über den Befehl „include_once()“ die einzelnen Dateien die für den reibungslosen Ablauf des Systems benötigt werden. Weiterhin enthält sie eine kleine Funktion, die ich nicht mehr missen möchte.

1. function code($msg, $code=HTML_CODE)
2. {
3. $msg = print_r($msg, true);
4. if($code == HTML_CODE)
5. {
6. $msg = htmlentities($msg);
7. }
8. echo '<div><pre>'.$msg.'</pre></div>';
9. }

Sie ist sehr hilfreich, da es immer wieder vorkommt Quellcode, oder ähnliche Angaben im Browser zu veröffentlichen. Die Funktion erwartet mindestens einen Parameter – das was sie anzeigen soll. Der 2. Parameter ist hilfreiche wenn man HTML-Quellcode anzeigen möchte, da ja jeder Browser erstmal jeden Quellcode durch seine Render-Engine jagt und somit umwandelt. Standardmäßig wird jede Anzeige konvertiert, außer man setzt den 2. Parameter auf „HTML_RENDER“. Dabei handelt es sich, wie bei „HTML_CODE“ um eine Konstante, die 2. Datei definiert wird.

Auch habe ich noch eine 2. Hilfsfunktion eingebaut, sie aber später wieder daktiviert, weil sie bei den vielen Änderungen an der Struktur des Systems nur im Wege stand. Trotzdem möchte ich die hier kurz aufzeigen. Vielleicht kommt auch sie später wieder mit in die Application.

1. function __autoload($class_name)
2. {
3. $path = str_replace('_','/',$class_name);
4. $path = strtolower($path);
6. require_once('./core/'.$path.'.php');
7. }

„defines“-Datei

In der „defines“-Datei werden alle wichtigen Konstanten geladen, die das System und der Entwickler braucht. Gott sei dank sind das nur 4 Stück.

1. define('HTML_RENDER', 0);
2. define('HTML_CODE', 1);
3. define('BASEURL', dirname($_SERVER['PHP_SELF']));
4. define('TEMPLATEPATH', 'layouts');

Die ersten beiden Zeilen hatte ich ja gerade schon erklärt. Die Definition der BASEURL legt den absoluten Pfad zur Application fest. In meinen Fall ist das z.B. „http://www.re-design.de/weblabor/REDcms/demo“. So kann man später relativ schnell benötigte Dateien nachladen oder URL-Weiterleitungen programmieren.

Die letzte hat eigentlich das gleiche Ziel – schnell auf den Zielordner der Templates zuzugreifen. Wenn ich mir das aber hier jetzt näher ansehe, stelle ich fest dass es wohl auch sinnvoll wäre diese Definition in die Konfiguration des System auszulagern. So hat später der Verwalter des Systems schnelleren Zugriff um diesen Wert zu ändern. Vielleicht werden ich diese Angabe später noch optimieren.

Downloads

• REDcms_02.zip

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design
• Tag 19 – Formulare

Die genaue Interaktion des Programmeres mit dem Benutzer ist sehr vielfältig. Als erstes kann man sich von dem Frontend, also dem Bereich den der normale Benutzer sieht, über eine Anmelde-Maske an das Backend, dem Administrationsbereich, anmelden.

Danach erscheinen im Administrationskasten 3 weitere Links, um eine neue Seite, eine neue Box oder einen neuen Menüpunkt anzulegen. Außerdem kann man über den Button „abmelden” sich vom Administrationsbereich wieder abmelden.

Weiterhin erscheint hinter jedem Seitentitel, jedem Boxtitel und jedem Menüpunkt zwei Icons. Eins um die Seite, die Box bzw den Menüpunkt zu bearbeiten und eins um es zu löschen.

Es gibt also auch bei meinem CMS die klassischen Möglichkeiten zur Verwaltung von Content: hinzufügen, bearbeiten und löschen.

Welche Idee steckt hinter diesen 3 Bereichen?

Als erstes war mir wichtig die einzelnen Seiten sehr flexibel zu halten. Dazu habe ich mir überlegt, dass die tatsächlichen Texte der Seite in einzelne Boxen zu verpacken. Dadurch kann eine Seite sehr individuell aufgebaut werden.

Seite-Angaben

Was beinhaltet nun eine Seite? Eigentlich nur ihren Seitentitel und den Namen des jeweiligen Templates. Alle weiteren Angaben wie Einleitungstext und Autor sind optional.

Box-Angaben

Auch in der Box gibt es nicht viele, zwingende Informationen. Hier sind es der Boxtitel, der Haupttext, der Name des jeweiligen Templates und die Auswahl zu welcher Seite die Box gehört. Optional kann aber auch hier ein Einleitungstext und die Position (die Stelle innerhalb der Boxauflistung in der Seite).

Menü-Angaben

Hier sind nur 3 Angaben zwingend notwendig: der Name des Menüeintrages, die Zuordnung zu eines bestehenden Seite und ob der Menüeintrag ein Untermenü eines bestehenden Eintrages ist. Optional kann der Link mit einem Titel belegt werden.

Weitere Angaben

In allen drei Bereichen besteht die Möglichkeit die Veröffentlichung zu verneinen und damit die Seite, die Box bzw. den Menüpunkt im Frontend nicht anzeigen zu lassen. Außerdem ist schon ein Eingabefeld eingebaut, welches später das Zugriffslevel, also die Berechtigung, definiert.

Downloads

• Interaktion.zip

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design
• Tag 19 – Formulare

Bei komplexen bzw. skalierbaren Systemen entsteht dadurch schnell eine Unmenge an bei einzelnen Verarbeitungsdateien. Wenn man nun bedenkt, dass bei diesen Dateien oft ähnliche Verarbeitung zu Gange sind, wird einem schnell klar warum heutige CMS mit einer zentralen Verarbeitungsdatei arbeiten. Auch ich wollte bei REDcms diesen Trend verfolgen. Der Nachteil der dadurch entsteht, ist der das alle verarbeitungsrelevanten Befehle an diese zentrale Datei an gehangen werden müssen. Ein Beispiel für einen solchen Anhang wäre folgende URL:

„http://www.domain.tld/index.php?mode=page&id=1&action=show“

Solche URLs sind aber nicht gerade Suchmaschinen freundlich. Weswegen man mit der Konfigurationsdatei „.htaccess“ und der Modul-Erweiterung „mod-rewrite“ vom Apache-Server die URLs umschreibt. Eine bessere URL für das vorhergehen Beispiel wäre:

„http://www.domain.tld/page/1/show“

oder zumindest:

„http://www.doamin.tld/page/1“

Genau für diesen Zweck gibt es das Modul „mod_rewrite“ mit der man die URLs umschreiben kann.

Wie sieht die „.htaccess“-Datei aus?

Als erstes muss man Rewrite starten und dann braucht man die folgenden 3 Regeln:

1. RewriteRule ^([a-z]+)/*$ index.php?mode=$1&id=1&action=show
2. RewriteRule ^([a-z]+)/([0-9]+)/*$ index.php?mode=$1&id=$2&action=show
3. RewriteRule ^([a-z]+)/([0-9]+)/([a-z]+)$ index.php?mode=$1&id=$2&action=$3

Die Angabe nach RewriteRule ist das Suchmuster gefolgt von der Ersetzungsangabe. Das bedeutet in der ersten Regel, dass alle Angaben nach der Domain umgeleitet werden in die Ersetzungsangabe wobei die Angabe die im Suchmuster in den runden Klammern ([a-z]+) steht in den Platzhalter $1 in der Ersetzungsangabe eingefügt wird. Dazu ein paar Beispiele:

• / – /index.php?mode=&id=1&action=show
• /test – /index.php?mode=test&id=1&action=show
• /helloworld – /index.php?mode=helloworld&id=1&action=show

So gibt in der zweiten Regel 2 Platzhalter und dementsprechend auch 2 Bereiche mit den runden Klammern und in der dritten Regel alles dreifach.

Downloads

• REDcms_01.zip

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design
• Tag 19 – Formulare

Was soll nun genau alles änderbar sein?

Grob gesagt bestehen alle CM-Systeme aus einem einfachen Prinzip. Man kann etwas hinzufügen, ändern und löschen, so ist es auch bei meinem CMS. Wie schon am 2. Tag geschrieben, gibt es 3 wichtige Bereiche die man administrieren kann. Der erste ist die eigentliche Seite. Hier soll man neue Seiten anlegen, bestehende ändern und löschen können. Das gleiche sollte man natürlich auch für die einzelnen Boxen auf den Seiten machen können. Zum Schluss gibt es auch noch das Menü. Auch hier sollte man einen neuen Menüpunkt hinzufügen können, aber auch bestehende ändern und löschen können.

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design
• Tag 19 – Formulare

Als erstes habe ich die Funktionalität von REDcms radikal gekürzt, was nicht nur der allgemeinen Machbarkeit dienlich ist, sondern auch der Verständlichkeit. Es gibt also nicht mehr Tausende von Funktionen, sondern mir war es diesmal wichtig die Möglichkeiten sehr einfach und damit überschaubar zu halten.

Was kann also nun REDcms?

Eigentlich wollte ich ein CMS schaffen mit dem man neue Seite anlegen und diese in einer Menüstruktur sortiert kann. Weiterhin wollte ich innerhalb der einzelnen Seite Boxen hinzufügen, um den Inhalt besser zu untergliedern. Das was´s schon.

Das Ganze sollte dann über eine einfache Anmeldung administrierbar gemacht werden. Also anmelden, Dinge ändern und dann wieder abmelden. Ich glaube das dies dadurch sehr intuitiv benutzbar wird. So hoffe ich es zumindest, denn bis jetzt hat keiner mein REDcms getestet.

Wer also Lust hat in diesem System etwas herum zuspielen, der kann sich mit den folgenden Daten anmelden.

• Benutzername: admin
• Kennwort: demo

Bitte beachtet, das sich das CMS Mitternacht wieder in den Urzustand zurücksetzt. Bitte habt dafür Verständnis. Wer Anregungen zur Verbesserung bzw. zur Erweiterung hat, kann an den passenden Stellen einen Kommentar hinterlassen. Auch würde ich mich über jeden gefunden Fehler bzw. Bug freuen, oder auch nicht! Bedenkt aber, dass das System auf Rücksicht der Einfachheit keine Fehlerüberprüfung bei Eingaben macht. Dieses folgt dann bei der Umstellung auf den Produktionsstatus.

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design
• Tag 19 – Formulare

Warum habe ich ein solches System erstellt, werden sich jetzt einige Leser denken. Es gibt doch genug. Das stimmt! Mir geht es auch nicht direkt um die tatsächliche Verwendbarkeit des Systems. Mir geht es hier um die Wissensvermittlung wie solche Systeme funktionieren können.

Seit mittlerweile 11 Jahren bin ich als freier Dozent im Webbereich tätig und gebe natürlich immer wieder Programmier-Seminare. Dort kommt man leider nicht in die Tiefe ein eigenes System zu entwickeln. Und trotzdem kann man mit relativ wenigen Mitteln bzw. Kenntnissen ein solches System erstellen und genau das soll dieser Kalender verdeutlichen.

Um aber nicht völlig bei Null anzufangen, wäre es gut wenn gute HTML- und CSS-Kenntnisse vorhanden sind. Und da das System eine mySQL-Datenbank voraussetzt und in PHP geschrieben ist, sind Kenntnisse in diesem Bereich erforderlich um alles zu verstehen. Aber ich glaube auch ohne diese Kenntnisse kann man einen Großteil dieses Tutorials gut verstehen und nachvollziehen. Falls nicht, bitte ich euch in Kommentaren offene Fragen zu stellen, die ich dann beantworten kann.

Zum Schluss möchte ich meinem System noch einen Namen geben. Ich hoffe ihr findet ihn passend. Mein Projekt nennt sich „REDcms“. „RED“ kommen von RE-Design und „cms“ naja es ist ja nun mal ein CM-System.

Wer das CMS testen möchte, der findet in meinem Weblabor das entsprechende Demo. Dort werden später auch alle Releases zum Download veröffentlicht.

Ähnliche Beiträge

• Tag 24 – Abschluss
• Tag 23 – Mehrbenutzer- und Rechtesystem
• Tag 22 – Bild-Upload und RSS-Feed
• Tag 20 – CSS-Design
• Tag 19 – Formulare