[gelöst] Änderungen im Reiter "Anzeige verwalten" eines Nodes werden nicht gespeichert

Ich bräuchte mindestens den Display Mode "PDF" des gerade neu installierten Moduls zur Generierung von PDF-Dokumenten aus Nodes.

Könnte ich hier nicht einfach als Workaround einen Parameter in der Datenbank-Tabelle ändern?
Welche Tabelle wäre denn für die Display Modes zuständig?

Habe leider in der Datenbank nichts gefunden. Aber müsste es nicht eine Tabelle geben, die eben jene Display Modes einzelnen Nodes zuweist?

also wenn es an den schreibrechten liegt, mußt du da hosteurope alles auf 777 setzen und den richtigen nutzer dazu....

Bei HostEurope hat man ja ein sehr gutes Error-Log.
Da stehen auch Server-Fehler-Meldungen, also nicht nur PHP-Errors.
Steht da wirklich nichts drinnen?

Ich war jahrelang bei HE, aber nicht mit View Mode / Display Suite gearbeitet.

Vielen Dank CAW und montviso für die Antworten.

Ich werde gleich mal alles auf 777 stellen, mal sehen was es bringt.

@Error-Log: Außer einer ständigen Warnung bzgl. "syslog()" ist leider nichts dabei... Da habe ich auch schon mit Host Europe telefoniert, die können leider die php.ini nicht anpassen und der Workaround, den der Mitarbeiter mir eingerichtet hat um den Fehler zu umgehen, scheint nicht zu funktionieren. Könnte es denn daran liegen?

Die Fehlermeldung lautet wie folgt:

An die Sys-Log Errormeldung erinnere ich mich auch noch.
Da war ich aber schon voll mit dem Umzug auf All-Inkl beschäftigt und bin dem nicht näher nach gegangen.

Hier steht, was die Ursache ist:
https://community.magento.com/t5/Installing-Extensions/Warning-syslog-ha...

Ob das Deinen Fehler verursacht, weiß ich nicht. Glaube ich aber nicht.

Insgesamt muss ich sagen, dass ich zuletzt (nach 15 Jahren) mit HE nicht mehr zufriedne war.
Composer läuft nicht, auch nicht auf dem Webpaket für 50Euro, was wir hatten.

Bei All-Inkl kann ich alle Composer Aufgaben auf dem wesentlich günstigern shared Hosting Paket easy durchführen und diese Sys-Log Fehlermeldung gibt es auch nicht.
Mit dem Support war ich jahrelang sehr zufrieden bei HE, zuletzt nicht mehr.
Die haben Änderungen vorgenommen, die dazu geführt haben, dass ich die Zugriffs-Logs nicht mehr mit dem gleichen Script holen konnte. Haben aber steif und fest behauptet, sie hätten nichts geändert.
Nach einer Anpassung im Script, die eindeutig auf Änderungen gedeutet hat, lief es dann wieder.
Ich hatte um bezahlte Hilfe in dem Fall gebeten, machten sie nicht...fand ich für den Preis sehr unflexibel.

Einziger Wermutstropfen bei All-Inkl, es gibt nicht das gute Error-Log, sondern man kann sich nur selbst über php.ini eine PHP-Fehlerer-Log dateie einbinden.

Was hast Du für ein Paket bei HE?

Man kann bei All-Inkl ein Paket kostenlos testen für - zu meiner Zeit - 30 Tage und dann ohne Angabe von Gründen kündigen.
Wäre evt. eine Maßnahme, mal zu testen, ob es dort funktioniert.

Die Umstellung auf 777 hat leider nichts bewirkt.

Bei HE habe ich WebServer Medium, allerdings würde ich ungern schon wieder den Hoster wechseln. Aber vielen Dank für die Info zu all-inkl., lese da häufig gute Rezensionen zu diesem Hoster.

Es muss doch aber eigtl. auch hier auf einem HE Server funktionieren - es hat ja auch schon funktioniert....

klingt danach daß jquery nicht richtig geladen wird...
dateien verloren? verzeichnis geändert?

normalerweise dürfte nichts verloren gegangen sein.

Habe das Verzeichnis gezipped von einem Server auf den anderen übertragen und dann auf dem Ziel-Server entpackt.
Da dürften alle Verzeichnisstrukturen erhalten geblieben sein (hoffe ich zumindest).

Die jQuery Dateien werden auch eingebunden, wenn ich "/admin/structure/types/manage/[NODETYPE]/display" aufrufe. Habe mal aus dem Firefox Debugger einen Screenshot angefügt.

Dabei hab ich jetzt aber auch bei der Netzwerkanalyse über Firefox herausgefunden, dass er bei einem AJAX-Aufruf hängen bleibt.

Status 200, Method Post, Ursprung xhr, Typ HTML.

das hängt dann in der regel vom server ab!
das hatte ich auch mal bei ein paar kunden. hoster gewechselt (oder auch evtl php memory) und schon gings...

Das mit dem PHP Memory ist ein guter Hinweis, habe den Speicher jetzt von 256 auf 512 MB gestellt (soll wohl min. 15 Minuten dauern bis die Änderung aktiv ist). Mal sehen, ob es was bringt.

Der Fehler besteht leider immer noch - und noch schlimmer: Ich habe ihn jetzt in die Drupal 8 Installation durch Migration mitgeschleift.
Ich hatte irgendwie gehofft, dass sich das Problem durch die Migration in Drupal 8 von selbst löst. Ein frommer Wunsch, wie es scheint.

Wenn ich jetzt in Drupal 8 eine Anzeige des betroffenen Inhaltstyps bearbeiten will - oder die Formularanzeige - erhalte ich folgende Fehlermeldung:

Das ist zumindest schon mal eine Fehlermeldung, mit der man arbeiten kann.
Nur was betrifft diese Fehlermeldung?

Sicherlich ein Wert in der php.ini. Aber welcher?

Oder kann ich da irgendwelche Einstellungen in Drupal selbst konfigurieren, dass die maximale Dateigröße z.B. 64 statt 32 MB ist?

EDIT

Habe folgende Werte in die htaccess eingefügt:

Ergebnis: Egal welchen Wert ich für "post_max_size" einfüge (habe 128M, 512M und auch 2000M ausprobiert), die Fehlermeldung erscheint trotzdem nur eben mit dem jeweiligen neuen Wert. Da es die Werte von "post_max_size" sind, nehme ich an, dass es sich explizit darauf bezieht. Vielleicht hilft euch das weiter? Mir leider noch nicht.

Was sagt denn die phpinfo() Funktion, welche Werte tatsächlich auf dem Server zum Zuge kommen?
Hier sind einige Tipps, aber viel Neues ist da wohl nicht dabei:
https://www.drupal.org/node/2608620

Vielen Dank monviso.

Die phpinfo() Werte zu "post_max_size":
Local Value: 2000M
Master Value: 32M

Also hat es den Wert wohl übernommen.

Ich habe in der zwischenzeit mal in Chrome ein Memory Snapshot des Fehlers machen lassen.
Dabei werden insgesamt 37 Fehler unter Drupal 8 erzeugt - angefangen mit einem JS-Fehler, der auf die Zeile

Drupal.AjaxError = function (xmlhttp, uri, customMessage) {

referenziert, gefolgt von ReferenceError, CompileError, LinkError, RuntimeError, TypeError, SyntaxError, EvalError, URIError, RangeError (viele davon mehrfach vorhanden).

Vielleicht hilft das weiter, den Fehler einzugrenzen? -.-

Was vielleicht auch hilfreich zu wissen ist, es handelt sich um einen Inhaltstyp mit sehr vielen Feldern: Insgesamt 232.

Folgende Feldtypen sind dabei:

• Language selection
• Text
• Element des Node-Moduls
• Datum
• Langer Text
• Bild
• Meta tag module form elements.
• Path module form elements
• Referenz auf Taxonomy-Begriffe
• Liste (Text)
• Arbeitsablauf
• Langer Text und Zusammenfassung
• Redirect module form elements
• Link
• Computed
• Dezimalzahl
• Liste (Ganzzahl)
• Ganzzahl

huiuiui...kann es sein, dass in den Feldern zusammen so viele Daten übertragen werden, dass es upload size überschreitet?
Hört sich nach einem echten Alptraum an. ;-)

Soweit ich mich erinnere, ist die maximale Größe die des Master-Values. Also ist bei 32MB Schluß. Das ist bei Shared-Hosting Paketen nicht unüblich. Mehr kannst Du nur mit einem eigenen (Virtuellen) Server mit root-Rechten einstellen.

Aber dann würden doch in Drupal nicht 200MB angezeigt werden?

Da müsste man mal den Hoster befragen.

Ich glaube, ein ähnliches Problem bekommt man wenn man zu viele Blöcke verwendet (Du verwendest ja sehr viel Felder)

Dann wird in der Blockübersicht die Reihenfolge nicht mehr gespeichert und auch nicht die Änderung, wenn man einen Block in eine bestimmte Region verschiebt. Die Reiterwerte, die man dort auswählt, werden dann einfach nicht mehr gespeichert.

Um das zu fixen, muss man in der php.ini die Input Variablen max_input_vars hochsetzen. Mach das mal testweise auf 2500.
max_input_vars = 2500

Wenn Du zusätzlich suhosin verwendest, muss Du auch dort die Werte hochsetzen.
suhosin.post.max_vars = 2500
suhosin.request.max_vars = 2500

Alternativ kann man das auch über die htaccess steuern (siehe Link)

https://drupal.stackexchange.com/questions/89843/cannot-re-order-the-blo...

Probiere das bitte mal aus.

@montviso: Ja, das IST ein Alptraum. Es ist ein über die Jahre "gewachsener" Inhaltstyp - ständig mussten neue Felder angebaut werden, um den Ansprüchen der Redakteuere zu genügen. Die computed-Fields, dachte ich zumindest, müssten die meiste Rechenleistung beanspruchen. Ansonsten sind da eher kleinere Textteile, wenige Bilder, die auch nicht sonderlich groß sind (eher so max. 500 Pixel) - also kaum Performance-lastige Feldinhalte. Dafür sind es aber wirklich viele. Es werden aber selten alle Felder in einem Beitrag genutzt - mal dieses, mal jenes, etc.

@Ionit: Vielen Dank für den Hinweis! Habe den Wert in die htaccess aufgenommen. DAS WARS!!! Boah! Du rettest hier nicht nur den Tag, sondern ein ganzes Projekt! Vielen Dank! (Nur für den Fall: Ich habe lediglich den Wert "php_value max_input_vars 2500" in meine htaccess eingefügt - kein suhosin oder so.)

Also folgendes befindet sich jetzt in der htaccess:

Vielen Dank euch allen für die nützlichen und hilfreichen Tipps und dass ihr mir geduldig Fragen beantwortet und mir hier geholfen habt, den Fehler zu finden.
Ihr seid klasse!!

Klasse, daran hatte ich nicht gedacht. Der Wert muß in manchen Projekten sogar noch deutlich höher gesetzt werden (z.B. auf 10000).

Ja, da haben wir alle was gelernt.
Den Wert beachte ich auch zu selten.