Beitrag während der Bearbeitung Sperren

[abraxas]

Hallo zusammen,

gibt es eine Möglichkeit Beiträge die gerade von einem Benutzer bearbeitet werden für andere zu sperren?
Bei unserer Vereins-Seite ist es leider schon vorgekommen das zwei Leute gleichzeitig einen
Beitrag bearbeitet haben, derjenige der zuerst gespeichert hat war dann der Verlierer, weil der Beitrag anschließen vom 2. Benutzer überschrieben wurde.

Gruß Markus

[Luisehahne]

Nein leider nicht. Es ist aber für eine zukünfige Version angedacht zumindest einen Hinweis zu zeigen ,dass die Seite gerade bearbeitet wird.

Dietmar

[abraxas]

Danke für die schnelle Antwort,
dann werde ich mal sehn ob ich da übergangsweise irgend etwas entwickeln kann,
vielleicht eine Anzeige wer was gerade bearbeitet oder so.

Gruß Markus

[Hans>NULL]

Falls eine Eingangsseite nicht schon für andere Zwecke belegt ist, kann man diese dafür verwenden.
Klappt natürlich nicht bei Direktlinks. = Richtige Antwort, aber nicht auf die Frage, welche gestellt wurde (Verwechslung, Dank an "Stefek").
Gruß, Hans>NUL

[Stefek]

Falls eine Eingangsseite nicht schon für andere Zwecke belegt ist, kann man diese dafür verwenden.
Klappt natürlich nicht bei Direktlinks.
Gruß, Hans>NUL

Hast Du überhaupt gelesen und verstanden, worum es geht?

Wenn ja, dann erkläre doch mal bitte, wie du die Eingangsseite für diesen Zweck verwenden würdest.

Stefek

[Hans>NULL]

Du hast "Recht". Ich hatte hier eine ähnliche Frage aus einem anderen Forum vorliegen und verwechselt.
Das paßt ja nun überhaupt nicht.
Danke.
Gruß, Hans>NUL

[Stefek]

Kein Problem -
hätte ja sein können, dass Du ein neues geniales Tool in die Datei eingebunden hast 

Zum Glück hat sich noch nie einer meiner Kunen beschwert darüber.
Aber ich sehe, dass eine konkrete Lösung dafür ein gutes Feature für eine 3.0 WB Version wäre.
Doch es wäre gut, wenn dies über Optionen einstellbar wäre, und es nicht von vornherein diesen "in_bearbeitung_chec k" ausführen würde, sondern nur, wenn es für eine Installation explizit eingestellt (ausgewählt) wurde.

Gruß,
Stefek

[Hans>NULL]

Übrigens: Ich meine wirklich DANKE, weil im anderen Forum (Firma/Intranet) stand natürlich jetzt komplett Unverständliches. Deine Aufmerksamkeit hat mich vor Peinlichkeiten bewahrt.
Gruß, Hans>NUL

[Stefek]

Deine Aufmerksamkeit hat mich vor Peinlichkeiten bewahrt.

So, so... vielleicht solltest Du öfter 'auf mich höhren' 

[Luisehahne]

Das Problem einer Sperre ist, was ist wenn der Browser abstürzt bevor die Sperre wieder freigegeben wird. Dann bleibt die Sperre bestehen. Ist auch ein Problem bei der Anzeige, bevor die Bearbeitung abgeschlossen ist. Hmm, mal schauen, alles nicht so einfach

Dietmar

[Stefek]

Weil ich keine Ahnung habe, gleich eine Frage:
was wenn man es beim Speichern macht? Ich bearbeite eine Datei, speichere sie, und wenn sie zwischenzeitlich geändert wurde, bekomme ich einen Hinweis zu Gesicht, dass die Seite soeben geändert wurden.
Meine Äbderungen bleiben ungespeichert vorhanden, ich habe Zeit, mir im Frontend die gemachten Änderungen anzuschauen.

DasProblem ist nur, dass es generell an einer Versionsbearbeitung mangelt.
Thorn hat da etwas gemacht, recht rudimentär - wahrscheinlich, weil das System im Moment nicht mehr Spielraum bietet.

Gruß,
Stefek

[Hans>NULL]

Meinen Anwendern würde als vorläufige Lösung genügen, wenn jemand aus einer bestimmten Gruppe aktiv ist, sich andere aus dieser Gruppe nicht anmelden können, da der Kreis der Redakteure klein ist und jemand manchmal nur ein Zimmer weiter sitzt. Die Pausen stören nicht, da die Bearbeitung meist per copy&paste geschieht. Nur so als Anregung...
Gruß, Hans>NUL

[doc]

Hi,

bevor man nun wieder am WB 2.x Core frickelt, sollte man das aus anderen CMS Systemen bekannte Staging neben einer runderneuerten Rechteverwaltung wohl lieber für WB 3 vorsehen

Ein brauchbares Staging (Versionierung und Speichern von Seitenansichten als Entwurf) findet sich z.B. in Silverstripe.

Doc

[FrankH]

Ein brauchbares Staging (Versionierung und Speichern von Seitenansichten als Entwurf) findet sich z.B. in Silverstripe.

Oh ich glaub, dort kann man sich nicht nur *eine* Scheibe abschneiden...

[abraxas]

Also ich kenne sowas aus Joomla,
wenn dort jemand eine Seite bearbeitet bekommen andere beim Öffnen dr Seite
dies angezeigt. Für den Fall das eine Seite nicht korrekt geschlossen wird kann der Administrator diese
manuell frei zu schalten.
Ich denke das sollte mit einer zusätzlichen Bool-Variable zu machen sein oder?
Also im sinne von wenn bearbeitung==true -> Seite wird gerade bearbeitet.

Gruß Markus

[Waldschwein]

Ein brauchbares Staging (Versionierung und Speichern von Seitenansichten als Entwurf) findet sich z.B. in Silverstripe.

Oh ich glaub, dort kann man sich nicht nur *eine* Scheibe abschneiden...

*hust* Aber bitte nicht zu viel, das wäre dann der berühmte Schuss ins Knie.  *hust*

[FrankH]

*hust* Aber bitte nicht zu viel, das wäre dann der berühmte Schuss ins Knie.  *hust*

Das verstehe ich jetzt nicht, wie meinst du das?

[Waldschwein]

Das verstehe ich jetzt nicht, wie meinst du das?

Ich meine, dass vieles von diesem CMS definitiv nicht "WebsiteBaker tauglich" ist. Man kann den Entwicklern nicht oft genug eintrichern: Benutzt und beliebt ist - wie man in vielen Foren im Netz lesen kann - WebsiteBaker eigentlich nur, weil es "das einfachste" CMS ist. Wenn man jetzt so einen Web2.0 Verschnitt wie es tausende andere gibt hernimmt als Vorbild verspielt man sich die komplette Kundschaft.  

[FrankH]

Benutzt und beliebt ist - wie man in vielen Foren im Netz lesen kann - WebsiteBaker eigentlich nur, weil es "das einfachste" CMS ist.

Ja das habe ich auch geglaubt - bis zu dem Tag, an dem ich Silverstripe installiert habe. Das ist einfacher als bei WB.

[DarkViper]

@Luisehahne & Doc
Ein kleiner Denkanstoß...  mit dem Gedanken, das WB so einfach wie möglich bleiben soll..

Eine wirksame Bearbeitungssperre könnte relativ einfach realisiert werden.

Sowie ein Benutzer eine Seite zur Bearbeitung öffnet, bekommt er für diese Seite eine Lease mit einstellbarer Verfallszeit(Settings) zugeteilt. Solange diese dann existiert, kann kein anderer die Seite zur Bearbeitung öffnen. mit jedem Speichern wird die Verfallszeit wieder auf max gesetzt. Ruft der Benutzer eine beliebige andere Seite des Backends auf, werden seine sämtlichen noch nicht abgelaufenen Leases gelöscht und die Seiten sind wieder für die 'Allgemeinheit' frei. Im Falle eines Rechnerabsturzes etc. dauert es eben max. die Verfallszeit... und die Leases löschen sich selbst.
Inhalt der lease:  user_id, page_id, timeout-timestamp
Diese Methode erfordert keinerlei aufwändige Versionshistory oder ähnliches und bringt auch im Laufzeitverhalten nur wenig Nachteile.
Sollte jemand eine Seite in Bearbeitung haben, zwischendurch dann in die Kaffeepause gehen und sich dann wundern, dass seine Schreibberechtigung weg ist (Lease abgelaufen) dann ist er eben selber schuld.

häppy nachdenkeling..... 

Werner

[Luisehahne]

Hötz sich einfach an, aber wie willst das umsetzen. Der Server tut nichts von alleine. Und wenn der Browser abstürzt, was dann?
Wie willst du das umsetzen? Evtl indem der nächste der versucht den Content zu editieren, die Zeitschleife wieder ans Laufen bringt?

Dietmar

[DarkViper]

hört sich nicht nur einfach an, ist es auch. Ich habe das selbe System schon in mehreren meiner Anwendungen erfolgreich eingesetzt. Eine einzige Klasse mit nur 3 Funktionen genügt.

Tabelle:
  page_id (unique key)
  user_id
  timeout

abstrahierter Code:

Code:

class Lease {

  function create_lease( $user_id, $page_id ){
    lösche alle Leases wo timeout < now
    lege neuen datensatz an mit $page_id, $user_id, $timeout( now + Verfallszeit)
    return:
       true wenn Datensatz angelegt werden konnte
       false wenn $page_id bereits existierte (wird durch den unique-key ausgelöst)
  }

  function refresh_lease( $user_id, $page_id ) {
    UPDATE tabelle SET $timeout( now + Verfallszeit) WHERE user_id = $user_id AND page_id = $page_id
    return:
       true wenn Update durchgeführt werden konnte
       false wenn bei Fehler, weil z.B. Datensatz nicht mehr existierte
  }

  function delete_lease( $user_id ) {
    lösche alle Leases wo timeout < now  oder user_id == $user_id
  }

}

Diese Klassenfunktionen lassen sich jetzt problemlos z.B. in den Aufruf zu modify_page einbauen. Bzw. delete_lease() in die allgemeine Anzeige des Backends, wenn der Aufruf nicht für modify_page bestimmt ist.


   

[Waldschwein]

Ja das habe ich auch geglaubt - bis zu dem Tag, an dem ich Silverstripe installiert habe. Das ist einfacher als bei WB.

Das hab ich einmal gestern auf XAMPP gemacht - grauenvolles Ding als "Ganzes" betrachtet. Für den Geek sicherlich gut, aber alleine schon wenn man 1 Minute auf eine neue Seite im Backend warten muss... Nein Danke.  Viel zu unübersichtlich, viel zu überladen, und viel zu langsam. Ob es gut ist weiß ich nicht, aber da ist Drupal von dem Schlage CMS schneller und übersichtlicher, wenn auch etwas unlogischer aufgebaut, was ich zugeben muss...

Zum Sperren: Versionierung ist sicher ein ganz guter Ansatz, wobei das vorgeschlagene von DarkViper wenn es geht ja auch nicht so schlecht klingt.

[albatros]

Hi Waldschwein,

Deine Aussage zu Silverstripe beruhigt mich jetzt aber. Ich habe es auch auf den XAMPP gelegt und nur mal kurz reingeschaut. Mein Eindruck war ähnlich. Ich werde es mir aber trotzdem noch genauer ansehen. Was für Obama gut war kann für mich ja nicht schlecht sein. 

Gruß

Uwe

[Stefek]

Habe mir SS auch schon mal angeschaut.
Es mag für eigene Projekte gut sein, aber meine Kunden würde ich nur ungern an so ein Monster setzen.

Da kommt nix über WB. Jetzt mit eigens für Kunden erstellten BackendThemes ist es unschlagbar.


DarkViper: nicht schlecht, nicht schlecht...

Gruß,
Stefek