we:userInput wysiwyg="true" -> kein Bilderupload

[mobby]

Möchte man über <we:userInput type="textarea" name="content" wysiwyg="true" /> eine Grafik einfügen, bekommt man im Fenster keine Uploadmöglichkeit angezeigt, siehe Anhang.
Ist dies ein bekanntes Problem?

[WBTMagnum]

Hallo Mobby,

Ich denke das ist einfach nicht vorgesehen. Hätte ich auch nicht erwartet, dass das geht.

Liebe Grüße,
Sascha

[mobby]

Moin,
komisch. Wieso sollte es nicht gehen bzw.ist dies nicht vorgesehen? Ein Redakteur soll doch ruhig die Möglichkeit haben, in einen Artikel Bilder einzubauen.

[WBTMagnum]

Du schreibst hier von <we:userInput/>. Das ist ein Front-End Tag.

Liebe Grüße,
Sascha

[mobby]

Ja genau, der Redakteur soll übers Front-End arbeiten können.

[WBTMagnum]

Hallo mobby,

Naja, für die Einpflege von Inhalten durch die RedakteurInnen ist eigentlich auch das Backend gedacht. Dort klappt es dann auch mit dem Upload.

<we:userInput/> ist - wie der Name schon sagt - für User generated Content. Hier muss das System naturgemäß restriktiver sein.


Liebe Grüße,
Sascha

[e_herrmann]

Ich finde an dieser Stelle muss Webedition langsam echt mal nachlegen.
Das FrontendEdit ist immer öfter gefragt, da (zumindest meine) Kunden es gewohnt sind, sich auf Seiten anzumelden und Änderungen vorzunehmen. Ein Backend wie bei WE, das je eine eigene Applikation ist, ist da oftmals zu viel. Es geht den meisten darum, mal einen Text zu ändern, oder ein Bild auszutauschen. Da muss alles selbsterklärend sein.
Für eine kleine Handwerkerseite braucht der Entwickler das CMS um bequemer arbeiten zu können. Der Kunde braucht es nicht, der wäre mit einem FrontendEdit besser (einfacher) dran.
Und da WE ja nun ein WebApplication Framework ist, sollte es solche Werkzeuge zur Verfügung stellen.

Sorry mobby, dass ich deinen Post hier für mein Anliegen nutze, aber du hast ja offenbar in dem Punkt ähnliche Vorstellungen.

Grüße Elko

[mokraemer]

Das Front-End-Edit ist ursprünglich dazu gebaut worden um einen Blog bauen zu können und mittlerweile ausgebaut worden. Es war nie dazu gedacht das Backend abzulösen.
Dafür gibt es eigentlich den SEE-Mode, der ja eine abgespeckte Variante des Backends ist.

Der wysiwyg-Editor hat ja auch weitere Beschränkungen, daß man bspw. keine Links auf interne Dokumente setzen kann, weil man dafür ja Zugriff auf den Dateibaum geben müßte und sich hier keine Rechte mehr kontrollieren ließen.

[ThomasGoebe]

Der wysiwyg-Editor hat ja auch weitere Beschränkungen, daß man bspw. keine Links auf interne Dokumente setzen kann, weil man dafür ja Zugriff auf den Dateibaum geben müßte und sich hier keine Rechte mehr kontrollieren ließen.

Warum denn das? Natürlich ließen sich bei entsprechender Architektur da die Rechte kontrollieren. Das Argument kann ich nicht nachvollziehen.

Klar ist, dass FrontEnd Editing ursprünglich anders gedacht war. Aber in webEdition 1 gab es auch keine Medienverwaltung und ... schwups ist eine da, weil sich die Anforderungen geändert haben. Nun scheinen sich, zumindest nach der Beobachtung mancher die Anforderungen an das FrontEnd Editting zu ändern.
Od das dann der SEEMode ist (nutzt den eigentlich jemand wirklich produktiv?) oder ein "echtes" FrontEnd Editing ist fast egal. Auch ein deutlich ausgebauter SEEMode könnte eine gute Lösung sein. Aber vermutlich kann der nie so flexibel sein, wie es gebraucht wird. Einen Content Management Framework stünde ein Mehr an Werkzeugen für die Gestaltung der Eingaben durchaus gut zu Gesicht.

[mokraemer]

kein Ding, du kannst ja gerne mal einen Patch liefern, wir schauen uns das dann mal an.

Warum denn das? Natürlich ließen sich bei entsprechender Architektur da die Rechte kontrollieren. Das Argument kann ich nicht nachvollziehen.

Das ist die ewige Diskussion Kunden und Benutzer zu einem zu machen. Wir haben die Trennung und die Trennung macht auch Sinn. Ein Kunde (so ist unser Terminus noch immer) soll keine Seiten, oder Preise im Shop selbständig ändern.

[ThomasGoebe]

Hallo Marc,

vielen dank für Deine Antwort. Ich verstehe daraus, dass es primär keine technische sondern eine strategische Hürde ist. Es ist schlicht Eure (wer jetzt eigentlich genau?) Entscheidung, dass so was nicht kommt.
Das ist ok, damit kann ich leben und weiß woran ich bin. Ich habe nur Deine technische Begründung ("Die Berechtigungen können dann nicht abgeprüft werden.") nicht verstanden. Den Willen zur Veränderung dieses Sachverhalts vorausgesetzt, wäre das vermutlich lösbar.

Natürlich, und das weißt Du auch, bist aber vermutlich etwas angefressen, ist so was nicht mit einem Patch lösbar. Zumal es die klare Aussage gibt, dass es nicht gewollt ist, die nötigen Voraussetzungen zu schaffen (Kunde = Benutzer oder zumindest eine Verknüpfung der beiden). Damit wäre ich ja schön blöd, wenn ich Zeit in so einen Patch stecken würde, insbesondere, da es an sehr vielen Stellen einer Änderung bedürfte.

Noch einmal danke für die Klarstellung. Solche elementaren Aussagen helfen enorm, bei Projekten einzuordnen, ob webEdition mit Blick in die nahe Zukunft die richtige Basis für die Anforderungen des Projekts ist.

[WBTMagnum]

Ich denke die Trennung zwischen benutzergenerierten und redaktionell erstellten Inhalten macht jedenfalls Sinn. Ich würde nicht wollen, dass Front-End User Zugriff auf die im System abgelegten Daten und Strukturen erhalten. Ich möchte mich als wE-Entwickler auch nicht darum kümmern müssen, eine solche Kapselung bei meinen Projekten implementieren zu müssen.

Wie Marc schon angemerkt hat, bildet der SEE-Mode am ehesten die Idee von Front-End Editing ab. Wir selbst haben das aber auch nicht im Einsatz. Wäre schon interessant zu wissen, ob es da jemanden gibt, der das aktiv verwendet und wie da die Erfahrungen sind.

Á la longue wäre es natürlich fein, wenn es in Zukunft möglich wäre mit wE ein komplett eigenständiges Redaktions-Interface zu bauen. Andere CMS (z.B. WordPress) zeigen hier interessante Ansätze auf.

So etwas ist aber Zukunftsmusik und hilft Mobby bei seinem aktuellen "Problem" nicht weiter. Hier bleibt aktuell nur der Weg über <we:userInput type="img" /> und <we:userInput type="binary" />. Oder eben die Einpflege der Inhalte über das Backend selbst.

Just my 2 cents,
Sascha

[Carrear]

Ich meine mich an eine Diskussion vor kurzem zu erinnern in der genau anders herum argumentiert wurde. Da wurde gesagt bestimmte Lösungen würden im Backend nicht extra umgesetzt weil wE sich ja mehr richtung Framework entwickelt und man sich "Backends" selber bauen kann (was ja dann de fakto ein Backend im Frontend ist ) Aber egal: Unabhängig davon sollte doch der Programmierer der Templates entscheiden können ob er im Frontend einen Bildupload erlaubt oder nicht, oder?

[blickfang]

Hallo zusammen,

in den Zeiten von responsive Desig und ordentlicher Trennung von Layout und Content, sehe ich keine Notwendigkeit im wysiwyg Editor im Frontend Bilder einbauen lassen zu können. Schaut man sich die landschaft der Website-baukästen mal an, so setzen die meisten auf eine klare Trennung der Module (Text, Bild, Video,...). Das ist theoretisch heute schon mit webEdition realisierbar, limitierend ist da eigentlich nur die nicht verfügbare Block-Funktion im Frontend, nicht aber ein Bildupload im Tiny.

just my 2 more cents
Timo

[Carrear]

Stimmt auch ! Nur wird der Aufbau schon etwas komplizierter wenn er auch gefloatete Bilder anbieten will - da ist man in der Bild-Text-Anordnung in einem WYSIWYG ja sehr einfach flexibel. Aber da muss man dann wohl durch. Ein Fan von der Vermischung war ich aber auch nie - sehe immer wieder bei Redakteuren, de WP benutzen, was dabei raus kommen kann