Beiträge

Mir sind die neuen Möglichkeiten noch nicht ganz klar, aber damit hab ich auf alle Fälle auf einmal viele Baustellen - ich muss den (evtl. mozilo-versionsabhängigen) Hauptmenü-Code  mit copy&paste übernehmen und anpassen, muss den Content checken und evtl. nicht anzeigen, zusätzlich im Content eine Sitemap oder ein Suchergebnis erkennen und dann im generierten HTML rumwerkeln. Seh ich das falsch? Das kann ich mir durch einen kleinen Patch alles schenken! Gut, es ist eigentlich kein PLUGin sondern eher ein WELDin oder GLUEin   .
Inwieweit eine plugintechnisch perfekte Version kompatibel zu Folgeversionen (gar mozilo 2.0) wäre, weiss ich auch nicht - einige Arbeit wär's auf alle Fälle schon.

Bzgl. neuer Möglichkeiten werde ich nochmal im anderen Thread nachfragen.

Grüße
Manfred

[nicht nur]

Hi Stefan,

d.h. ich kann {MAINMENU} ersetzen, wie ich das bisher technisch gleichwertig durch eine Alternativfunktion wie z.B. {access_control|MY_MAINMENU} im Template gekonnt hätte?

Es geht aber nicht nur um die Begrenzung des Menüumfangs (auch bei Suche oder Sitemap), sondern darum, dass die Suche (nicht nur im Menü sondern auch in der Anzeige der Suchergebnisse im Inhaltsseitenbereich) keine Ergebnisse von Seiten liefert, die nicht betrachtet werden dürfen. Ausserdem soll mozilo das Standardverhalten für eine nicht vorhandene Inhaltsseite zeigen, wenn jemand die URL einer Seite kennt und aufruft, die ihn nichts angeht. Wie gesagt, es geht nicht nur um's Menü.

Langfristig werd' ich mir wohl eine andere Lösung einfallen lassen müssen oder Abstriche in kauf nehmen müssen oder auf der letzten mozilo Version stehenbleiben müssen, mit der's funktioniert. Oder es ist natürlich irgendwann mal ein Standardmodul.

In der jetzigen Plugin-Version steckt unerwartet viel Arbeit und ich bin momentan (vielleicht noch fälschlicherweise) der Meinung, dass die gewünchste Funktionalität ohne Patch nicht 100%ig erreicht werden kann.
Immerhin lässt sich inzwischen alles via Backend installieren, konfigurieren und wieder deinstallieren...

Prinzipiell wäre es aber interessant, wenn Du in dem von Dir verlinkten Post ausführlicher über die neuen Möglichkeiten berichten würdest.

Grüße
Manfred

[hier]

Jetzt geht's hier weiter...

[rolinux]

Hallo allerseits,

jetzt hat's bis zur Version 2.0 doch nicht besonders lange gedauert. Es wurde munter herumoptimiert und auch gleich noch ein kleiner Feature-Wunsch von rolinux eingebaut (der "alte" Thread von der Nicht-Plugin-Ur-Version bis zum Plugin v1.0 ist hier zu finden).
Und hier geht's direkt zur Plugin-Downloadseite.

Neue Funktionen gegenüber v1.0:

• In der Zugriffsliste ist jetzt der Benutzer "any_login" erlaubt (Kategorie/Seite sichtbar für jeden registrierten Benutzer)
• Es wurden zwei Mechanismen zur Verwendung des aktuell angemeldeten Benutzers z.B. durch andere Plugins implementiert
• Passwörter können jetzt auch durch die Benutzer selbst geändert werden, wenn der Admin dies für den jeweiligen Benutzer zulässt
• Es wurde ein kleines Formular für die MD5-Verschlüsselung von Passwörtern hinzugefügt, somit muss dafür keine externe Seite bemüht werden

Im Detail wurden folgende Änderungen durchgeführt (Auszug aus doku.html):

Code Auswählen Erweitern

Version 2.0
- Bugfix: vergessenes {access_control|doku} aus Plugin-Dropdown-Liste bei Inhaltsseitenbearbeitung
  gelöscht
- Performance verbessert
  Die accesslist wird für aktuellen Benutzer am Anfang gleich auf die für ihn freigeschalteten
  Kategorien/Inhaltsseiten gekürzt -> 1x etwas mehr Verarbeitungsaufwand, bei den wiederholten
  Folgeaufrufen ist dann deutlich weniger Stringsuche nötig
- Wird für eine Seite der Benutzer "any_login" angegeben, so muss fuer die Anzeige der Seite
  einfach nur irgendein registrierter Benutzer angemeldet sein.
- Plugin-Funktion zur Rückgabe des verifizierten aktuell angemeldeten Benutzers implementiert
  Der Name kann auf einer Seite ausgegeben werden oder über als Teil des Aufrufs an andere Plugins
  übergeben werden.
- Implementierung einer sehr einfachen "API", welche die Verwendung des aktuell angemeldeten
  Benutzers in anderen Plugins ermöglicht.
- Erweiterung der Befehlssyntax um ein Formular zur Änderung des Benutzerpassworts im Frontend
  (vom Admin für jeden Benutzer extra freischaltbar)
- Erweiterung der Befehlssyntax um ein kleines Formular zur MD5-Codierung von Passwörtern
- Erweiterung der Doku im Backend und Aufnahme der Dokus für die Benutzer- und Zugriffsliste
  in den Plugin-Beschreibungstext (kann in Version 1.1 aus den eigentlichen Eingabefeldern gelöscht
  werden)
- Im Vergleich zu v1.0 muss nicht mehr für einen Benutzer eine Kategorie alleine extra freigegeben
  werden, wenn er für die betreffende Kategorie inkl. einer Unterseite freigeschaltet ist.Das Update v1.0 auf v2.0 ist sehr unspektakulär:

• Alle "alten" Dateien mit denen aus dem neuen Archiv überschreiben, die Datei plugin.conf belassen
• Optional aufräumen: Im Backend können aus Benutzer- und Zugriffsliste die Kommentarzeilen größtenteils entfernt werden, da die Doku jetzt in der eigentlichen Beschreibung im Backend enthalten ist

Wenn Ihr an weiteren Neuigkeiten bzgl. access_control interessiert seid, dann beobachtet einfach diesen Thread - ich werde mich voraussichtlich auch bei Folgeversionen hier melden...

Viel Spaß mit dem Plugin!
Manfred

[index.php]

Wow, sind DIE bei lima-city restritkiv:

Erlaubte und verbotene Inhalte
[...]
Auf den Webspace-Servern sind folgende Dateiformate verboten:

*.bmp, *.avi, *.midi, *.mpeg, *.mpg, *.mp3, *.wav, *.wmv, *.wma, *.mov, *.rar, *.zip, *.ace, *.tar, *.exe, *.lzh, *.tar.gz, *.tar.bz2, *.gz, *.bz2, *.jar, *.psd, *.cab, *.mid, *.zi0, *.torrent, *.dem, *.w3g, *.w3x, *.wmf, *.dll, *.ogg, *.bin, *.psp, *.tgz, *.ram, *.rmvb, *.7z

Ebenso sind auf dem Webspace alle nicht aufgeführten Archivformate sowie sämtliche Methoden, um Dateien zu tarnen, verschlüsseln oder ähnliche Aktionen, um den Dateiinhalt oder das Dateiformat zu verschleiern ohne vorherige Zustimmung eines Knights oder eines Administrators verboten!

Des Weiteren sind auf dem Webspace alle multimedialen Dateitypen (Dateien, welche Bild, Ton, Ton + Bild = Video beinhalten) nicht erlaubt, Ausnahmen sind natürlich *.png, *.gif, *.jpg, *.jpeg, *.ico, *.swf, *.pdf, *.doc, *.xls, *.ppt, *.odt, *.ods und *.odp Dateien.

Jedoch gibt es eine Ausnahme, was den Upload von *.zip Dateien betrifft. *.zip Dateien können temporär hochgeladen werden, wenn diese nach dem Upload über den Filemanager mit der entsprechenden Option ("Nach dem Hochladen entpacken") entpackt werden und sofern in dem Archiv nur erlaubte Dateien vorhanden sind. Dies dient dazu, um Traffic zu vermeiden, andererseits ist es somit möglich, mehrere Dateien auf einmal hochzuladen.

Bei Verstößen kann es zu Strafen bis zur kompletten Löschung des Benutzers und des Webspaces kommen. Verlinkungen zu externen Downloads sind erlaubt, insofern diese nicht gegen deutsches Recht oder die Regelungen des jeweiligen Anbieters verstoßen.

Von .lnk steht da explizit nix, aber wahrscheinlich greift da die "Ebenso..."-Sektion. Ich bin jetzt bei dritten Hoster und hatte diese Einschränkung noch nicht.

Ein Workaround (falls Du das wirklich tun willst; ungetestet und inkompatibel zum Standard...):
Such mal in der index.php und adminindex.php nach

Code Auswählen Erweitern

$EXT_LINK = ".lnk"; und ersetz' es z.B. mal mit ".lin" oder so (irgendwas mit 3 Buchstaben). Benenn' die zugehörigen Dateien im kategorien-Verzeichnis und den Unterverzeichnissen um und es sollte funktionieren.

Grüße
Manfred

Auch ich muss da meinen Senf dazugeben:
Mozilo ist gut genauso wie es ist. Ein Wysiwyg-Editor überlädt das ganze einfach, da könnte man dann auch noch über eine Datenbank diskutieren. Dass es sowas nicht gibt, macht gerade den Charme von mozilo aus. Klar beinhaltet "einfach" eigentlich auch Wysiwyg, aber das muss nicht unbedingt sein.

Es ist doch schon angenehm, dass man sich nicht ständig um HTML-Start und -Endtags kümmern muss, dass automatisch Referenzen zu Überschriften erzeugt werden, die Syntax ziemlich einfach und beliebig erweiterbar ist, ...

Vielleicht macht ja wirklich jemand ein Plugin, welches dann zusätzlich zur Standard-Bearbeitung im Backend einen - in eine spezielle Inhaltsseite eingebundenen Editor enthält, der die mozilo-Syntax anders darstellt.

Grüße
Manfred

"max_file_uploads" bezieht sich auf die Anzahl der Datei-Auswahl-Elemente auf einer Seite. Im "Dateien"-Reiter ist ja für jede Kategorie ein Feld für den Dateinamen enthalten, auch wenn die meisten ausgeblendet sind. Und bei über 20 dieser Eingabefelder wird's bei Default-Einstellungen kritisch. Liegt das ganze im Netz und nicht "nur" auf dem lokalen xampp, dann kann's evtl. gar nicht möglich sein, den Parameter ändern zu lassen.

Grüße
Manfred

In 1.12.betaX haben sich einige relevante Dinge geändert (u.a. auch die Dateicodierung der Datenbasis, die Plugin-Schnittstelle ist hinzugekommen,...). Erstens hast Du nur 'ne Menge Konvertierungsaufwand und zweitens verschenkst Du die genialen Plugins (aktuell 34 an der Zahl). Und .beta3 funktioniert - wie auch die Beta-Vorversionen - wirklich sehr zuverlässig.

Mir gings übrigens auch so - ich finde Plain Text für überschaubare Auftritte viiiieeel cooler als mySQL. Und wenn Du erstmal Dein eigenes Plugin programmierst, welches genau DAS macht, was Dir noch gefehlt hat, wird's Dich noch mehr begeistern.

Grüße
Manfred

Hi Rolf!

Danke für die - sogar positive - Feedback-Premiere! Auch für das positive Feedback bzgl. PHP4.

Zur Anwendungsmöglichkeit:
Ich nutze das ganze u.a. zur Freischaltung meines internen Bereichs (da hab ich u.a. das Login-Protokoll oder einen Redirect auf das Admin-Login) bzw. zur Freischaltung einer ständig aktualisierten Kategorie mit Bildern von meiner kleinen Tochter - die will ich nur einem ausgewählten Besucherkreis zugänglich machen. Hier sind übrigens auch die Bilder ganz interessant geschützt (damit hängt die Option "Benutzerinfos für andere Plugins speichern" zusammen) - vielleicht komm ich mal dazu, mein Galerie_Slimbox Plugin zu überarbeiten und als Alternative zum Slimbox Plugin einzustellen.

Zum Bug:
Stimmt - danke für den Hinweis. Das war mal drin, die Doku mit Installationshinweisen darf aber nicht erfordern, dass das Plugin bereits läuft, das hab ich dann in der Liste vergessen - ist aber nicht dramatisch. Ich werde es bei der nächsten Version rausmachen.

Zum Feature-Request:
Das "no_login" macht mit dem Prinzip des Plugins keinen Sinn, da sonst jede Kategorie und jede Inhaltsseite ein Hochkomma am Ende des Namens haben müsste. "no_login" ist einfach die Standard-Struktur, die jeder Besucher sieht, der nicht angemeldet ist - angemeldete Benutzer sehen all diese Seiten + ausgewählte Zusatzseiten.
Das mit dem "any_login" nehm ich auf alle Fälle mal als optional in die TODO-Liste auf.

Grüße
Manfred

So, jetzt isses endlich soweit: ich hab soeben das access_control (Version 1.0) ins Pluginarchiv eingestellt...

Hi!

Ich hab' immer noch keine Aktivierungsmail erhalten, gestern eine PN an oliverlorenz geschickt...

Grüße
Manfred

Wenn die Antwortmail automatisch erzeugt und gesendet wird, dann dauert's bei mir auch schon fast zu lange (fast 24h). Bei manueller Zusendung des Aktivierungslinks warte ich noch weiter ab...

[VORAB]

Hi stylerontour,

was für ein Timing - ich hoffe Du bist mir nicht böse, dass ich inzwischen auf absoluter Sparflamme an einer Plugin-Variante gearbeitet habe. Ich bin aktuell noch am Testen, wollte es aber innerhalb einer oder zwei Wochen online stellen (der Löwenanteil ist echt Mitte bis Ende der vergangenen Woche entstanden). Wie gesagt, ich leider unter akutem Zeitmangel dank arbeitsaufwändigem Job und kleinem Töchterchen.
Vorab: es war noch mehr Arbeit, als ich gedacht habe, da ja alles besser werden musste...
Neu und elegant: die index.php wird bei Aktivierung des Plugins automatisch um wenige Zeilen erweitert, bei Deaktivierung wird alles wieder rausgelöscht. Im Wesentlichen erfolgt der Eingriff nur noch an zwei Stellen und es werden 1x nur eine und 1x nur zwei Zeilen eingefügt. Den Patch erfordert der tiefe Eingriff, auf den ich bei der Plugin-Variante nicht verzichten wollte. Das ganze ist jetzt vollständig übers Backend administrierbar. Zudem ist das ganze noch ein wenig manipulationssicherer geworden (z.B. wenn jemand manuell die Cookies ändert, die ja optional verwendet werden - hier kann jetzt nicht mehr einfach ein anderer Benutzername eingegeben werden, um die Rechte dieses Benutzers zu erhalten). Ausserdem ist noch ein Seiteninhaltsfilter dazugekommen. Es gibt jetzt auch eine eigene Plugin-Funktion für's Template.

Ich häng' mal eine VORAB-Version (inkl. Mozilo 1.12.b3) an diesen Post - die Emailfunktion bei Login nutze ich in meiner nicht-Plugin-Variante schon, für's Plugin hab ichs bislang aber noch nicht getestet. Wie gesagt - VORAB-Version - ein bis zwei Wochen brauch ich noch.
Zur Verwendung des Plugins in einer eigenen Seite muss man lediglich das access_control-Verzeichnis in plugins übernehmen, für's erste Austesten ist Mozilo im Zip-Archiv komplett lauffähig - hoffe ich.

Nimm am besten eine frisch runtergeladene Haupt-index.php und füge {access_control|loginform} ins Template ein. Die Doku findest Du in doku.html im Plugin-Verzeichnis, die möglichen Befehle im Plugin-Backend.

Grüße
Manfred

Wow - cool!
Ist mir nicht wirklich richtig abgegangen (hatte schon ein [code|]-Element definiert), find's aber super toll auf meiner Homepage!
Falls es jemanden interessiert: hier ist übrigens mein code-Element und das "neue" code_high-Element (mir war die Standard-Schrift von HighLighter zu gross und der Codebereich war nicht farblich hinterlegt):

Code Auswählen Erweitern

code = <div class="code">{VALUE}</div>
code_high = [code|{HighLighter|{DESCRIPTION}|{VALUE}}]Aufruf z.B. [code_high=c|irgendein C-Code...].

So sieht div.code in meiner style.css aus:

Code Auswählen Erweitern

div.code {
padding:5px;
margin:5px;
font-family:monospace;
background-color:#F0F0F0;
border:1px dotted #B0B0B0;
font-size:0.85em;
line-height: 1.2;
}

Hallo an die Mozilo-Entwickler,

es handelt sich hierbei nicht um einen Feature-Wunsch, sondern der Wunsch geht in Richtung Doku.

Die Haupt-index.php lädt sich die template.html aus dem Layout rein und ersetzt in dieser gewisse Platzhalter wie Menü oder Suchfeld. Dann gibt es die Textdateien mit dem Seiteninhalt, die in geeigneter Weise in HTML-Code umgewandelt werden und dann im content-Bereich der template.html landen. Schließlich kommen noch benutzerdefinierte Syntaxelemente und Plugins mit rein. Wer wird vor wem abgearbeitet, können Syntaxelemente im Plugin-Argument verwendet werden oder umgekehrt etc.?
Natürlich kriegt man alles durch Probieren raus, aber vielleicht wär's für den ein oder anderen ganz hilfreich, wenn's da eine einfache Info gäbe.

Vielleicht gibts ja sowas schon?

Grüße
Manfred