Aprilliaracer
Lt. Junior Grade
- Registriert
- März 2005
- Beiträge
- 289
MrTengu schrieb:
Symfony 2 ist halt ein Framework und kein fertiges CMS. Das eine hat ja nix mit dem anderen zu tun.
News Sicherheitslücke: Warnung vor kompromittierten Drupal-Installationen
- Ersteller fethomm
- Erstellt am
- Zur News: Sicherheitslücke: Warnung vor kompromittierten Drupal-Installationen
Symfony 2 ist halt ein Framework und kein fertiges CMS. Das eine hat ja nix mit dem anderen zu tun.
![[n]ARC](https://pics.computerbase.de/forum/avatars/m/69/69789.jpg?1290264056){kind=avatar}
[n]ARC
Lieutenant
- Registriert
- Apr. 2005
- Beiträge
- 855
MrTengu schrieb:
Das ist jetzt nicht dein Ernst, wenn ihr im Core hacken müsst, dann habt ihr schlicht und einfach keine Ahnung von Drupal und vom Drupal-Way. Drupal-Coding-Standards sind warscheintlich für euch auch nur böhmische Dörfer. Drupal, besonders die Version 8 (leider noch Beta) ... ist das beste was es im Moment auf dem Markt gibt. Es existieren keine Aufgaben, die mit Drupal nicht umgesetzt werden.
Daddi89
Lt. Junior Grade
- Registriert
- Aug. 2008
- Beiträge
- 283
Naja, Drupal lässt schon sehr zu wünschen übrig. Wenn ein paar Content-Types mit je 10 Feldern dazu führen, dass eine Seite ohne Varnish oder andere Caching-Systeme extrem langsam wird, sehe ich das nicht so. Aber wundert auch nicht, wenn einfache Singe-Page Anzeigen (z.b. eine einzelne Node), Datenbankabfragen mit > 20 Joins benötigen, weil jedes Feld ne eigene (bzw. gleich mehrere) Tabellen bekommt. Ich hab nicht selten in Projekten zwischen 400 und 500 Tabellen, für eine einzelne Seite. Für Sitebuilder ist das System sicher nicht schlecht, aber definitv ist es nicht das Beste was es im Moment auf dem Markt gibt.[n]ARC schrieb:
Mit welchem CMS gibt es denn Aufgaben, die nicht umgesetzt werden können? Du hast doch immer (in dem Falle) PHP oder die entsprechende Programmiersprache im Hintergrund über die du im Endeffekt immer "jede" Aufgabe lösen kannst.[n]ARC schrieb:
[n]ARC
Lieutenant
- Registriert
- Apr. 2005
- Beiträge
- 855
Das schöne an Drupal, es ist kein CMS sondern ein FMS. Vielles kann nichts muss, man muss den Core nicht hacken um etwas zu erreichen. Wir haben das mächtige Drush und eine Vielzahl an Tools. Und mal unter uns, welcher vernünftiger Mensch verzichtet auf Caching? Opcache an, memcache an und Varnish. Da kann noch so viel kommen, Drupal bewältigt es. Von welchem CMS kann das noch behauptet werden.
Drupal bietet nun mal flexible Entitys, sicher kommen da einige Joins zusammen. Aber mit Cache ist das Ding flink wie sonst was. Ich spreche aus Erfahrung, wir setzen große Enterprice Lösungen für Namhafte Hersteller und Firmen um. Wir reden hier nicht von Sidebuilding, sondern Individuallentwicklung und zwar auf dem Drupal-Way. Wir hatten mal bei einem Projekt über 20 unterschiedliche Contenttypes, mit einer dynamischen Anzahl an Entitys, nichts war da langsam. Wenn man weiß was man tut, die Module nach den Coding-Standards verknüpft und die Views mit A/B Tests erstellt.
Zeige mir mal bitte ein DB-basiertes CMS, welches eine Vielzahl an Inhalten verwalten soll und noch flüssig ohne Cache läuft. Das ist halt Quatsch, jeder nutzt Cache und mit Varnish haben wir eine wirklich starke Waffen gegen Performance einbüßen. Wenn man sich ganz blöd stellt, einfach alles in den Varnish, fertig ist der Salat.
Kann die Kritik absolut nicht verstehen.
Sicher kannst Du das Rad neu erfinden, doch wozu. Ich würde z.B. nie auf die Idee kommen mit Wordpress ein Shop umzusetzen. Selbst Magento würde ich dafür nicht einsetzen. Drupal kann alles, ist OpenSource, hat eine GEWALTIGE Community hinter sich und das flexibelste was ich bis heute gesehen habe.
PS: Aber es gibt ja auch noch leute, die nicht mit GIT arbeiten, sondern schön mit FTP. Sich mit der Materie nicht auseinder setzen und dann sagen, Drupal ist scheiße
Drupal bietet nun mal flexible Entitys, sicher kommen da einige Joins zusammen. Aber mit Cache ist das Ding flink wie sonst was. Ich spreche aus Erfahrung, wir setzen große Enterprice Lösungen für Namhafte Hersteller und Firmen um. Wir reden hier nicht von Sidebuilding, sondern Individuallentwicklung und zwar auf dem Drupal-Way. Wir hatten mal bei einem Projekt über 20 unterschiedliche Contenttypes, mit einer dynamischen Anzahl an Entitys, nichts war da langsam. Wenn man weiß was man tut, die Module nach den Coding-Standards verknüpft und die Views mit A/B Tests erstellt.
Zeige mir mal bitte ein DB-basiertes CMS, welches eine Vielzahl an Inhalten verwalten soll und noch flüssig ohne Cache läuft. Das ist halt Quatsch, jeder nutzt Cache und mit Varnish haben wir eine wirklich starke Waffen gegen Performance einbüßen. Wenn man sich ganz blöd stellt, einfach alles in den Varnish, fertig ist der Salat.
Kann die Kritik absolut nicht verstehen.
Sicher kannst Du das Rad neu erfinden, doch wozu. Ich würde z.B. nie auf die Idee kommen mit Wordpress ein Shop umzusetzen. Selbst Magento würde ich dafür nicht einsetzen. Drupal kann alles, ist OpenSource, hat eine GEWALTIGE Community hinter sich und das flexibelste was ich bis heute gesehen habe.
PS: Aber es gibt ja auch noch leute, die nicht mit GIT arbeiten, sondern schön mit FTP. Sich mit der Materie nicht auseinder setzen und dann sagen, Drupal ist scheiße
@ Cool Master
Also mein Drupal schreibt mir auch eine Mail wenn es Updates gibt.
Und mein Drupal prüft das per cron jede Stunde.
Das sollte jede Drupal installation können. Und ich brauche kein Drush zu installiern.
Und wer es nicht kann der kann Drupal per Plesk installiern dann geht das update glaub ich automatisch.
Ich habe leider auf meinem Webhosting keinen Cache deshalb habe ich einfach Boost installiert das erzeugt eine html datei.
Und der nginx liefert diese datei sehr schnell aus weil er genau dafür gemacht wurde.
Also mein Drupal schreibt mir auch eine Mail wenn es Updates gibt.
Und mein Drupal prüft das per cron jede Stunde.
Das sollte jede Drupal installation können. Und ich brauche kein Drush zu installiern.
Und wer es nicht kann der kann Drupal per Plesk installiern dann geht das update glaub ich automatisch.
Ergänzung ()
Ich habe leider auf meinem Webhosting keinen Cache deshalb habe ich einfach Boost installiert das erzeugt eine html datei.
Und der nginx liefert diese datei sehr schnell aus weil er genau dafür gemacht wurde.
[n]ARC schrieb:Das schöne an Drupal, es ist kein CMS sondern ein FMS. Vielles kann nichts muss, man muss den Core nicht hacken um etwas zu erreichen. Wir haben das mächtige Drush und eine Vielzahl an Tools. Und mal unter uns, welcher vernünftiger Mensch verzichtet auf Caching? Opcache an, memcache an und Varnish. Da kann noch so viel kommen, Drupal bewältigt es. Von welchem CMS kann das noch behauptet werden.
Drupal bietet nun mal flexible Entitys, sicher kommen da einige Joins zusammen. Aber mit Cache ist das Ding flink wie sonst was. Ich spreche aus Erfahrung, wir setzen große Enterprice Lösungen für Namhafte Hersteller und Firmen um. Wir reden hier nicht von Sidebuilding, sondern Individuallentwicklung und zwar auf dem Drupal-Way. Wir hatten mal bei einem Projekt über 20 unterschiedliche Contenttypes, mit einer dynamischen Anzahl an Entitys, nichts war da langsam. Wenn man weiß was man tut, die Module nach den Coding-Standards verknüpft und die Views mit A/B Tests erstellt.
Zeige mir mal bitte ein DB-basiertes CMS, welches eine Vielzahl an Inhalten verwalten soll und noch flüssig ohne Cache läuft. Das ist halt Quatsch, jeder nutzt Cache und mit Varnish haben wir eine wirklich starke Waffen gegen Performance einbüßen. Wenn man sich ganz blöd stellt, einfach alles in den Varnish, fertig ist der Salat.
Kann die Kritik absolut nicht verstehen.
Sicher kannst Du das Rad neu erfinden, doch wozu. Ich würde z.B. nie auf die Idee kommen mit Wordpress ein Shop umzusetzen. Selbst Magento würde ich dafür nicht einsetzen. Drupal kann alles, ist OpenSource, hat eine GEWALTIGE Community hinter sich und das flexibelste was ich bis heute gesehen habe.
PS: Aber es gibt ja auch noch leute, die nicht mit GIT arbeiten, sondern schön mit FTP. Sich mit der Materie nicht auseinder setzen und dann sagen, Drupal ist scheiße
Zuletzt bearbeitet:
Das ist die einzig korrekte Aussage dazu.dylan1982 schrieb:
Updates? Ja gerne. Updates zeitnah? Auch gerne. Updates vollautomatisch, ohne Staging-Umgebung? Nä. Wenn dann DOCH was am Update hakt, geht vielleicht eine Seite mitten zur Hauptverkehrszeit down.
Fehler passieren, und was diese spezielle Injection angeht: Ich hab die umliegenden Codezeilen mal überflogen, "auffällig" ist echt was anderes. Wenn man nicht bis über die Schultern im Projekt steckt sieht man da nicht, wo genau die Lücke ist.
Der einzige Fehler, der hier gemacht wurde: Die Bedeutung der Lücke wurde massiv unterschätzt. DAS darf nicht passieren. Alles andere (allen voran die Existenz der Lücke) ist durchaus vertretbar.
Auch andere Projekte haben solche Probleme. Contao hatte Anfang des Jahres mal einen derben Sicherheits-Schluckauf, der über viele Jahre unentdeckt blieb.
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 37.458
testerMR schrieb:
1. Es ist Cool Master aber ok
aber ja, die Mails sollten auch kommen wenn man es nicht am Anfang deaktiviert hat. Plesk sagt mir nichts da ich nur root server habe und somit vollen zugriff auf das System habe.@Daaron
Wie gesagt man hat Backups wenn beim einspielen der Updates was schief geht aber in der Regel macht ein Core Update nichts aus. Module lass ich z.B. nicht automatisch updaten nur den Core.
Zuletzt bearbeitet:
(einspielen der Backups --> einspielen der Updates)
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 37.458
Bei einer Webseite halte ich das nicht für so schlimm. Wie gesagt da kann man ein Backup in wenigen Minunten wieder einbinden und die Seit läuft wieder. Ich hatte damit bis jetzt aber auch nie Probleme bei einer gleichbleibenden Major Version. Gleiche wie bei Debian auch noch nie ein Problem bei einem dist-Upgrade gehabt (innerhalb der Major).
Denk mal nicht an eine einfache Firmen-Homepage mit 5-10 statischen Seiten und nem Kontaktformular. Denk auch nicht an ein Forum. Selbst ein Newsportal, wo du im Zweifel durch n 1h-Rollback die Stundenleistung von 5-10 Redakteuren nullst, ist da noch recht egal.Cool Master schrieb:
Aber denk mal an ein Shopsystem mit richtig schönem Durchsatz. Was machst du mit den Bestellungen, die zwar bezahlt wurden, aber deren Bestellnummern, Rechnungsdaten, bestellte Warenkörbe,... du jetzt killst. Bei einem Shopsystem kriegst du beim Einspielen eines Backups extreme Probleme, auch mit dem Finanzamt. Das wird stutzig, wenn in den Rechnungsnummern plötzlich ein Sprung drin ist oder, was bei nem Rollback wahrscheinlicher ist, REchnungsnummern doppelt vergeben werden.
Und bei einem Webdienst hat man mindestens ein Staging-System, auf dem man erst einmal die Verträglichkeit des Updates prüft.Falcon schrieb:Naja, dafür gibts ja WSUS mit Testfeld etc.
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 37.458
Na mein lieber [n]ARC, da hat du dich aber ganz schön weit aus dem Fenster gelehnt.
Redkite, Bolt, praktisch alle, die auf SF2 oder deren Komponenten basieren. Und da muss ich nicht tausend Extramodule installieren, damit die Kiste performant läuft.
Drupal verwendeten wir als CMF, was ist ein FMS?
Joins sind nicht langsam, wenn die Indexes richtig gesetzt sind. Es geht auch gar nicht um Joins.
Wie greifst du nochmal auf ein Value einer Entity zu? $node->value[LANGUAGE_NONE][0]['value'] ? Wann hast du jemals was anderes als LANGUAGE_NONE verwendet?
Musst du auch nicht. Wenn du mit Drupal glücklich bist, bleibe dabei.
Was hat FTP mit GIT zu tun?
Drupal kann NICHT alles, es will gern eine eierlegende Wollmilchsau sein, aber das ist es nicht.
Und wer will das Rad neu erfinden? CMS gibts wie Sand am Meer. Viele nutzen SF2 als Unterbau und setzen die CMS Fähigkeit einfach darüber.
Jawohl. Nach mehr als 60 Modulen für Drupal habe ich keine Ahnung vom "Drupal Way".
Schon mal die Standardsprache auf "de" gestellt? Kann man ja machen. Blöd nur, dass Drupal die Sprache "en" hardcodiert im Core hat. Gibt ein paar schöne Überraschungen beim Übersetzen weil man das nicht gleich merkt. Aber klar, es ist ja vermutlich kein Drupal Way, die Standardsprache umzustellen. Dieser Fehler war schon in Version 6. In Version 7 wurde der bis jetzt nicht beseitigt.
MySQL Master/Slave konfigurationen? Fehlanzeige! Lesend von Slave, Schreibend auf Master. Versuchs mal. Aber bitte den Drupal Way! Da schreibst du nämlich für jede Verbindung das Ziel hin, weil Drupal zu blöd ist, eine Lesequery zu erkennen und den auf den Slave umzuleiten. Aber warte...da gibt es doch das Modul "Autoslave", das macht genau das. Blöd nur, dass dann auf einmal das update.php von Drupal nicht mehr geht, weil der virtuelle Datenbanktreiber nicht vom Update erkannt wird. Was tun? Core hacken! Das wird sogar empfohlen, damit man das Update noch nutzen kann.
Allgemein schreibt man einen Cache aus Performancegründen nicht in die Datenbank. Dafür muss man aber erst das Modul Filecache installieren. Warum ist das nicht von Anfang an drin?
Apropos Übersetzungen...Ändere mal den einen Schreibfehler im englischen Sourcestring. Ooops, alle Übersetzungen des Strings sind futsch und müssen nochmal neu gemacht werden. Die alten Sprachstrings sind natürlich weiterhin in der Datenbank und müllen das System zu.
Globale Hooks sind übrigens sowas von out. Jedoch wird selbst in Drupal 8 nicht darauf verzichtet. SF2 hat ein Eventsystem, warum wird das nicht verwendet?
Authentifizierung externer User? Z.B. per XMLRPC? Geht, aber warum müssen die Nutzer zusätzlich in der Drupal DB gespeichert werden? Warum ist nur eine einzige Emailadresse möglich?
Die Suche von Drupal. Das Ding indiziert wirklich ALLE Inhaltstypen, ist nicht einstellbar. Die Suche selbst macht LIKE Abfragen über die DB. Da kannst du cachen wie du willst, das sind extrem langsame Abfragen.
Ich hab letztens 20k Inhalte importiert. Wie lange soll ich den Cron laufen lassen bis die alle indiziert sind?
Die ach so tolle Community spaltet sich übrigens gerade, weil der Umstieg von D7 zu D8 dermaßen viel Änderungen am Code mitbringt und den bisherigen "Drupal Way" auseinanderreißt.
Und zu guter Letzt haben wir hier einen fatalen Bug, der seit 1 Jahr existent ist und erst im letzten Monat als kritisch eingestuft wurde, nachdem ein EXTERNES Audit die Gefährlichkeit ermittelt hat.
Wie schon gesagt, wenn ihr mit Drupal glücklich seid, bleibt dabei. Für mich sind es jedoch einfach zu viel Stolpersteine geworden und es sieht keinesfalls so aus, als würde sich das ändern. Im Gegenteil.
[n]ARC schrieb:
Redkite, Bolt, praktisch alle, die auf SF2 oder deren Komponenten basieren. Und da muss ich nicht tausend Extramodule installieren, damit die Kiste performant läuft.
Drupal verwendeten wir als CMF, was ist ein FMS?
Joins sind nicht langsam, wenn die Indexes richtig gesetzt sind. Es geht auch gar nicht um Joins.
Wie greifst du nochmal auf ein Value einer Entity zu? $node->value[LANGUAGE_NONE][0]['value'] ? Wann hast du jemals was anderes als LANGUAGE_NONE verwendet?
Musst du auch nicht. Wenn du mit Drupal glücklich bist, bleibe dabei.
Sicher kannst Du das Rad neu erfinden, doch wozu. Ich würde z.B. nie auf die Idee kommen mit Wordpress ein Shop umzusetzen. Selbst Magento würde ich dafür nicht einsetzen. Drupal kann alles, ist OpenSource, hat eine GEWALTIGE Community hinter sich und das flexibelste was ich bis heute gesehen habe.
PS: Aber es gibt ja auch noch leute, die nicht mit GIT arbeiten, sondern schön mit FTP. Sich mit der Materie nicht auseinder setzen und dann sagen, Drupal ist scheiße
Was hat FTP mit GIT zu tun?
Drupal kann NICHT alles, es will gern eine eierlegende Wollmilchsau sein, aber das ist es nicht.
Und wer will das Rad neu erfinden? CMS gibts wie Sand am Meer. Viele nutzen SF2 als Unterbau und setzen die CMS Fähigkeit einfach darüber.
[n]ARC schrieb:
Jawohl. Nach mehr als 60 Modulen für Drupal habe ich keine Ahnung vom "Drupal Way".
Schon mal die Standardsprache auf "de" gestellt? Kann man ja machen. Blöd nur, dass Drupal die Sprache "en" hardcodiert im Core hat. Gibt ein paar schöne Überraschungen beim Übersetzen weil man das nicht gleich merkt. Aber klar, es ist ja vermutlich kein Drupal Way, die Standardsprache umzustellen. Dieser Fehler war schon in Version 6. In Version 7 wurde der bis jetzt nicht beseitigt.
MySQL Master/Slave konfigurationen? Fehlanzeige! Lesend von Slave, Schreibend auf Master. Versuchs mal. Aber bitte den Drupal Way! Da schreibst du nämlich für jede Verbindung das Ziel hin, weil Drupal zu blöd ist, eine Lesequery zu erkennen und den auf den Slave umzuleiten. Aber warte...da gibt es doch das Modul "Autoslave", das macht genau das. Blöd nur, dass dann auf einmal das update.php von Drupal nicht mehr geht, weil der virtuelle Datenbanktreiber nicht vom Update erkannt wird. Was tun? Core hacken! Das wird sogar empfohlen, damit man das Update noch nutzen kann.
Allgemein schreibt man einen Cache aus Performancegründen nicht in die Datenbank. Dafür muss man aber erst das Modul Filecache installieren. Warum ist das nicht von Anfang an drin?
Apropos Übersetzungen...Ändere mal den einen Schreibfehler im englischen Sourcestring. Ooops, alle Übersetzungen des Strings sind futsch und müssen nochmal neu gemacht werden. Die alten Sprachstrings sind natürlich weiterhin in der Datenbank und müllen das System zu.
Globale Hooks sind übrigens sowas von out. Jedoch wird selbst in Drupal 8 nicht darauf verzichtet. SF2 hat ein Eventsystem, warum wird das nicht verwendet?
Authentifizierung externer User? Z.B. per XMLRPC? Geht, aber warum müssen die Nutzer zusätzlich in der Drupal DB gespeichert werden? Warum ist nur eine einzige Emailadresse möglich?
Die Suche von Drupal. Das Ding indiziert wirklich ALLE Inhaltstypen, ist nicht einstellbar. Die Suche selbst macht LIKE Abfragen über die DB. Da kannst du cachen wie du willst, das sind extrem langsame Abfragen.
Ich hab letztens 20k Inhalte importiert. Wie lange soll ich den Cron laufen lassen bis die alle indiziert sind?
Die ach so tolle Community spaltet sich übrigens gerade, weil der Umstieg von D7 zu D8 dermaßen viel Änderungen am Code mitbringt und den bisherigen "Drupal Way" auseinanderreißt.
Und zu guter Letzt haben wir hier einen fatalen Bug, der seit 1 Jahr existent ist und erst im letzten Monat als kritisch eingestuft wurde, nachdem ein EXTERNES Audit die Gefährlichkeit ermittelt hat.
Wie schon gesagt, wenn ihr mit Drupal glücklich seid, bleibt dabei. Für mich sind es jedoch einfach zu viel Stolpersteine geworden und es sieht keinesfalls so aus, als würde sich das ändern. Im Gegenteil.
Zuletzt bearbeitet:
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 37.458
@MrTengu
Ja Sprache ist aktuell in Drupal noch eine Qual. Wird aber mit 8.0 besser werden
Ich finde es auch gut, dass sich etwas ändern weil so wie es aktuell ist, ist es einfach nur eine Qual. Ich habe selber schon Themes geschrieben und da vermisse ich Django einfach wie die Sau, weil es einfach leichter und eleganter war.
Ja Sprache ist aktuell in Drupal noch eine Qual. Wird aber mit 8.0 besser werden
Ich finde es auch gut, dass sich etwas ändern weil so wie es aktuell ist, ist es einfach nur eine Qual. Ich habe selber schon Themes geschrieben und da vermisse ich Django einfach wie die Sau, weil es einfach leichter und eleganter war.@Cool Master:
Naja, wir müssen sowieso den Code komplett neu schreiben für Drupal 8. Und da stellen wir uns natürlich die Frage, ob sich das lohnt. Zumal wir bereits mehrere SF2 Installationen haben und ich schon einige Apps dafür geschrieben habe.
Wenn man einfach mal nur die Fakten zusammenfasst und auf einer Liste pro/kontra gegenüberstellt, ist die Sache einfach klar.
Naja, wir müssen sowieso den Code komplett neu schreiben für Drupal 8. Und da stellen wir uns natürlich die Frage, ob sich das lohnt. Zumal wir bereits mehrere SF2 Installationen haben und ich schon einige Apps dafür geschrieben habe.
Wenn man einfach mal nur die Fakten zusammenfasst und auf einer Liste pro/kontra gegenüberstellt, ist die Sache einfach klar.
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 37.458
Jo klar kann ich verstehen. Bei uns war es so Django weiter benutzen und mit den Nachteilen leben oder auf ein neues CMS? Letzeres hat gewonnen. Da wir für ein Video Projekt vor einiger Zeit Drupal eingesetzt haben, blieb das natürlich im Hinterkopf für das neue Projekt also Drupal benutzt und seitdem werden wir in naher Zukunft unsere alten Django(-CMS) Installationen auf Drupal umstellen sobald es 8.1/8.2 gibt. Ich hoffe ja noch auf ein Release dieses Jahr damit man nächstes Jahr direkt anfangen könnte umzustellen aber ich glaube das wird nichts.
