Tester gesucht: XH mit alternativem Seitensplitting

[frase]

Das Grundproblem ist, dass sowohl Editor als auch Pagemanager Plugins sind, und nichts voneinander wissen – klar, das kann man ihnen beibringen, aber dann bleibt dennoch eine Menge Arbeit, weil ja nicht nur ein Editor (sondern derzeit 3-4) und theoretisch auch mehrere Pagemanager angepasst werden müssen. Und wie garstig ein solches Interface sein kann, sieht man an der Editor-Filebrowser-Integration.

Sehe ich nicht so.
Weder Pagemanager noch die Editoren müssten bei zwei iFrames angepasst werden.
Es wäre, wie zwei offene Browser-Tabs oder -Fenster.
Nur das gegenseitige Überspeichern muss verhindert werden - oder eben eine Änderung verworfen.

[cmb]

Weder Pagemanager noch die Editoren müssten bei zwei iFrames angepasst werden.

Na ja, ruf doch mal den Pagemanager oder den Editor in einem IFrame auf! Da wird immer die gesamte Seite ausgeliefert, nicht nur das "Widget". Zumindest etwas Anpassung wäre nötig.

Mein Vorschlag mit den beiden iFrames hat aber auch noch einen anderen Grund: Trennung von Adminbereich und Seite.
Admin einheitlicher gestalten (-> Templates).
Und ich hatte vorgeschlage, diesen Bereich aus- und einklappbar zu machen. Vielleicht ähnlich wie bei fhs-left-right - was dort die Navigation enthält, könnte den gesamten Admin-Bereich enthalten.
Der Pagemanager könnte so "beiseite geschoben" werden.

Ah, das ist des Pudels Kern! Ich bin nicht grundsätzlich gegen einen eigenständigen Admin-Bereich (schimpft sich neudeutsch wohl Admin-Panel), aber dann sollten sich alle Plugins dort integrieren (können). Und ich denke, dass ist ein ganz eigenes Thema, das vermutlich wieder eine ganze Menge Diskussionstoff liefern wird, so dass ich das von XH-split komplett separieren würde. Ein Admin-Panel ist halt auch ohne XH-split denkbar, und umgekehrt eben auch.

[frase]

Na ja, ruf doch mal den Pagemanager oder den Editor in einem IFrame auf! Da wird immer die gesamte Seite ausgeliefert, nicht nur das "Widget". Zumindest etwas Anpassung wäre nötig.

Klar. Dazu war dieser Beitrag gedacht:
https://cmsimpleforum.com/viewtopic.php ... =70#p57105

Ah, das ist des Pudels Kern!

Wäre das schlimm?
Um nicht, wie bisher und auch bei anderen CMS immer zwischen "Verwaltung" und "Seite bearbeiten" hin und her umschalten zu müssen, könnte alles "auf einer Seite" vorhanden und notfalls "beiseite" geschoben werden.

... ist ein ganz eigenes Thema, das vermutlich wieder eine ganze Menge Diskussionstoff liefern wird, so dass ich das von XH-split komplett separieren würde

Damit wäre ich einverstanden. Es passt allerdings doch ganz gut hierher. "split" ist ein ziemlicher "Sprung" und es wird sowieso noch lange dauern, bis umgesetzt. Warum nicht gleich Optionen diskutieren?

[cmb]

Na ja, ruf doch mal den Pagemanager oder den Editor in einem IFrame auf! Da wird immer die gesamte Seite ausgeliefert, nicht nur das "Widget". Zumindest etwas Anpassung wäre nötig.

Klar. Dazu war dieser Beitrag gedacht:
https://cmsimpleforum.com/viewtopic.php ... =70#p57105

Ah, okay.

... ist ein ganz eigenes Thema, das vermutlich wieder eine ganze Menge Diskussionstoff liefern wird, so dass ich das von XH-split komplett separieren würde

Damit wäre ich einverstanden. Es passt allerdings doch ganz gut hierher. "split" ist ein ziemlicher "Sprung" und es wird sowieso noch lange dauern, bis umgesetzt. Warum nicht gleich Optionen diskutieren?

Auf der Roadmap für XH 1.7 befinden sich 124 Einträge, und XH-split ist, glaube ich, noch nicht mal dabei. Ja, also jede Menge Arbeit und eine Reihe nicht unbedeutender Änderungen stehen an. Trotzdem denke ich, ist es besser, Dinge die nicht direkt zusammenhängen lieber separat zu diskutieren. Wer will sich schon später durch ein paar hundert Posts hangeln, um einen einzigen Roadmap-Punkt umzusetzen – ich jedenfalls nicht; das hat mir bei XH 1.6 schon genügt.

[frase]

... und XH-split ist, glaube ich, noch nicht mal dabei. Ja, also jede Menge Arbeit und eine Reihe nicht unbedeutender Änderungen stehen an. Trotzdem denke ich, ist es besser, Dinge die nicht direkt zusammenhängen lieber separat zu diskutieren. Wer will sich schon später durch ein paar hundert Posts hangeln, um einen einzigen Roadmap-Punkt umzusetzen ...

Das verstehe ich.
(Ursprung waren aber Tatas Tests und Vorschläge zum Pagemanager. Das hängt zusammen. Deine Argumente oben "ziehen" aber mehr )

[olape]

Und dann frage ich mich, warum nun gleich der ganze Pagemanager beim Seitenbearbeiten verfügbar sein soll. Ging doch bisher auch ganz gut ohne, und nur weil bei XH-split die Seiteverwaltung per Editor nicht mehr (so einfach) möglich ist, muss doch nicht gleich noch Verschieben, Kopieren, Verstecken von Seiten und was weiß ich nicht alles, auch noch da sein.

Müssen muss ja auch nicht. Es sind nur Vorschläge und jeder hat halt so seine Vorstellungen, wie er es gern hätte.
Und weil nun die neu Seitenverwaltung den Schwerpunkt mehr auf den Pagemanager legt ...

Bisher habe ich den Pagemanager fast nie genutzt. Eine Zeit lang hätte ich ihn eh gar nicht nutzen können, weil er bei mir nicht funktionierte.

[Tata]

Endlich zu hause am Komputer statt am vinzigen Notebook. Ich habe es versucht.
1. In adminfuncs.php die function XH_adminMenu zu function XH_adminMenuPM kopiert/"ausgeräumt" (bestimmt ist da noch etwas unnötiges geblieben)

Code: Select all

/**** Mod by Tata ****/
function XH_adminMenuPM($plugins = array())
{
    global $sn, $edit, $s, $u, $cf, $tx, $su, $plugin_tx;
    if ($s < 0) {
        $su = $u[0];
    }
    $changeMode = $edit ? 'normal' : 'edit';
    $changeText = $edit ? $tx['editmenu']['normal'] : $tx['editmenu']['edit'];
    $menu = array(
        array(
            'label' => $changeText,
            'url' => $sn . '?' . $su . '&' . $changeMode,
        ),
       array(
            'label' => utf8_ucfirst($tx['editmenu']['pagemanager']),
            'url' => $sn . '?&normal&xhpages'
        ),
    );
    $t = "\n" . '<div id="xh_adminmenu">';
    foreach ($menu as $item) {
        $t .= XH_adminMenuItem($item);
    }
    $t .= '<div class="xh_break"></div>' . "\n" . '</div>' . "\n";
    return $t;
}
/**** Mod by Tata END ****/

2- Im template

Code: Select all

     <div class="pagemanager">
     <?php if($adm == 'true'){echo XH_adminmenuPM();}?>
     </div>

Es ist, ja, keine große Veräderung im Prinzip, aber ich finde es mehr praktisch. Das einzige, das man nie vergessen darf ist:
NEUE SEITEN NIE IM EDITOR ANLEGEN, UMNENNEN, LÖSCHEN - IMMER UND AUSSCHLIEßLICH IM PAGE MANAGER!!!
3. Soweit nur In der Sprachdatei

Code: Select all

$plugin_tx['pagemanager']['menu_main']="Immer Speichern!!!";

Was mir noch gefällt ist, dass, wasimmer im Editor gespeichert ist, hat keinen Einfluß auf die Seitenstruktur. Wasimmer im Pagemanager geändert ist, aktualisiert sich nachdem gespeichert, sobald welcheimmer Seite geöffnet ist.
4. In plugins/pagemanager/views/widget.php

Code: Select all

<h1 style="color:red">Pagemanager &ndash; <?php echo $this->lang('menu_main')?></h1>

(nur style für H1 gegeben)
Absolut super wäre, wenn bei jeder Seite im PM ein Link stehen würde, um auf die Seite direkt vom PM springen zu können (ist aber absolut nicht wichtig, die Navigation ist gleich daneben).
Schaumal hier.

[frase]

Hi Tata,
das ist durchaus eine gute individuelle Lösung.
Der Nutzen ist eher gering, da der Link "Seiten" ("Pages") sowieso auch immer oben im Admin-Menü sichtbar ist.

[Tata]

Der Nutzen ist eher gering, da der Link "Seiten" ("Pages") sowieso auch immer oben im Admin-Menü sichtbar ist.

Klar, das habe ich im Plan rauszunehmen. Nur ich wollte es nicht machen bevor ich es getestet habe. Noch habe ich kleinigkeiten in oberen Post aktualisiert. Jetzt habe ich in dem Menu oben dem Editor noch das "Bearbeiten". Wie schon oben geschrieben, nichts anderes brauche ich als Webmaster, um die Seiten zu editieren.
EDIT
Unnötige Items im "Haupt-Adminmenu" rausgenommen.
Modifizierte Datei adminfuncs.php >>>

[isometric]

Finde ich sehr gut, dass ihr das Thema angeht.

Kann man bestehende Contentdateien übernehmen, oder muss man ein neues Projekt anlegen?