CMSimple_XH - Ideen und Vorschläge

[Gert]

Hallo,

nach der Veröffentlichung von CMSimple_XH CoAuthors beta02 habe ich mal darüber nachgedacht, was davon für CMSimple_XH nützlich und sinnvoll sein könnete. Ich will das hier mal aufdröseln:

1. Pluginmanager

Der Pluginmanager ist im Core integriert und erlaubt es, Plugins zu deaktivieren, ohne dass sie aus der Installation gelöscht werden müssen. Ein uralter Wunsch der Community.

Da dazu auch der Pluginloader überarbeitet werden musste, habe ich gleich ein paar bekannte kleine Ungenauigkeiten gefixt, vielen Dank an Christoph, der mich darauf aufmerksam gemacht hat.

2. Das Admin Menü

Die logische Struktur des Admin Menüs, so wie es zur Zeit ist, gefällt mit nicht.

In der ersten Ebene gibt es Punkte:

- die eine Untermenü haben und anklickbar sind (Einstellungen)
- die eine Untermenü haben und NICHT anklickbar sind (Dateien, Plugins)

Wir haben uns daran gewöhnt, aber sauber ist das nicht.

Mit dem Pluginmanager ist nun der Menüpunkt der 1. Ebene namens "Plugins" ebenfalls direkt anklickbar, es öffnet sich der Pluginmanager.

Bei CMSimple_XH CoAuthors ist nun auch der Menüpunkt "Dateien" direkt anklickbar, er öffnet direkt das Verzeichnis "userfiles".

Das macht natürlich nur dann Sinn, wenn die Verzeichnisse "images" und "downloads" auch im Verzeichnis "userfiles" liegen. Dann verhalten sich alle Menüpunkte der 1. Ebene im Admin Menü, die ein Untermenü haben, gleich:

1. Bei Direktklick wird eine Übersichtsseite geöffnet:

- Dateien => userfiles-Ordner (mit downloads, images, media usw.)
- Einstellungen => Einstellungen-Seite
- Plugins => Pluginmanager

2. Bei hover (mouseover) gibt es "Quicklinks in die Tiefe" (im sich öffnenden Untermenü der 2. Menüebene)

Beim Plugins Menü gab es ausserdem das Problem, dass bei vielen installierten Plugins das Pluginmenü zu lang wurde. Jetzt gibt es ein "breites Pluginmenü", bei dem 3 Plugins nebeneinander im DropDown Menü (2. Ebene) Platz finden. Ab wie vielen Plugins das breite Plugins-Menü aktiv wird, ist konfigurierbar.

"Wartungsmodus"

Bei CMSimple_XH CoAuthors kann man die Inhalte der Seite für Besucher unsichtbar machen. Die Inhalte und alle Funktionen, die der Navgation dienen (toc, prev, top, next, locator) sind nur sichtbar, wenn man eingeloggt ist. Das dient der Vermeidung von Duplicate Content, und der Author kann in der h2- und h3 Ebene arbeiten, ohne von der Öffentlichkeit dabei beobachtet zu werden.

Dieses Verhalten ist abschaltbar. Die Variable ist in der Website Konfiguration angelegt, so dass man die Inhalte der Hauptinstallation, Zweitsprachen und Subsites unabhängig voneinander sichtbar oder unsichtbar machen kann.

Wenn man nun noch im Content per "else" eine Meldung ausgeben würde (z. B. "Diese Seiten werden gerade gewartet - bitte besuchen Sie uns später wieder"), hätte CMSimple_XH einen eingebauten Wartungsmodus. Auch danach wird immer mal wieder im Forum gefragt.

CoAuthors

Die 3 ersten Funktionen sollten eigentlich in CMSimple_XH zum Standard werden, ich wüsste nicht, was dagegen sprechen könnte.

Die Funktion "CoAuthors" ist eine kleine Funktion, die beim abspeichern von h1-Seiten txt Dateien erzeugt, die dann in andere html-basierte Anwendungen eingebunden werden können:

Code: Select all

        if($txc['coauthor']['create_content_textfiles'] == 'true' && $f == 'save' && stristr($c[$s],'</h1>'))
        {
            if(is_writable('./userfiles/co_author/'))
            {
                $handle=fopen('./userfiles/co_author/'.$su.'.txt', "w");
                fwrite($handle, $c[$s]);
                fclose($handle);
            }
            else
            {
                if($cf['language']['default'] == $sl)
                {
                    $e.='<ul><li>Folder <b>./userfiles/co_author/"</b> not exists or not writable</li></ul>';
                }
                else
                {
                    $e.='<ul><li>Folder <b>./' . $sl . '/userfiles/co_author/"</b> not exists or not writable</li></ul>';
                }
            }
        }

 

Und spätestens da scheiden sich die Geister: Soll so etwas Bestandteil des Core von CMSimple_XH sein?

Andererseits: Wenn ich mit grossem Brimborium, Projekt- und Demoseite und eigenem Download ein CMSimple_XH CoAuthors veröffentliche, und jemand kommt darauf, dass der eigentliche Unterschied lediglich in den obigen paar Codezeilen besteht, laufe ich Gefahr, mich lächerlich zu machen.

Gut, ich könnte es einfach in CMSimpleRealBlog einbauen und dort auf der Projektseite als zusätzliches Feature einbauen, bewerben und dokumentieren.

Trotzdem mache ich jetzt mal folgendes Angebot:

Ich bin bereit, CMSimple_XH CoAuthors als CMSimple_XH 1.5.4 zur Verfügung zu stellen. Noch ein paar Punkte aus der Roadmap realisiert, und fertig ist die neue Version.

CoAuthors ist dann gegenstandslos, und das Mini-Plugin CoAuthors_XH, mit dem die txt Dateien in eine übergeordnete CMSimple_XH Installationen eingebunden werden können, stelle ich dann als Freeware zur Verfügung,

Gert

PS: CMSimple_XH CoAuthors ist im folgenden Download im Verzeichnis "author1" enthalten.

Es ist ein überabeiteter Download (27.05.2012 - 12:00 Uhr) mit den oben beschriebenen Eigenschaften.

Download: Neuer Download weiter unten ...

[cmb]

Hallo Gert,

Pluginmanager und Adminmenü haben ja eigentlich nichts mit dem Co-Author-Konzept zu tun. Deshalb kann das ja durchaus separat überlegt werden.

Über Pluginmanager und Adminmenü gibt es ja bereits Threads (http://www.cmsimpleforum.com/viewtopic.php?f=29&t=4558 und http://www.cmsimpleforum.com/viewtopic.php?f=16&t=4666), in denen daüber diskutiert wurde.

Zum Wartungsmodus: grundsätzlich ist das eine gute Idee. Aber ich finde es besser, wenn der Wartungsmodus nicht mal das Template nutzt, damit auch dort ggf. Änderungen erst mal vom Admin in Ruhe durchgeführt und getestet werden können. Holgers Maintenance-Plugin löst das eigentlich sehr elegant, finde ich. Man könnte nun eine entsprechende Funktionalität in den Core integrieren, aber als Plugin ist's ja auch okay und tut seinen Dienst.

Zu Co-Authors: anstatt das Erzeugen der *.txt Dateien in den Core zu integrieren, könnte man diese auch vom Plugin selbst erzeugen lassen (muss dann halt in den Author-Sub-Installationen ebenfalls installiert werden). Das fände ich wesentlich sinnvoller, da die Co-Author-Funktionalität sicherlich von vielen Nutzern nicht benötigt wird, und man dann die Core-Konfiguration nicht noch umfangreicher machen muss. Bzgl. des "Zugriffschutzes" auf bestimmte Funktionen lässt sich vermutlich auch noch was per Plugin (die Plugins werden ja vor adm.php geladen) machen, ohne den Code in adm.php noch komplexer zu machen. Die entsprechenden Änderungen im Adminmenü könnten vielleicht so ebenfalls per Plugin durchgeführt werden.

Christoph

[Gert]

Hallo Christoph,

vielen Dank für Dein feedback.

Pluginmanager und Adminmenü haben ja eigentlich nichts mit dem Co-Author-Konzept zu tun. Deshalb kann das ja durchaus separat überlegt werden.

Richtig, deshalb steht CoAuthors auch nicht im Titel des Threads.

Ich habe ja viele Optionen. Je nach dem, was wir in den Core übernehmen oder nicht, kann ich CoAuthors als separate Lösung veröffentlichen, in CMSimpleRealBlog integrieren oder ganz canceln. Eigentlich ist es mir egal, ich will nur wissen, wie ich weitermache, vor allem, ob sich die weitere Entwicklung der Projektseite lohnt

Was den Wartungsmodus betrifft: Der sollte Holgers Plugin nicht tangieren. In der Normalkonfiguration mit sichtbarer Seite kann sicher das Maintenance Plugin verwedet werden, sozusagen als Komfort-Alternative für den integrierten Wartungsmodus. Es gibt ja auch ein einfaches Mailform und eine einfache Sitemap im Core, und es gibt Plugins, die beide Funktionen mit mehr Möglichkeiten und mehr Komfort bereitstellen,

Gert

[svasti]

Hallo Gert,

Apropos Pluginmanager:
Ich wünsche mir noch die Funktion: verbergen (hide), die Plugins aktiv lässt, aber diese nicht im Dropdownmenü zeigt. Damit könnte eine lange oder unübersichtliche Liste auf das Wichtige reduziert werden. Trotzdem könnten alle Plugins über den Pluginmanager erreicht werden. Weiterhin hätten deine Radiobuttons aus meiner Sicht mehr Berechtigung, weil jetzt drei Auswahlmöglichkeiten da wären statt einfach nur an und aus einzustellen (wofür aus meiner Sicht ein Knopf reicht).

Wartungsmodus:
Verstehe ich es richtig, dass man dann den Wartungsmodus per Seite einstellen kann? Wenn ich also eine bestimmte Seite bearbeite und ab und zu mal speichere und den Rest der Site weiterhin zugänglich lassen möchte, dann könnte das für manche Leute brauchbar sein... Er sollte dann aber über den Page Seitenreiter einstellbar sein, ...

Allerdings: Über den Fehler in 1.5.3 mit den Doppelten : bei "Show last edit" pro Seite hat sich niemand beschwert hat (außer mir), –– benutzt diese Funktion überhaupt jemand? Vielleicht nicht. Und jetzt noch mehr Funktionen im Core?

svasti

[Gert]

Verstehe ich es richtig, dass man dann den Wartungsmodus per Seite einstellen kann?

Nein, das gibt es doch schon, in page_params, die verschiedenen Stufen, eine Seite zu verstecken.

Der Wartungsmodus kann lediglich für jede Zweitsprache und Subsite einzeln aktiviert werden, betrifft dann alle Seiten und ist eigentlich ein Abfallprodukt von CoAuthors, wo ja die Autorenseiten (in der Autoren Installation) unsichtbar sein sollen. Also nur da, wo sie eingebunden sind, sichtbar.

Über die hide Funktion im Pluginmanager werde ich mal nachdenken.

Allerdings: Über den Fehler in 1.5.3 mit den Doppelten : bei "Show last edit" pro Seite hat sich niemand beschwert hat (außer mir)

Ein paar Punkte aus der Roadmap werde ich in CMSimple_XH CoAuthors mit umsetzen, unter anderem auch das.

–– benutzt diese Funktion überhaupt jemand? Vielleicht nicht. Und jetzt noch mehr Funktionen im Core?

Jedes CMS hat Funktionen, die nur von wenigen genutzt werden. Ich nutze auch unsere Waschmaschine nie, trotzdem ist es gut, dass wir eine haben ... hoffentlich liest hier meine Frau nicht mit, sonst ändert sich das evtl.

In diesem Thread biete ich ja lediglich an, alle meine Ergebnisse aus CoAuthors für CMSimple_XH zur Verfügung zu stellen. Beim augenblicklichen Stand (noch nicht veröffentlicht) kann man CMSimple_XH CoAuthors nach Belieben zu einem normalen CMSimple_XH konfigurieren, oder zu einer CoAuthors Installation,

Gert

[cmb]

Hallo Frank, hallo Gert,

bei "Show last edit" pro Seite hat sich niemand beschwert hat (außer mir), –– benutzt diese Funktion überhaupt jemand?

Ich denke schon, dass diese Funktion genutzt wird (hab's jedenfalls schon mal online gesehen). Aber der Fehler kann ja leicht selbst behoben werden -- was dann vermutlich die meisten einfach tun.

Ich wünsche mir noch die Funktion: verbergen (hide), die Plugins aktiv lässt, aber diese nicht im Dropdownmenü zeigt.

Wenn ich drüber nachdenke, halte ich das sogar für wichtiger als die Möglichkeit Plugins zu deaktivieren. Gerade für Endanwender ist der Zugriff auf viele Plugins gar nicht nötig, wenn sie erst mal konfiguriert wurden (Filebrowser, Pagemanager, Editoren, jQuery etc.); wenn diese Plugins dann versteckt werden, bleibt's übersichtlicher.

In diesem Thread biete ich ja lediglich an, alle meine Ergebnisse aus CoAuthors für CMSimple_XH zur Verfügung zu stellen.

Das ist ja eigentlich gut. Aber ich sehe da ein potentielles Problemchen für die Pluginautoren. Bei Subsites gab's ja nur eine kleine "Inkompatibilität" ($sl), und da hatte ich irgendwann mal vorgeschlagen, dass ein Pluginautor einfach sein Plugin als nicht Subsites konform dokumentieren kann, wenn er nicht umstellen will. Aber es gab dann doch immer mal Anfragen, dass da was nicht funktioniert, und diverse Plugins "mussten" "kompatibel" gemacht werden. Das könnte ähnlich sein, wenn die Co-Author-Funktionalität in den Core wandert, da ja ebenfalls eine Anpassung an vielen Plugins erforderlich ist, um für Co-Autoren nutzbar zu sein.

Ich denke, es ist also besser Co-Authors zumindest zunächst separat anzubieten, zumal ja Martin vor einiger Zeit schon mal Ansätze entworfen hat, wie man vielleicht die Subsites-Funktionalität alternativ implementieren könnte, so dass die Plugins für einzelne Subsites separat funktionieren. Wenn das möglich wäre, dann könnte das Co-Autor-Konzept das vielleicht nutzen.

Und eigentlich denke ich, dass es wichtigere Punkte für den Core gibt: was mir zuletzt etwas Kopfschmerzen bereitet, ist das unabhängige Speichern und Lesen von content.htm und pagedata.php. Hängt sich das Script auf, nachdem pagedata.php bereits neu geschrieben wurde, ist u.U. die Synchronisation mit content.htm futscht (das Problem wurde von Flukey besonders bzgl. des Pagemanager schon gemeldet).

Christoph

[Gert]

Hallo,

die nächste Evolutionsstufe steht zum Download bereit. Es ist alles drin, was ich oben beschrieben habe, und noch mehr.

@ Svasti: Verstecken der Plugins vor dem Admin Menü ist jetzt auch möglich, und Dein Doppelpünktchen ist auch entfernt

Der Download CMSimple_XH CoAuthors beta03 umfasst nur eine einzige Installation. CMSimple_XH CoAuthors ist als ganz normales CMSimple_XH konfiguriert, und natürlich mit einer vernünftigen userfiles Konfiguration, alles im userfiles Ordner, auch images und downloads.

Pluginmanager:

Die Datei "disabled_plugins.txt" im CMSimpleRoot muss beschreibbar gemacht werden, damit sie vom Pluginmanager geschrieben werden kann.

Wenn Ihr eine "disabled_plugins.txt" in eine Zweitsprache oder Subsite legt und beschreibbar macht, könnt Ihr die Plugins für jede Subsite oder Zweitsprache einzeln aktivieren, deaktivieren und verstecken.

CoAuthors:

Zur Konfiguration zum Einsatz als CoAuthors Installation in einem Unterverzeichnis des CMSimple Root sind folgende Schritte erforderlich:

1. Beim TinyMCE eine der coauthors inits einstellen, damit absolute Links aus dem Domain Root heraus erzeugt werden.

2. In der Website Konfiguration ganz oben unter Coauthor "Create_content_textfiles:" auf "true" setzen, damit die txt Dateien erzeugt werden.

3. Das Verzeichnis ./userfiles/co_author/ beschreibbar machen, damit die txt Dateien erzeugt werden können.

So, wie es ausgeliefert wird, kann es als ganz normales CMSimple_XH verwendet werden.

Download:

CMSimpleCoAuthors beta03: <edit> neues Projekt mit integriertem Pluginmanager: http://www.ge-webdesign.de/co_authors/ </edit>

Gert

[Gert]

Hallo,

21:00 Uhr neuer Download, gleicher Link, mit erweiterten Sprachdateien: Hilfetexte für die Konfiguration und Sprachvariable für den "Wartungsmodus", hatte ich irgendwie vergessen.

Und die Newsboxen waren noch sichtbar, auch im Wartungsmodus, ist jetzt auch gefixt.

Vielleicht findet Ihr ja noch ein paar Kleinigkeiten ...

Gert

[cmb]

Hallo Gert,

Wartungsmodus/unsichtbarer Autoren-Content: warum lässt Du ein fast leeres Template ausgegeben? Das sieht m.E. bescheiden aus, ist mehr Aufwand als nötig (immerhin wird in fast 10 Funktionen eine zusätzliche Abfrage eingebaut), und man vergißt auch leicht mal eine Funktion (vielleicht wird in der Zukunft noch die ein oder andere ergänzt). Warum nicht einfach im Plugin im globalen Scope:

Code: Select all


if ($txc['coauthor']['content_visible'] != 'true' && !$adm && $f != 'login') {
    header('HTTP/1.0 503 Service Unavailable');
    die('Currently not available');
}
 

Das $txc könnte so zu einem $plugin_cf['co_authors'] werden, der String, der von die() ausgegeben wird, kann leicht internationalisiert werden. Für Co-Autorenseiten bietet sich vermutlich eher ein "403 Forbidden" an; das könnte man ja konfigurierbar machen. Das sieht zwar auch nicht schön aus, ist aber sehr zweckmäßig, zumal dem User-Agent (Search-Bot!) ein sinnvoller HTTP-Statuscode geliefert wird.

allow_config: ist das wirklich nötig/sinnvoll. Reicht nicht schon full_settings_menu, um unerfahrenen Anwendern die Konfiguration zu "verbieten"? Erfahrene Anwender können dort ja gerne reinschauen, wenn sie wollen, und bei Bedarf auch was ändern.

Das sind natürlich nur Vorschläge, denn Co-Authors ist Deine Sache. Aber

So, wie es ausgeliefert wird, kann es als ganz normales CMSimple_XH verwendet werden.

Das klingt fast so, als ob Co-Authors nun doch in den CMSimple_XH Core integriert werden könnte. Das liegt natürlich im Ermessen des Teams, aber ich würde mir wünschen, dass es eine eigenständige Lösung bleibt, da ich finde, dass es (überspitzt ausgedrückt) "nichts halbes und nichts ganzes" ist. Eben so ein bisschen Multiuser, aber doch nicht wirklich. Es gibt sicherlich einige, die das Feature gut nutzen können, ähnlich wie die "Subsites", die ich selbst im Einsatz habe, um meine Templates ggf. mit individuellem Content zu präsentieren. auch wenn die "Subsites" leider keine richtige Mehrmandantenlösung sind.

Nun sehe ich ein, dass eine eigenständige Co-Authors-Solution bzgl. der Updates aufwendig werden könnte. Warum also nicht als eigentständiges Plugin, ohne weitere Anpassungen am Core?

• Schreiben der *.txt-Dateien: ist im Plugin möglich (if ($adm && $f=='save') {...})
• unsichtbare Seiten, falls nicht eingeloggt: ist wie oben beschrieben im Plugin machbar
• full_settings_menu: da würde es wohl genügen im Core einen Hook (auch für andere Plugins) zu ergänzen:
  

  Code: Select all

  if (function_exists('custom_admin_menu')) {
    return custom_admin_menu();
} else {
    return admin_menu();
}
 

  
  und dann custom_admin_menu() entsprechend zu definieren. Das kann ja ruhig eine leicht modifizierte Kopie von admin_menu() sein; bei Updates müsste das ggf. überarbeitet werden, aber es ist nur 1 Funktion.
• allow_config: darauf kann man, denke ich, wie gesagt, verzichten

Christoph

PS: bzgl. des Schreibens der *.txt-Dateien muss ich mich korrigieren: es muss nicht bei $f == 'save', sondern bei $function == 'save' erfolgen, also etwa:

Code: Select all


if ($adm && $function == 'save') {
    $fn = "./userfiles/co_author/$su.txt";
    if (($fh = fopen($fn, 'wb')) === FALSE
            || fwrite($fh, stsl($text)) === FALSE) {
        e('cntsave', 'file', $fn);
    }
    if ($fh !== FALSE) {fclose($fh);}
}
 

Allerdings bin ich mir nicht sicher, ob das URL-Encoding immer gültige Dateinamen ergibt. Auf jeden Fall gibt es aber (auch bei Deiner jetzigen Variante) Unstimmigkeiten, wenn per Editor Seiten neu angelegt, gelöscht oder umbenannt werden. Auch werden die Seiten-Verwaltungs-Plugins (Pagemanager, Menumanager) nicht berücksichtigt.

[Gert]

Reicht nicht schon full_settings_menu, um unerfahrenen Anwendern die Konfiguration zu "verbieten"?

Wenn ich das so gemacht hätte, hätte mir garantiert irgendein Naseweis um die Ohren gehauen: "Ätsch - per Adresszeile kommt der Autor ja doch ran". Es ist in Stufen konfigurierbar - und gut so.

Erfahrene Anwender können dort ja gerne reinschauen, wenn sie wollen, und bei Bedarf auch was ändern.

Das soll der Admin entscheiden können. Wenn der Zugang zur Konfiguration per allow_config deaktiviert ist, kann er nur per ftp wieder freigegeben werden, und so soll es auch sein. Das hat noch nicht mal was mit CoAuthors zu tun, sondern ist ganz einfach eine weitere Möglichkeit für den Administrator, wenn er für andere eine Seite oder eine Subsite einrichtet.

Für Co-Autorenseiten bietet sich vermutlich eher ein "403 Forbidden" an

Mit noindex, nofollow kann man die Suchmaschinen fernhalten, mit unterdrückten Inhalten gibt man denen sowieso kein Futter, und man kann eine schöne Maintenance Meldung ausgeben, wenn man diese Funktion als Maintenance Mode nutzt.

Nun sehe ich ein, dass eine eigenständige Co-Authors-Solution bzgl. der Updates aufwendig werden könnte.

Ja, voraussichtlich so aufwändig, dass ich dann für CMSimple_XH keine Zeit mehr haben werde,

Gert