Beitrag während der Bearbeitung Sperren

[doc]

Hi,

@Dark-Viper
Mir ging es mehr darum erstmal zu überlegen welche Funktionen WB gut zu Gesicht stehen würden (Staging war nur eines der Features) und sich dann Gedanken über die Umsetzung zu machen (z.B. WB 3.0).

Ich vermisse bei WB gelegentlich den Blick über den Tellerrand. Nen guten Ansatz gabs in diesem Thread (aktuell aber wieder etwas eingeschlafen).

Silverstripe war nur ein Beispiel (und ja die Performance ist schlecht, es sei denn man hat genügend Arbeitsspeicher). Gut gelungen finde ich in Silverstripe die Aufbereitung der Seiten Informationen (Meta tags, Links, Inhalt), oder die Versionierung und Freigabe von Seiten (Staging), die automatische Skalierung eines Bildes wenn dieses im Editor grösser/kleiner geschoben wird, das hochladen von Dateien ... Ähnlich coole Features gibt es auch in anderen CMS Systemen (z.B. TYPOlight etc.). Kein CMS das ich bisher getestet habe, macht alle Sachen richtig gut, einer Stelle hackt es eigentlich immer. Denoch kann man sich viel abschauen.

Denke Features die tief in den Kern des CMS eingreifen, sollte man nicht mal so eben einbauen (gutes Beispiel multiple groups). Dein Vorschlag ist einer von x-Möglichkeiten. Auf Kundenwunsch hatte ich mal einen "Seite sperren" Button integriert und im Seitenbaum eine Anzeige ausgegeben, wer die Seite belegt hält. Der Kunde war glücklich, ich fands die Lösung ne Krücke

Gruss Doc

[erpe]

Ich vermisse bei WB gelegentlich den Blick über den Tellerrand. Nen guten Ansatz gabs in diesem Thread (aktuell aber wieder etwas eingeschlafen).

Ich bin immer wieder überrascht, wie gerne und viel denn auch (mit)-diskutiert wird.
Wenn es aber dann an die Umsetzung geht und man auch mal in die Tiefe schauen muss (und nach oben und links und rechts) dann ist von der "Herrlichkeit" meist nicht mehr viel übrig.

Wenn es zu diesem Thema ein Ticket gibt, dann könnte man ja die Lösung von DarkViper einfach mal da dran hängen.
Dann erreicht es auf jeden Fall die Devs.
Wenn es kein Ticket gibt, kann man eins eröffnen.

Aber grundsätzlich gilt doch:

Features die tief in den Kern des CMS eingreifen, sollte man nicht mal so eben einbauen

Ansonsten kenne ich niemanden, der für ernsthafte,  gute, sinnvolle und umsetzbare Vorschläge nicht offen wäre.

Gruss

erpe

[Waldschwein]

Ich vermisse bei WB gelegentlich den Blick über den Tellerrand. Nen guten Ansatz gabs in diesem Thread (aktuell aber wieder etwas eingeschlafen).

[...]
Kein CMS das ich bisher getestet habe, macht alle Sachen richtig gut, einer Stelle hackt es eigentlich immer. Denoch kann man sich viel abschauen.

Hallo!

Och, ich denke im Moment wird mehr über den Tellerrand geblickt als jemals zuvor, nur ist das halt nicht für jeden sichtbar. Es wird alles andere gemacht als nichts.   Und soweit ich weiß wird auch nichts mehr herumgefrickelt, Bugfixes für 2.8 wird es noch geben, aber neue Features allgemein für den 2.x Strang wohl generell eher nicht, oder zumindest nichts was in den Core eingreifen würde. Nur steht halt im Moment das erste Mal in der WB Geschichte jeder im Team wirklich direkt in einem Team was eine abgegrenzte Sache tut und kann nicht mehr sagen "aber das ist ja eigentlich Arbeit von XY, und ich muss ja noch abwarten bis..." Und das jedem - der Community als auch den Mitgliedern - klarzumachen dauert bekanntlich.
Dass kein CMS alles richtig macht ist klar, definitiv. Das ist aber überall so. Perfektion gibt es nirgends. Ich hab mir auch oft die Haare gerauft als Anwender über WB...

Aber nun zurück zum Thema: Alles ist gut, solange es den Benutzer nicht verwirrt, und für 90% der Benutzer Mehrarbeit bedeutet. Wenn es eine Versionierung gibt ist das natürlich sehr schön, doch sollte das auch abzuschalten sein, am Besten sogar standardmäßig. Auch ich würde mir gerne solch eine Versionierung wünschen, gerade weil es unter Umständen viel Arbeit erspart, wenn durch irgendetwas (un)vorhersehbares die jetzige Bearbeitung total misslingt (gerade bei solchen, wo das Layout direkt im FCKEditor geschieht wie z.B. auf der start.wb2.org). Und man hat immer vorher alles abgespeichert, aber wie man weiß gerade dann wenn etwas passiert eben nicht.

Gruß Michael

[doc]

Hi,

Wenn es kein Ticket gibt, kann man eins eröffnen.

Erledigt: Ticket #824

Gruss Doc

[Hans>NULL]

@DarkViper
Machedochmoa soweit färtsch, dasses jeder mal ausprobian kann. (copy&paste)

Gruß, Hans>NUL

<offtopic>

Und soweit ich weiß wird auch nichts mehr herumgefrickelt,

So sehe ich es mittlerweile auch. Anfangs noch manchmal "erbost" (immer noch mit/im Rückblick, sorry), nehme ich die neue Herangehensweise sehr wohl war. Da wo nötig wurde gefixt, neues wird zumindest überdacht. Die Grenzen des Ausbaus sind für Interessierte sichtbar und werden kommuniziert. Eine sehr gute Entwicklung!
</offtopic>

[DarkViper]

ich schau mal, ob ich's heute Nacht noch online bekomme. So als 'inoffizieller Patch' mit Anleitung.

[Hans>NULL]

Na, aber bitte nicht überschlagen. (Purzelbaum-Smiley)
Erstmal vorab schon Dank für Deine Bemühungen.
Da nicht klar ist, wann es in branches einfließt, die haben ja nun noch vieles andere zu tun   , kommt es zumindest für meine Anwender und auch für mich zur rechten Zeit. Sogar DOC's Warn-Button wäre schon hilfreich gewesen. Deine Lösung ist natürlich selbstredend zu bevorzugen. Nicht immer sitzen Redakteure ein Zimmer weiter  
Wenn schon keine ausgebaute Rechteverwaltung in WB 2.8, ist Deine Lösung hervorragend dazu geeignet bestehende Konflikte auszuräumen. Sehr gut! Das wertet das CMS ungemein auf.

Gruß, Hans>NUL

[DarkViper]

Ok, das hat jetzt etwas länger gedauert, da ich die Tage viel unterwegs war.
Die Tests bei mir liefen fehlerfrei, mal sehen, wer erster Betatester wird.  

ACHTUNG:: dieser Patch ist KEINE offizielle Erweiterung (zumindest jetzt noch nicht...). Folglich wird er auch in keinem offiziellen WB-Update etc. berücksichtigt werden!!

Ich habe für das Locking gleich noch 2 Optionen in den erweiterten Optionen des Backends eingebaut:

• Locking ein- / ausschalten (default: aus)
• beliebige Sperrzeiteinstellun g zwischen 60 Sekunden und 24 Stunden (default: 1800sec)

Wer zusätzliche Sprachen (ausser DE/EN) benötigt, darf sich die Übersetzungen in den jeweiligen Sprachdateien selbst einbauen...
Wer ein anderes Backend-Theme als argos benutzt, darf die erforderlichen Ergänzungen in der jeweiligen settings.htt ebenfalls selbst einbauen..

Wer trotz der ausführlichen Einbauanleitung mit dem Patch nicht klar kommt, sollte seine Finger von derartigen Eingriffen lassen. Zusätzliche Hilfe zu Einbaufehlern gibt es nicht (Tester-Feedbacks selbstverständlich ausgenommen).

viel Spass damit...
Werner

[Hans>NULL]

Noch ein Nachtarbeiter  
Wunderbar, nur werde ich erst zum Wochenende dazu kommen. Schaffe neben viel Arbeit an einem neuen Multiflex rum; das kostet Zeit.

Bin aber gespannt wie'n Bogen. Mal gucken, wie lange ich's aushalte  
Vermute mal, daß sich noch mehr User drauf stürzen werden. Die Features hören sich ja mehr als vielversprechend an.
Dank und Gruß, Hans>NUL

Edit: Der Änderungen sind ja nicht viele und leicht zu bewältigen, tolle Anleitung!

Ich bin denn (erst)mal weg... 

[doc]

Hi,

@DarkViper:
Schöner fix, gut kommentiert. Eventuell noch ne klare Bemerkung dazuschreiben, dass Dein Fix zwingend PHP 5 (falls nicht bereits irgendwo geschehen) voraussetzt. Für WB 2.8 reicht derzeit noch PHP 4.4.9. Ansonsten Hut ab, einfach, sauber und effektiv.

Gruss Doc

[DarkViper]

Das Thema PHP4 ist seit längerem 'beerdigt', deshalb denke ich schon gar nicht mehr an einen Hinweis darauf .

News-Archiv auf php.net

PHP 4 end of life announcement
[13-Jul-2007] Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.
The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

Spätestens seit dem 01.01.2008 schreibe ich keine Zeile explizit PHP4 kompatiblen Code mehr und seit Anfang 2009 versuche ich bewusst keine Funktionen mehr einzusetzen, die für PHP5.3/PHP6 als deprecated gekennzeichnet sind. Allerdings werden meine Applikationen solange unter PHP5.2.x lauffähig bleiben, bis auch dieses vom Entwicklerteam beerdigt wird.  

Werner

"arbeite für die Zukunft, die Vergangenheit lässt sich nicht mehr ändern..."

[Hans>NULL]

@DarkViper
Das Teil "solltest" Du auch in EN plazieren.
Gruß, Hans>NUL

[doc]

@DarkViper:

Das Thema PHP4 ist seit längerem 'beerdigt', deshalb denke ich schon gar nicht mehr an einen Hinweis darauf.

Vernünftiger Standpunkt. Denke spätestens mit WB 2.9 wird das Thema PHP 4 dann auch für WB durch sein, wenn ich das auf der Startseite richtig interpretiere.

WebsiteBaker 2.8 ist zwar unter PHP 4.4.9 lauffähig, es wird jedoch auch hinsichtlich verschiedener Zusatzmodule PHP 5.2 als Minimal-Voraussetzung dringend empfohlen.

Gruss Doc