Neuigkeiten:

moziloCMS verwendet Cookies. Wenn Sie auf unserer Seite weitersurfen, stimmen Sie der Cookie-Nutzung zu Datenschutzerklärung
moziloCMS Layouts
moziloCMS Plugins

Hauptmenü
-Menü

Beiträge anzeigen

Dieser Abschnitt erlaubt es dir, alle Beiträge anzusehen, die von diesem Mitglied geschrieben wurden. Beachte, dass du nur Beiträge sehen kannst, die in Teilen des Forums geschrieben wurden, auf die du aktuell Zugriff hast.

Beiträge anzeigen-Menü

Beiträge - mhsob

#31
Hallo!

Erstmal war ich überrascht, dass man auch ohne Probleme Plugins ineinander verschachteln kann - genial programmiert!

Nun bin ich aber auf ein Problem gestoßen: <script></script>-Bereiche werden ja in der Haupt-index.php erstmal ersetzt, da sie ja z.B. javascript-Code und somit {} enthalten könnten, die dann fälschlicherweise als Plugin-Aufruf interpretiert würden. Tiefer bin ich nicht eingestiegen... Dies führt aber bei der Verschachtelung zu einem Problem:
Bei dem Aufruf {plugin1|{plugin2|xyz}} könnte z.B. plugin1 ein Plugin zum Ein-/Ausblenden von Seitenteilen sein und Plugin2 eine Slimbox-Galerie, die eben auf Mausklick ein- oder ausgeblendet wird. Zum Ein-/Ausblenden ändert man mit javascript das css-"display"-Attribut und Slimbox includiert auch javascripts für seine Funktionalität. Nun passiert es, dass im erzeugten HTML-Quellcode die includes von plugin2 einwandfrei enthalten sind, das erste include von plugin1 aber durch den Inhalt des ersten Includes von plugin2 ersetzt wird, etc. Es funktioniert also in diesem Fall die Rück-Ersetzung nicht.

Vielleicht ist das Problem so speziell, dass der Rat einfach "Lass es sein..." oder der Kommentar "Was issn das für ein Unsinn?" ist.
Als Workaround hab ich jetzt vor {plugin1|{plugin2|xyz}} ein {plugin1|init} eingefügt, welches die nötigen javascripts zurückgibt, damit es im eigentlichen Plugin-Aufruf keine <script>-Bereiche mehr gibt. Nachteil ist, dass es bei der eigentlichen Plugin-Rückgabe des "äußeren" Plugins keine alternativen <script> und <noscript>-Bereiche mehr geben kann.

Vielleicht gibt's eine andere Lösung, vielleicht ist's einfach nur eine Feststellung und die Weitergabe der Erfahrung an die Mozilo-Entwickler. Das mit der Plugin-Schnittstelle ist auf alle Fälle einfach und total genial gelöst!

Grüße
Manfred
#32
access_control für Mozilo 1.12.beta3

Anbei findet Ihr eine ZIP-Datei mit der gepatchten index.php und dem access_control-Verzeichnis. Hinweise zur Verwendung und Einrichtung findet Ihr in der readme.txt im Unterverzeichnis "access_control"

ACHTUNG Änderung (sorry an diejenigen, die's wie ich bereits verwenden und jetzt ac_accesslist.txt und die Kategorie-/Seitennamen anpassen müssen):
Ich habe von server2go auf xampp umgestellt und konnte lokal erstmals mit mod_rewrite testen. Bisher waren alle geschützten Kategorien/Seiten dadurch gekennzeichnet, dass deren Namen mit * endeten. Dies war gleichzeitig die Info für den angemeldeten Besucher, dass er sich auf einer Seite befindet, die er nur dank seines Logins erreichen kann. Mit mod_rewrite (das ich auf meiner eigenen Homepage NICHT verwende) gibts bei mir Probleme, wenn die Kategorie ein * am Ende - vielleicht auch irgendwo im Namen hat. Daher habe ich vom Sternchen * auf ein (dezentes) Hochkomma ' umgestellt.

Grüße
Manfred
#33
Naja, ich will's natürlich auch. Es wird aus den genannten Gründen als Plugin nur nicht DAS, was es als Hack ist (vgl. meinen letzten Beitrag). Ich nutze das ganze nach wie vor, ein Plugin liefert wie gesagt aber leider nicht das, was ich will. Ich stell aber eine gepachte index.php für 1.12b3 ein, wenn's gewünscht ist. Vielleicht wird's ja doch Bestandteil von 1.12.beta4 oder von 1.13... Die Mozilo's könnten gerne auch Code-Teile ohne Quellenangabe verwenden oder alles in optimierter Form selbermachen.

Grüße
Manfred
#34
Hi!

Habt Ihr daran auch gearbeitet?

Grüße
Manfred
#35
Wie kann ich...? / Re: Grüne mozilo_box
18. Juni 2010, 23:09:58
Hi!

Vielleicht hilft Dir das Beispiel 3 hier weiter:
http://forum.mozilo.de/viewtopic.php?f=12&t=15

Grüße
Manfred
#36
@stylerontour:
zu 1.:
"die für den User vorgesehene Seite" gibts bei meinem Prinzip nicht. Es gibt mehrere Seiten, um welche das Menü nach erfolgreichem Login erweitert wird. Die erste aller geschützten Seiten anzuzeigen macht aber nicht unbedingt Sinn.
zu 2.:
Ich habe mir selbst ein slimbox-Galerie-Plugin programmiert, welches ich auf meiner Seite nutze. Hab auch schon stefanbe's Kalender etc. ausprobiert. Bisher hatte ich keine Probleme. Was sein kann ist, dass Du mit 1.12.beta1 Probleme hast, weil diese Version alles zwischen { } als Plugin deutet und der {LOGIN}-Tag als ungültiges Plugin gedeutet wird. Das wurde in .beta2 behoben.
zu 3.:
Ich hab bei mir einige versteckte Inhaltsseiten (3. Menüebene und so). Hatte keine Probleme damit.
zu 4.:
Schau Dir das oben verlinkte Demo an - sieht doch wie gewohnt aus, oder? Möglicherweise gibts mit einigen Layouts Probleme, ich hab bisher nur das MoziloCMS und mein eigenes Template genutzt. Dazu kann ich leider nicht mehr sagen.
Dass Du zu blöd bist, das richtig einzubauen, glaub ich nicht - es ist halt ein auf meine Anwendung optimierter "Hack" und kein universelles Plugin. Normalerweise funktioniert der auch, aber vielleicht nicht in jeder Konstellation.

So, nun zum Thema Plugin:
stefanbe (der Plugin-Gott) hat mir am 23.02.2010 eine Schnellversion in Pluginform geschickt. Prinzipiell genial - das hat mir auch die Plugin-Schnittstelle verdeutlicht.
Das Prinzip ist es, im Template eine eigene Funktion zur Ausgabe des Menüs anstelle von {MAINMENU} zu verwenden, z.B. {Login|loginmenu}. Die Felder für Benutzername/Passwort werden dann ausgegeben im Template mit {Login|loginform}. Der Inhalt jeder zu schützenden Seite wird mit {Login|...} umgeben und ... nur bei gültiger Session ausgegeben.

Es gibt für mich aber Einschränkungen im Vergleich zu meiner Version:
  • Mir war es wichtig, mozilo auf lowlevel vorzugaukeln, dass die Seiten, für welche kein gültiges Login existiert, gar nicht vorhanden sind. Der Effekt ist nicht nur, dass diese eben automatisch nicht im Menü auftauchen, sondern dass auch die Sitemap oder die Suche nix von den Seiten wissen.
  • Beim Plugin benötigt man wie bei mir eine Datei mit Benutzerdaten und eine Datei mit Zugangsberechtigungen für die verschiedenen Kategorien/Inhaltsseiten. Sind die Benutzer mal angelegt, dann wird alles aus der Datei mit den Zugangsberechtigungen verwaltet. Beim Plugin muss man zusätzlich jede zu schützende Inhaltsseite bearbeiten.
  • Bei der vorgeschlagenen Lösung werden die Logindaten erst durch die eigentliche Inhaltsseite geprüft und eine Session-Variable gesetzt. Das Menü ist zu diesem Zeitpunkt schon entsprechend dem alten Wert der Session-Variablen aufgebaut.
  • Die Ersatzfunktion für die Menüausgabe ist im Wesentlichen eine modifizierte Kopie aus der mozilo-index.php. Je nachdem, wie sich im Laufe der Zeit die Funktion ändert, sollte sie auch im Plugin angepasst werden.

stefanbe hat mir geraten (für ein Plugin hat er da wohl recht), dass man Zugriffsrechte- und Benutzerverwaltung direkt aus dem Mozilo-Adminbereich machen muss. Wow - das wäre Luxus aber auch ein bischen Arbeit, für die ich einfach momentan keine Zeit habe.
Er hat auch gemeint, dass ich in der Zugriffsrechte-Datei die Seiten so benennen soll, wie sie im Verzeichnissystem abgelegt sind, also z.B. "30_gesch%C3%BCtzte%20Kategorie%2A" statt "geschützte Kategorie". Das gefällt mir auch nicht besonders, da ich schon oft Seiten verschoben habe, und dann müsste ich auch immer die Rechte-Datei kontrollieren und anpassen. Andererseits kanns mit meiner Variante Probleme mit der Zeichenkodierung der Rechtedatei geben (UTF-8, DOS, etc.). Irgendwie hat er ja auch hier recht, aber ich wollte es eben ein wenig anders.

Beim Hack hat sich inzwischen auch was geändert. Wegen der 1.12.beta1 { }-Problematik wird das Login-Formular im Template jetzt mit #LOGIN# aufgerufen. Geschützte Kategorien oder Seiten müssen jetzt ein * am Ende haben. Alles was ein * am Ende hat, wird erstmal nicht angezeigt, ausser der angemeldete Benutzer hat entsprechende Rechte. Alles ohne * wird gar nicht überprüft. Das * zeigt angemeldeten Benutzern auch, dass sie sich auf einer "besonderen" Seite befinden, für welche sie beim nächsten Besuch wieder Logindaten brauchen. Auch Logins über den Session-Timeout hinaus sind jetzt durch Verwendung von Standard-Cookies möglich.
Ich stell mal wieder eine zip-Datei online mit dem moziloCMS 1.12.beta2 und gehackter index.php sowie access-control Verzeichnis.
Was ist zu tun, um das ganze einzurichten? Die zip-Datei entpacken und fertig. Und bei der eigenen Seite?
  • index.php aus der .zip-Datei verwenden oder selbst patchen. Eine Anleitung (auch für Folgeversionen) befindet sich in der Datei "mozilo_ac_hack.php" im Verzeichnis "access_control". Dort sind die vier Blöcke, welche in die index.php eingefügt werden müssen inkl. Beschreibung der richtigen Stelle enthalten, sowie der Hinweis, wie das ganze ins Template kommt. Wie gesagt, es muss nix "verändert", nur was einfgefügt werden.
  • Template anpassen und #LOGIN# z.B. analog zu {SEARCH} reinbringen (Search kopieren und Tag ersetzen)
  • Verzeichnis "access_control" in die oberste Verzeichnisebene kopieren und "ac_accesslist.txt" und "ac_users.txt" in "safedir" mit Texteditor im DOS-Format anpassen (nicht UTF-8 kodiert)
  • evtl. "safedir" mit .htaccess schützen

Zugangsdaten für die Demo-Installation: user1 & pass1 / user2 & pass2, die Seitenstruktur ist wie im Eingangsbeitrag.

Vielleicht bringts Euch ja was - wie gesagt, für mich isses momentan perfekt und ein wirklich GUTES Plugin ist momentan für mich deutlich zuviel Aufwand. Und was anderes braucht man nicht veröffentlichen, wenn alle bloß Ärger damit haben.
#37
Tipps und Tricks / Re: 3. Menü-Ebene
04. Juni 2010, 22:40:22
Ich habs grad ausprobiert:

Hauptseite:
[include|Menueseite]
[ueber1|Hauptseite]

[ueber3|Inhaltsverzeichnis]
[absatz|Abschnitt1]
[absatz|Abschnitt2]

[ueber3|Abschnitt1]
blablabla...

[ueber3|Abschnitt2]
blablabla...

Menueseite:
[seite=Bezeichnung1|Seite1] | [seite=Bezeichnung2|Seite2]

In dieser Konstellation sind bei Aufruf der Hauptseite die Links "Abschnitt1" und "Abschnitt2" rot durchgestrichen mit Kommentar "Absatz 'xyz' nicht vorhanden.".

Wenn ich nun zum Test in die Menueseite ein [ueber3|Abschnitt1] einfüge, dann ist der Link "Abschnitt1" nicht mehr durchgestrichen und bei Klick springt er die entsprechende Überschrift in der includierten Menueseite an.

Was tun also?
#38
Tipps und Tricks / Re: 3. Menü-Ebene
04. Juni 2010, 15:52:20
Die Idee mit der includierten versteckten Seite ist genial - ich hatte den Thread schon lange in meinen Bookmarks.

Heute wollte ich es mit der 1.12.beta2 erstmals implementieren und ich hatte folgendes Problem:

Wenn ich relativ weit oben auf der Inhaltsseite [include|menueseite] reinsetze, dann funktionieren auf der eigentlichen Seite die [absatz|...]-Links nicht mehr. Setze ich das [include|menueseite] nach die [absatz|...]-Links, dann funktionieren sie. Irgendwie scheint der die Absätze in der includierten Seite zu suchen und nicht zu finden, wenn ich die Seite vorher includiere.

Weiss jemand, wie ich das umgehen kann, ausser dass ich die Reihenfolge und damit das Seitenlayout verändere?

Grüße
Manfred
#39
Wow, IHR seid ja Freaks! Ich weiß, warum ich mich vor nem Vierteljahr für Mozilo entschieden habe!

Ist eigentlich irgendwo dokumentiert, was von betaX zu betaY geändert wird, oder ist im Zweifelsfall wieder ein rekursiver Diff nötig?

Grüße
Manfred
#40
Schon klar - bin übrigens von UltraEdit zum genialen PSPad umgestiegen, da freeware. Nur muss ich das künftig bei jedem Copy & Paste machen...
Wahrscheinlich zu speziell - wer hat normalerweise schon {}'s auf seiner Seite. War nur so ein Kommentar.
#41
Hi,

ich hab eine Weile schon die Nightly-Version vom 28.03.2010 "produktiv" genutzt. Heute hab ich mir die Arbeit gemacht, manuell auf 1.12.beta1 upzudaten.

Was mir am unangenehmsten aufgefallen ist: alles, was zwischen { und } steht, wird gleich als Plugin gedeutet und damit als fehlerhaft dargestellt. Ich habe in einigen Seiten C-Code zitiert, und da braucht man {} wie auch bei PHP zum Bilden von Blöcken. Natürlich funktionierts mit ^{ und ^}, aber das ist umständlich, wenn man mehrere zig Zeilen Code korrigieren muss. Das war bei der Nightly auch nicht so.

Ich werd wahrscheinlich auch mal ein Slimbox-Galerie-Plugin online stellen, wenn die 1.12 mal ausgegoren ist.

Grüße
Manfred
#42
Kanns mir heute selbst beantworten.

Problem ist das clear:BOTH.

Einfache Lösung: zwei Syntaxelemente definieren

nofloat_rechts = <div style="clear:right;"></div>
nofloat_links = <div style="clear:left;"></div>

Dann [bildrechts|xxx.jpg]Blablablabla blabla...[nofloat_rechts|]
#43
Hi!

Ich habe heute den Zeilenumbruch, der das Umfließen beendet, ausprobiert. Prinzipiell funktioniert er, nur hatte ich das Problem, dass der nachfolgende Text, wenn ich gleich oben auf der Seite z.B. [bildlinks|...] mit etwas umfließenden Text und dann [br|] verwendet habe,  erst unter dem Ende des Hauptmenüs auf der linken Seite fortgesetzt wurde.
Aufgetreten ist das beim Template MoziloCMS 2009.
Eigentlich sollte sich der style="clear:both;" auf die div "content" beziehen und keine Rücksicht auf div "sidebar-a" oder gar "containerboth" nehmen.
Wie kann ich das umgehen?

Grüße
Manfred
#44
Es gibt nochmal einen Nachtrag - ich hab' die Überprüfung der Zugangsberechtigung, die ja relativ oft aufgerufen wird, von einer PHP-Interpreter-For-Schleife mit einem Durchlauf pro geschützter Resource in EINEN strpos()-Aufruf pro Abfrage geändert. Da die strpos()-Funktion direkt Teil der php-Binary ist, sollte das etwas effizienter sein.
Ausserdem hab ich in der index.php noch meine Formularfelder umbenannt, um nicht mit den Mozilo-eigenen zu kollidieren (action -> ac_action).

Grüße
Manfred
#45
Hallo hausl78,

ich musste bei der Nightly-Version bzgl. URL nix weiter anpassen. Vielleicht ist es serverabhängig???
Ich hab ja in meinem letzten Beitrag in diesem Thema einen Link eingestellt - da funktionierts.

Grüße
Manfred