Ist das möglich?: Code des Themes ändert sich ohne Zutun?

Da gibt es natürlich viele Möglichkeiten und wenn Du das Projekt neu übernommen hast, würde ich mal grundsätzlich das "niemand hat irgendetwas geändert." hinterfragen. ;-)

Welche D7 Version ist das?
Wurde sie im März aktualisiert, als die Sicherheitslücke bekannt wurde?
Ich meine, sieht ja nicht, wie eine klassische Hacker-Aktivität aus, aber dennoch natürlich eine der ersten Fragen.

Dem Bild nach ist das vermutlich weniger eine Sache vom Bootstrap Theme, als vom Modul https://www.drupal.org/project/views_bootstrap.

D.h. Du solltest auch hier die Versionen abgleichen, nicht nur das Theme.
Könnte natürlich auch mal der Hoster eine PHP-Version verändert haben.

Aber ganz ehrlich: Ich glaube doch eher an eine händische Veränderung in der View.

So doof es klingt, ich habe ähnliche Erfahrungen gemacht. Und zwar einmal mit einem Subtheme zu Framework, ein anderes Mal mit einem Subtheme zu Foundation und in einem dritten Fall mit einem Subtheme zu Zen. Ich habe zwar was geändert, nämlich Updates gemacht, aber eigentlich gibt es keinen Zusammenhang zu den Themes, da ich diese nicht ins Update einbezogen hatte.

Im Framework-Fall war nach den Updates die Sidebar weg, im Foundation-Fall waren eine ganze Reihe Styles in Unordnung gekommen, z.T. im Kontext von media queries, im Zen-Fall war das Menu der Desktop-Ansicht nicht mehr sichtbar.

Tja, da bleibt wohl nur Zähne zusammenbeißen und nachschleifen. Ging mir genauso ;-) ...

Naja, ist ja kein Wunder. Das Theme macht ja nur den groben Rahmen des Designs.
Alles was an Inhalten in den Regionen erscheint, wird von Core oder irgendwelchen Modulen geliefert.
Also klar, dass sich da auch mal was ändern kann, was so nicht gewollt war.

Vollkommen richtig, so sehe ich das auch.

In dem einen Fall hatte z.B. das responsive_dropdown_menu Modul eine Klasse geändert bzw. gestrichen - da hängt natürlich ein Style, der daran geknüpft ist, etwas unglücklich in der Luft.

Hallo und sorry, ich betreue viele Projekte.

Ja das stimmt. Nach Rückfrage entstanden die Fehler nach einem Update.

Bin auch schon ein Stück weiter. In den Block-Details der Ansicht (bzw.View) habe ich plötzlich viel mehr Optionen als vorher, die code-technisch alle eingearbeitet werden (xs, md, lg usw.).

Mal sehen, ob ich da weiterkomme. Bin aber grundsätzlich genervt von Systemen, die man permanent konfigurieren muss. Alles für die Anzeige ein paar Bilder und Text. Das wäre ohne Drupal viel einfacher.

Gruß Matthias

Ok, gelöst ...und noch die Auflösung:

Durch das Update kamen einige neue Optionen in der Darstellung des Blocks hinzu, die alten wurden dadurch einfach ungültig. So war die Bs-Standardklasse "col" einfach nicht mehr da, weil die Spalten-Klasse nun optional anzugeben ist. Auch das Verhalten bei verschiedenen Device-Größen mussten nun manuell erneuert werden.

Hmmm... in meinem Augen widersprich das dem Prinzip, dass ein CMS für Laien geeignet sein sollte.

Gruß Matthias

Steile These, wer hat die denn aufgestellt?

Klar, Laien sollen Texte schreiben können.
Aber für die Administration von Drupal sollte man schon Ahnung haben.
Ist halt ein sehr mächtiges Tool.

Ich verstehe Deinen Ärger allerdings, dass das Modul da solche Änderungen rein bringt.
Keine Ahnung, wofür man das überhaupt installiert hat.

Ähhm... ging es beim CMS nicht grundsätzlich darum, Inhalte im Web veröffentlichen zu können, ohne über HTML-Kenntnisse verfügen zu müssen?

Naja, kann mich auch täuschen. :-)

Gruß Matthias

geht es natürlich, wenn es jemanden gibt, der die Website einrichtet, pflegt und wartet. So ist das auch gedacht.

Von selbst geht leider nicht viel. Von Drupal sollte man als Newbie - auch in der Basisversion ohne zusätzlichen Schnickschnack - die Finger lassen, wenn man eine schlüsselfertige laientaugliche Installation will. Irgendwas ist immer. Drupal ist eine lange, manchmal beschwerliche Reise, kein Schnell-mal-zwischendurch-Kurztrip. Da gibt es andere. Aber selbst bei Website-Baukästen wie Wix, Jimdo oder WP-Elementor muss man sich erst mal eindenken ...

Ja, genauso wie Kissmedve das schreibt, habe ich das auch gemeint.

Eben, selbst bei Wordpress und dgl. geht das nur lange gut, wenn Fachleute, die sich damit auskennen, alles so bereit stellen, dass der Laie / Redakteuer sorglos schreiben kann.
Ich hatte halt verstanden, Du hast die Installation übernommen und dann gehört Wartung auch dazu.
Das geht bei Drupal sehr schwer ohne dedizierte Kenntnisse.

Wir sind da alle einer Meinung, kein Ding.

Ich habe da nur ein persönliches, grundsätzliches Problem mit Typo3, WP, Drupal, Joomla und Co. Ich halte alle Kandidaten für viiiiel zu komplex. Denn meiner Erfahrung nach nutzen Kunden diese Systeme um Inhalte auf ihrer Website zu veröffentlichen (z.B. News, Bilder, Videos usw.), vielleicht auch als Cloudspeicher und eine Benutzerverwaltung ist für viele auch nicht schlecht. Das aber lässt sich mit herkömmlicher Programmierung ganz oft viel einfacher umsetzen und pflegen. Der ganze Konfigurationsaufwand, der bis zum nächsten Update (oder noch schlimmer: Modul-Installation) immer nur irgendwie klappt, ist im meinen Augen dem Ergebnis gegenüber unangemessen hoch. Und wenn dann ein Modul individuell geändert werden muss, weil der Kunde vielleicht etwas möchte was er woanders gesehen hat, dann ist es ja meistens komplett vorbei: Mehrere Tage vergehen um hinter dem Eingabefeld ein Sternchen zu platzieren o.ä.

Weiterhin ist die Usability für den Kunden ebenfalls enorm schlecht. Nicht nur diese unzähligen Optionen, die man selbst erstmal verstehen muss, überfordern den Betreiber oft. Diese ewigen Warnungen und Hinweise (Update verfügbar = Bombenalarm) verleiten den Betreiber ebenfalls dazu, das Update mal eben selbst durchzuführen. Und was dann passiert, kann man am Anfang dieses Threads lesen. Von Geschwindigkeit, Serverkompatibilität und Ressourcenhunger usw. möchte ich gar nicht erst anfangen.

Aber wie gesagt: Ich betrachte das in Bezug auf das, was ich vom CMS zurückerhalte. Und das ist für mich nicht stimmig. CMS mag ich übrigens sehr, wenn sie klein und praktisch sind und der Nutzer/Kunde Freude daran hat.

Gruß Matthias

Da stimme ich Dir absolut zu. Bei den Individualisierungen ist ja nicht PHP das Problem, sondern den richtigen Hook und das entsprechende Howto zu finden - die vielen Abstraktionsschichten und Schnittstellen, die so ein modulares Konfigurationssystem benötigt, führen zu, im System betrachtet, sicher sinnvollen, aber von außen gesehen unerwarteten Konstruktionen.

Auch zum Themen ist es zeitsparender, nicht alles mitthemen zu müssen, was der Kunde eventuell selbst konfigurieren könnte (in Grenzen!), sondern nur das, was wirklich jetzt und direkt im HTML ankommt.

Ich arbeite für kleine Seiten derzeit mit Flat Files CMS und bin ziemlich begeistert von Herbie. Grav mag auch gut sein, aber das schaut ein bisschen aufgeblähter, nach einer Nummer größer, aus. Mein bisheriges CMS für kleine Seiten Contao entwickelt sich schon zu sehr in Richtung Kundenüberforderung, vor allem wegen des Ressourcenhungers.

Mein Problem mit der Aussage ist, dass ich sie für viiieeeel zu pauschal halte. ;-)

Ich habe mit TYPO3 und Drupal schon Seiten umgesetzt, die mit kleinen CMS nicht zu bauen gewesen wäre.
Und selbst programmieren hätte jeden Budget-Rahmen gesprängt.

Die Diskussion ist doch nicht zielführend, wenn nicht bekannt ist, von welchem Projekt man redet.
Im Grunde muss man bei jedem Projekt neu überdenken, mit welchem CMS.
Ich mache auch immer mal wieder eine Webseite statisch, ganz ohne Datenbank, wunderbar...

Mit TYPO3 mache ich gar nichts mehr, weil ich mich irgendwann entscheiden musste, ob ich Drupal oder TYPO3 weiter anbiete.
Beides wäre nicht seriös, eben weil komplex. Das sind sie, aber sie sind nicht zu komplex, da wo sie geeignet sind.

Wenn Dein Kunde die "herkömmliche" Programmierung - was immer das ist- zahlt, dann ist ja gut. ;-)
Und wenn dann die Eigenprogrammierung so sicher ist, dass man nie ein Update braucht, noch besser...nur ich glaube es nicht.
Der Kunde erfährt nur nicht, dass ein Update dringend nötig wäre.

Und die Benachrichtigungen kann man so einstellen, dass der Kunde davon nichts erhält.
Und man kann ihm auch einschärfen, dass der Fehlersupport teurer wird, wenn er selbst dran langt.
Der Hausbesitzer ist auch angehalten, nicht an die Elektrik zu langen, wenn er sich damit nicht auskennt.
Macht er es dennoch und es gibt einen Kurzen, dann wird kein Elektriker das auf eigene Kappe reparieren....
Dann ist aber nicht das Haus zu komplex, sondern ein anderes Problem liegt vor...

Ressourcenhunger Kennen wir bei Drupal nicht, wir stecken einfach mindestens 64 GB in einen VPS für 1 Kundenprojekt und dann ist alles ok :-)

Nein im Ernst Grav als Flat-CMS mit Twig aks Template-Engine setzen wir zum Beispiel auch hier ein.

localize.drupal.de

Einfach weils schön schnell geht und Twig nicht weiter schewr ist,

Aber meinen Kunden würde ich Grav nicht in die Hand geben. Das ist dann doch eher für Menschen, die sich auskennen. Da nimm ich lieber Drupal 8 aber dann halt wirklich auf einem VPS und nicht auf einem Shared Hosting Server. Der ist zwar schön billig, aber früher oder später reicht dein Ram dann eben nicht mehr. Ich stell jetzt einfach mal die behauptung in den Raum, dass Drupal auch nicht komplizierter ist als Typo 3 und eventuell auch nicht komplizierter als Contao. Das Problem hierzulande ist einfach, dass es uns an Litaratur fehlt, die wir nicht noch übersetzen müssen um sie zu begreifen. Selbst das Handbuch hier im Center ist bei D7 hängen gebleiben. Wen wundert es da, dass keiner mehr mit Drupal arbeiten will und viele, wenn es um D8 geht einfach nur noch rot sehen.

Zun Problenm oben, fals noch nicht gelößt:

Im übrigen ändert sich doch nicht der Code deines Themes einfach so. du müsstes eben die Breakpoints in Bootstrap entsprechend an die Bildschirmgrößen anpassen. Das Ding ist responsive und reagiert auf die Gräße des Bildschirms mit dem es betrachtet wird. Man muss Bootstrap aber noch sagen, ab wie viel Breite in Pixel welcher Breakpoint verwendet werden soll. Wird das falsch eingestellt, bekommst du unschöne Ergebnisse. In der Vesion für D7 musst du außerdem auf die Reiheinfolge in der theme.info achten, damit die Breaktpoints nicht genau verkehrt rum angewandt werden.

Mit Typo3 kenn ich mich nicht aus. Aber der wesentliche Unterschied zwischen Drupal und Contao ist einfach, dass Contao sich immer als Content Management System verstanden hat und Drupal eher als Framework mit dem Ansatz einer viel stärkeren Modularität. Je mehr Puzzleteile, desto mehr Puzzleteil-Schnittstellen, desto mehr Bestandteile, die ohne die Schnttstellen wegfallen könnten, desto mehr Fehlerquellen und Reibungsverluste.

Ursprünglich hatte Contao keinen großen Ressourcenhunger, genau genommen galt das bis einschließlich Contao 3.5x. Der Sprung kam mit C 4 und Composer, weil jetzt plötzlich viele Erweiterungen via Composer installiert werden müssen.

In der Contao-Community gibt es viel mehr Sitebuilder, die vom Design kommen, als in Drupal. Allein schon die Kommandozeile ist für viele von denen ein Schreckgespenst. Aber eigentlich hat die neue Architektur basierend auf Symfony nur sichtbar gemacht, dass die Zahl der Erweiterungen kontinuierlich gestiegen ist, das ganze Ökosystem heute nicht mehr so fokussiert ist wie zu früheren Zeiten (was normal ist) und auch Contao-Agenturen immer mehr Enterprise-Kunden bedienen wollen. Eine frustrierte Contao-Kollegin meinte: Contao will ein kleines Drupal werden ...
Und das bedeutet eben auch, dass Contao für eine Webvisitenkarte mit 10 pseudostatischen Seiten lange nicht mehr so interessant ist wie früher. Was für Drupal erst recht gilt. Drupal ist cool für komplexe Projekte, insbesondere wenn der Kunde später noch die Möglichkeit haben soll, vieles selbst zu bedienen, aber für so kleine Projekte ist es Mega-Overkill. Das war es, was ich meinte.

Ich habe mich selbst schon etwas mit Contao beschäftigt und fand das 3.5 recht smart.
Aber es bietet nicht die Flexiblität, wie Drupal mit CCK und Views.
Und meine Kunden, die fast alle Grafiker sind, für die ich die technische Umsetzung mache, konnte ich nicht überzeugen, Seiten, für die man keine Drupal-Funktionalität macht, mit Contao zu bauen.
Die wollen alle Wordpress, weil ihre Kunden das so wollen.
Folglich kam es nie dazu, dass ich nenneswerte Projekte mit Contao umgesetzt habe.
Inzwischen ist D8 so ausgereift und ich soweit eingearbeitet, dass ich meinen Fokus wieder fast ausschließlich auf Drupal lege.
Was ich eigentlich sagen wollte: Habe nun schon mehrfach gehört, dass die Contao Gemeinde noch mehr vom Umzug auf C 4 mit Composer entsetzt ist, als Drupal Sitebuilder von Drupal 8.
Contaoe 4 ist sicher nicht viel weniger komplex, als Drupal. Aber mit Drupal - weil es ein Framework ist, wie kissmedve schon schreibt, kann man eben noch viel mehr machen, falls der Kunde mal neue Anforderungen hat.
Wenn man all das mit Composer machen möchte, was Drupal im Core schon kann, dann ist es sogar deutlich komplexer.
Ich finde übrigens inzwischen nicht mehr, dass Drupal nichts für kleinere Projekte ist.
Man kann es so abgespeckt betreiben, dass es einfach einzurichten und zu bedienen ist.
Wordpress hat ja auch seine Haken und Ösen (ich sag nur: Gutenberg. ;-)).
So einfach, wie immer getönt wird, ist das auch längst nicht (mehr).