Drupal 8 Editor Plugins

Moin ,

nach weiterem stundenlangem Suchen und ob der "überwältigenden" Reaktion hier ist meine aktuelle Schnell-Einschätzung zu Drupal 8 :

• Dokumentationen zum Core und den Modulen sind selbst für einen Umsteiger von D7 mehr als dürftig, unvollständig und "lieblos"
• Dokumentationen gibt es (fast) nur in englisch
• Dokumentationen vor allem zu den nun integrierten Modulen (die sich meistens völlig anders "verhalten" bzw. administrieren) gibt es nicht
• grundlegende Änderungen, wie z.B. die Einführung von Composer und Console, sind nicht erklärt. Ich habe es (bisher) so vertstanden, dass man einen ssh-Zugang zum webServer dafür benötigt - was häufig aber nicht möglich ist. Außerdem habe ich kein Wort zu event. Sicherheitslücken dadurch gefunden
• viele Module sind noch nicht nach D8 portiert
• von benötigten Modulen gibt es häufig nur alpha oder beta-Versionen. Man kann nicht abschätzen, ob ein Nichtfunktionieren an dem frühen Stadium des Moduls, an eigenen Fehlern oder einfachem Nichtverstehen liegt
• mir ist es nicht gelungen, so grundlegende Module wie ein backup_db ans laufen zu bekommen

Damit ist ein produktiver Einsatz, selbst knapp ein Jahr seit Erscheinen, m.M. nach nicht möglich.
Ich habe mein D8-Projekt abgebrochen und fange es mit D7 nochmal neu an :-(

Christoph
P.S.
Bestätigung oder Wiederspruch wäre schön

Hallo,

Ich kann bei Dir unterschreiben. Mit D7 kenne ich mich mittlerweile gut aus und kenne die Stärken und Schwächen. Seit dem ersten Erscheinen von D8 habe ich nun einige Anläufe unternommen, damit rumzuspielen. Vor kurzem wollte ich das erste "richtige" Projekt damit umsetzen, scheitere aber bereits wieder an fehlenden Bestandteilen von Rules. Ich bin wieder zurück nach D7.

Den Composer und sogar Drush habe ich mit Ach und Krach auf dem lokalen XAMPP zum Laufen gebracht, behaupte aber, dass ein Anfänger mit der bestehenden Doku keine Chance hat. Wenn ich mich recht entsinne, brauchte ich das gesammelte Wissen von gefühlt 100 Beiträgen aus verschiedenen Quellen....

Seit einigen Tagen habe ich einen ssh-Zugang zum Hosting, was mir das Leben jedoch deutlich erleichtert. Die Installation des Composers war ein Klacks und selbst Drush 7 und 8 funktionieren koexistent.
Mit Sicherheit werde ich niemandem ein D8-Projekt ohne ssh montieren.

Wenn ich es richtig verstanden habe, benötigt man auch für D8 nicht zwingend Drush und auch nicht Composer. Du kannst D8 ganz normal von drupal.org herunterladen und auf dem „herkömmlichen“ Weg installieren. Composer und Drush können enorm Zeit sparen, aber auch nur wenn man diese Werkzeuge täglich einsetzt.
Die Funktionen des CKEditor wurden in der Tat ausgemistet / entschlankt. Auf den ersten Blick fehlen aber keine, die für Drupal nicht sowieso schon immer entbehrlich waren (z.B. „Speichern“, „Neue Seite“, „Vorschau“). Oder täusche ich mich?

Moin,

iCH habe keinen Weg gefunden, z.B. Videojs OHNE Composer mit dem CDN zu verbinden - und Libaries API gibt es nicht mehr (und somit keine Möglichkeit, das JS-Script lokal zu kopieren) - zumindest habe ich nirgendwo eine Anleitung gefunden WIE das geht.
2. Der Editor HAT viele WICHTIGE Funktionen verloren, ich nennen nur mal
- Suchen und ersetzen
- Bildabstand und Textumfluss einstellen
- Rechtschreibprüfung
- iFrame
- Textfarbe
- Hintergrundfarbe
- Anker setzen
- Teaser Break
- Seitenumbruch beim Drucken einfügen
reicht dir das?
Klar, kann man auch coden ... aber RÜCKschritt kein FORTschritt
Und wie soll man Plugins dem CKEDitor hinzufügen ohne Composer?
Ich kann mich nicht des Eindrucks erwehren, das ganze D8 auf (große) Werbeagenturen zugeschnitten ist (Vorbild: Typo3), die
- den ganzen Tag nix andere machen als Drupal
- eigene Server mit ssh- oder lokalem Zugang verfügen
um all die "Konkurenz" der vielen Kleinen, die "auch mal Drupal machen" loszuwerden.
Schade - da hat jemand (wieder mal) nicht verstanden, wo seine Wurzeln und damit sein Erfolg liegt.

Christoph

Drupal hat sich zu einem Enterprise Framework entwickelt, das Out-of-the-Box Anwender mehr und mehr aus dem Blick verloren hat. Für diese Zielgruppe gibt es inzwischen deutlich ausgereiftere Systeme (z.B. Wordpress, Contao) als noch vor fünf Jahren.

Mal davon abgesehen, daß dieser "Jemand" eine Comunitity und keine einzelnen Person oder ein einzelnes Unternehmen ist, sähe Drupal 8, wenn Du Recht hättest jetzt noch ganz anders aus, wenn sich niemand um die einfachen Anwender kümmern würde. Daß in der Drupal-Community bewußt von großen Agenturen die normalen Anwender verdrängt werden insbesondere mit einer Strategie "es absichtlich kompliziert zu machen" entbehrt meiner Meinung nach jeder Grundlage. Natürlich verfolgen Unternehmen auch eigene Interessen, die allerdings häufiger gegen andere Unternehmen gerichtet sind. Auch haben einige Unternehmen einen großen Einfluß auf Drupal. Da gibt es genügend Konkurrenz und auch andere Community-Mitglieder, die das sehr genau im Blick behalten. Aber vor allem haben meiner Meinung insbesondere große Agenturen etwas davon, daß das System nicht unnötig kompliziert wird. Die Schulung von Personal wird dadurch nämlich nicht günstiger ...

Auf der anderen Seite gibt es vor allem einige Fakten, die Deine Theorie eher widerlegen. Denn es gibt in der Drupal-Community eine große Lobby für einfache Anwender. Das sieht man z.B. an speziellen Usability Initiativen für's "Backend". Aber am besten sieht man das an Drupal 8 selbst, das immer noch ein recht aufgeblähtes Standard-System ist. Wenn es nach mir gegangen wäre (wofür ich auch auf drupal org geworben habe), hätte D8 einen schlankeren Core und eine Standard-Community Distribution. Aber es wurde anders entschieden und weiterhin alles in das Standard-Drupal gepackt, das sich auch im Interesse der einfachen Anwender immer noch ohne Drush oder Composer installieren lässt. Um den einfachen Anwendern entgegen zu kommen und damit Drupal Out-of-the-box ein nutzbares CMS und nicht nur ein Framework ist, gibt es übrigens überhaupt erst einen WYSIWYG-Editor im Core (was ich persönlich eher weg gelassen hätte). Und im Interesse der Einfachheit ist dieser nun im Moment wohl noch etwas unflexibel (was mir auch schon aufgefallen ist). Und da scheint ja Dein Problem zu liegen bezüglich der Anfangs-Posts. Du kannst ja gerne mal versuchen, Deine anscheinend dann doch gehobenen Ansprüche mal mit den anderen, einfacheren CMS zu realisieren.
Drupal ist eben sehr flexibel und dies schätzen viele an Drupal. Aber die Flexibilität bringt eben auch eine gewisse Komplexität mit sich, die dann wiederum häufig Unmut herauf beschwört. Dies Spannungsfeld treffe ich immer wieder an. Es lässt sich aber wahrscheinlich auch nicht so leicht lösen. Aber die große Flexibilität von Drupal inkl. dem Versuch möglichst Anwenderfreundlich zu sein wird von vielen, vielen Menschen voran getrieben und davon werden einige von den besagten großen Agenturen bezahlt, um dies zu tun. Das ganze ist sehr transparent auf drupal.org nachvollziehbar bis hin zu den Aufwänden, die in den Usability-Initiativen geleistet wird. Auch kann sich jeder an den Diskussionen auf drupal.org beteiligen.

Ps.: Für einen SSH-Zugang benötigt man übringes nicht unbedingt einen eigenen Server, den gibt's auch bei Shared-Hosting-Paketen.

Drupal ist ein strukturiertes CMS, während Contao oder auch Typo3 eher Seitenbasierte Systeme sind.

In Drupal gestaltet man die Ausgabe nicht mit dem Editor, weil man zig bessere Möglichkeiten hat.

Dadurch dass Drupal so stark strukturiert ist, lassen sich beliebige Verwaltungssystem leicht aufbauen, macht aber eine rein Seitenbasierte WEB-Seite komplizierter, als Anfänger, die HTML gelernt haben, erwarten.

Drupal ist anders, und man muss sich ein bisschen darauf einlassen.

Wer ständig versucht mit Drupal an den Drupalmitteln vorbei zu entwickeln, muss frustriert irgendwann aufgeben.

Lass dich auf Drupal ein, auch wenn es ein paar Tage dauert, es lohnt sich.

Was ich persönlich ebenfalls sehr schade finde. Denn für was sind Distributionen da? Aktuelle Projekte wie Thunder, Lightning und Panopoly demonstrieren ja, dass dieses Konzept erfolgreich nach D8 übernommen wurde.

BLUBB - immer derselbe salbungsvolle Sermon von Dir!

Der TE ist nur in diesem Fall leider kein Drupal-Anfänger, sondern jemand, der schon hinreichend Erfahrungen mit D7 hat und das auch zu schätzen weiß. Und nun feststellt, dass vieles von dem, das er an D7 zu schätzen gelernt hat, in D8 bislang nicht bzw. nicht ohne unverhältnismäßigen Aufwand zu realisieren ist.

Und ich kann das nachvollziehen. Eigenprojekte habe ich mehrfach mit D8 anfangen wollen, dann aber festgestellt, dass ich mit D7 viel schneller ans Ziel komme. Weil irgendwo ein Modul kaputt bzw. noch nicht fertig ist. Weil ich mich für die Nutzung von Modul XY erst in Composer einarbeiten muss. Um mal eben "quick&dirty" was aufzusetzen, passt das einfach noch nicht. "quick&dirty" in Anführungszeichen, weil im Prinzip auch nicht dirty, aber eben mit einfachen Bordmitteln mit D7 auch nachts um 3 im Halbschlaf schnell am Ziel.
Ich habe hier einen Kunden, der von D6 runter muss und gefragt hat, ob wir D7 nicht einfach überspringen und D8 machen (da es eine Hilfsorganisation ist, ist das Budget begrenzt). Ein anderer Kunde mit einer fetten Seite mit vielen Community-Funktionen und Workflows fragte ebenfalls an, ob der Wechsel nach D8, vielleicht dieses Jahr schon, sinnvoll sei. In beiden Fällen habe ich davon (vorerst) abgeraten, weil ich mit einem fetten Overhead rechne. Und das kann es doch nicht sein.
Selbst so vermeintlich einfache Sachen wie Pathauto und entsprechende Pfadmuster sind unter D8, wenn man es unter D7 kennt, ein absolut unintuitiver Krampf.

Und ja, ssh gibt es auch auf normalem Webspace, aber nicht überall. Je nachdem, wo der Kunde bislang ist, ist ein Wechsel kundenseitig auch nicht erwünscht. Lieschen Müller mit ihrem 1&1-Paket fällt da aus der Zielgruppe jedenfalls mal komplett raus. Da kann auch noch so sehr ein CKEditor integriert sein, damit Lieschen Müller kein HTML kennen oder sich selbst einen Editor installieren muss.

Sehr schön, das musste mal gesagt werden ;)

Davon abgesehen kann ich nur mit dem Kopf schütteln, wenn ich diesen Thread hier lese. Der CKeditor ist nicht mehr so, wie er mal war, in Rules funktionieren einige Sachen noch nicht, das ist ja doof. Und überhaupt sind noch viele contrib- Module in alpha und früher war das Leben sowieso besser und das Benzin war auch billiger also nehmen wir lieber wieder den Schnee von gestern --> Drupal 7.

Und dann auch noch so neues Zeugs wie Composer und Drupal Console. Wie soll ich das denn auf meinen Webspace kriegen? Eigentlich gar nicht, denn entwickelt wird doch lokal... Öh da muss ich ja 'ne lokale Umgebung haben....ach nee...

Wie wäre es denn, wenn ihr - statt immer zu maulen - euch entweder aktiv an der Entwicklung der Module und der Dokumentation beteiligt oder euch euer Zeugs selber schreibt oder WP, Contao, Joomla etc. benutzt. Oder heißt Open Source jetzt neuerdings, dass die Contrib- Entwickler meist völlig unbezahlt zack zack alles D8 ready haben müssen, damit die dienstleistenden "Experten" vor Ort die Websites für ihre Kunden - gegen Honorar versteht sich - möglichst bequem zusammenklicken können.

Ich finde, einige Leute hier sollten mal ihre Erwartungshaltung gründlich überdenken. Vielleicht auch mal in Wien bei fago anrufen und mal nachfragen, wie viel Arbeitsstunden z.Bsp. in Rules stecken. Da könnt ihr bei der Gelegenheit gleich was spenden ;)

Moin,

Bitte lies noch mal meinen Threat-Anfang. Da steht nix von "früher war alles besser" und das war auch kein Gemaule sondern sachliche Kritik (und ich habe zu Wiederspruch meiner Meinung aufgerufen).

Ich finde, du solltest deine Haltung zu openSource mal überdenken/ergänzen/auf den aktuellen Stand bringen.
openSource-Projekte leben vom mitmachen (ich betreue selber eines im Bereich Datenbanken). Mitmachen heißt aber NICHT nur mit PROGRAMMIEREN, sondern fängt an mit MELDEN - Fehler melden, möglichst exakt beschreiben, geht weiter über BESEITIGEN der Fehler, über TESTEN und "endet" in der WEITERENTWICKLUNG. Alles das ist originären Bestandteil der MITARBEIT an openSource-Projekten.
Und es liegt in der Natur der Sache, das es IMMER viel mehr reine ANWENDER als tatkräftige ENTWICKLER gibt (die IMMER zu wenige sind).
Und noch eine Anmerkung: man/frau/ich kann nicht an JEDEM Projekt GESTALTEND mitwirken ("auf allen Hochzeiten" tanzen"), sollte aber UNTERSTÜTZEND mitmachen. Das habe ich getan. Nicht mehr und nicht weniger.
Ich habe die Erfahrung gemacht, das die Entwickler manchmal die Übersicht und das "Empfinden" zu Ihren Anwendern verliehren und immer von Ihren EIGENEN Voraussetzungen und Wünschen ausgehen - sie benötigen mal hin und wieder Anwendersicht.

Christoph

...schon klar, das ist sachliche Kritik ;) Aber mal zurück zum Thema CKeditor:

Bilder einfügen und positionieren ist build-in. Das Insert Module ist damit überflüssig
Folgende contrib- Module erweitern die Core Funktionalität: https://www.drupal.org/documentation/modules/ckeditor/contrib
Man kann die Plugins von ckeditor.org auch manuell integrieren, wenn man in der Lage ist, ein config file zu editieren

Libraries Modul: Brauchst du nur noch, wenn mehrere eingesetzte Module gleiche Abhängigkeiten haben. Erstmal also nicht.

Moin,

dann will ich mal versuchen, deine Antworten umzusetzen:

Bilder einfügen und sagen Text links oder rechts davon ist build in. Das sieht so aus wie im Auswahl_008
Unter D7 sah das so aus - siehe Auswahl_009
Unter D8 ist das nicht mal für minimalste Anforderungen geeignet.
Das kannst du also nicht gemeint haben. Aber WAS hast du gemeint? WIE geht es z.B. mit einem Horizontal-Abstand?
Wie kann kann ich die GRÖSSE des eingesetzen Bildes anpassen? Das ging mit dem Modul insert - das konnte ich BEIM Einsetzen in den Text die Bildgröße auswählen - also ÜBERFLÜSSIG ist die Funktion nicht. Klar, kann ich auch alles im Quellcode einfügen ... es ist aber nicht der Sinn eines WYSYWIG-Editors zu coden.

kein Einziges ist dabei für Bildverarbeitung ... und einige (viele?) funktionieren nicht (zumindest nicht nach deren eigener Installationsanleitung): z.B. Fontsize, Loreimsum, Smily, Spoiler ... mehr hab ich dann nicht mehr probiert.

Solche pauschalen Aussagen sind - entschuldige - ungeeignet, einem weiter zu helfen. Sag mir nicht DAS es geht, sag mir WIE es geht ... vielleicht auch nur mit einem Hinweis wo das schon mal ein anderer beschrieben hat.

Christoph

Habe hier eigentlich nur wegen dem im Editor fehlenden Teaser Break gesucht, dann via der Kommentare meine Eindrücke der letzten Wochen grundsätzlich bestätigt bekommen.

Seit Anfang 2014 betreue ich ein relativ komplexes Drupal 7 Projekt (Mehrautorenblog) incl. lokalem Backup, lokalen Tests unter XAMPP. Der Schwerpunkt liegt weniger im Multimedia-Bereich, denn bei Zugriffsrechten, erweiterten Rollen, privaten, nichtöffenlichem Dateisystem, selektiv nichtöffentlichen Nodes und Themeswitching je nach Funktionalität und natürlich dem PN-System (Private Messages). Bilde mir also ein, halbwegs fit mit D7 zu sein.

Für ein neues Projekt sollte nun D8 genutzt werden, wo (offensichtlich) vieles nicht nur anders ist, oft einfach (noch?) nicht geht, obwohl das Teil bereits im Core ein Vielfaches an Umfang zeigt, die Installation dieses Trum lokal wie beim Provider diverse Tücken offenbarte.

Gerade die Tage gelesen, das Problem mit den Themes:

https://www.ostraining.com/blog/drupal/drupal-org-themes/

Wobei auch die vorhandenen, getesteten mir alle irgendwie hilfsbedürftig daherkommen. Und bei den Modulen sieht es auch nicht viel besser aus, finde ich jenseits gewisser Core-Funktionalität bestenfalls die Hälfte der mir vertrauten, von mir benötigten Module; oft noch als alpha etc.Version .

Ergo: Early Adopter kommen auf ihre Kosten, der Bastelfaktor ist mit Sicherheit hoch, nur ich lasse dann mal eine Version aus, schaue vielleicht in ein bis zwei Jahren mal wieder nach D8; ggf. seinem Nachfolger ...

Gruß, Bernd