Tabellengröße eingeschränkt?

[eisenherz]

Erzeuge dir im Root deiner Contao Installation eine Datei namens pi.php und füge folgenden Inhalt ein:

<?php phpinfo();

Rufe diese PHP Datei dann auf und überprüfe dort den Wert von max_input_vars.

... und wie rufe ich so eine Datei so auf, dass ich den Wert überprüfen kann?

root wäre hier, oder?
Root.jpg

[Spooky]

... und wie rufe ich so eine Datei so auf, dass ich den Wert überprüfen kann?

Einfach im Browser die URL zu deiner Conato Installation eingeben und pi.php hinten dran.

root wäre hier, oder?
Root.jpg

Yep

[eisenherz]

...
überprüfe dort den Wert von max_input_vars.

da steht weiterhin 1000. Also sind die 5000 nicht akzeptiert, oder?
Wie kann ich meine Installation nun davon überzeugen , meinen Befehl zu übernehmen?

[tab]

Hmm, kann das mit FastCGI zusammenhängen, dass php_value eventuell nicht funktioniert? Wäre dann allerdings stark vom Hetzner-Support, das so vorzuschlagen

Edit: Mal ganz abgesehen davon, dass PHP 5.3.29 und Contao 3.5.x eigentlich nicht zusammenpassen, du brauchst PHP 5.4.0 oder höher.

[mlweb]

Ich habe das gerade mal auf einem meiner Kundenpakete Hetzner Level4 getestet. Das funktioniert. Hat bei mir allerdings so ca. 5min gedauert ehe das aktualisiert war.

[mlweb]

PHP-Version kannst Du bei Hetzner übrigens in der Konsole unter Einstellungen -> Konfiguration -> PHP-Konfiguration einstellen

[mlweb]

root wäre hier, oder?
Root.jpg

Ich habe mir gerade noch einmal Dein root-Bild angeschaut.
Abgesehen davon, dass es keine gute Idee ist den root-Pfad contao zu nennen, sieht das aber ausgesprochen eigenartig aus und eine .htaccess sehe ich im root auch nicht.
Unabhängig von den derzeitigen Problemen empfehle ich einen Contao-Check mit Überprüfung der derzeitigen Installation.

[fiedsch]

Ich habe das mal ausprobiert. Im BE funktioniert alles, dann kommt nach der Auswahl ein CSV Datei diese Fehlermeldung ... womit ich wieder raus bin.

Warning: include(/usr/www/users/baslerd/Droplimits/system/modules/table_from_csv/elements/ContentCsvTable.php)
 [function.include]: failed to open stream: No such file or directory in system/modules/core/library/Contao/ClassLoader.php on line 148

Ist eigentlich recht eindeutig: Die Datei ContentCsvTable.php kann nicht geladen werden.

Eigentlich sollte sie mit der mitgelieferten config/autoload.php gefunden werden. Deine Verzeichnisstrukturen sind auch so, wie es dort vermerkt ist.

Könntest Du mal folgendes probieren

(1) Entwickler-Tools -> Autoload-Creator

table_from_csv ankreuzen
Bestehende Dateien überschreiben ankreuzen
Autoload-Dateiei erstellen klicken

das sollte eigentlich genau die gelieferte config/autoload.php neu erzeugen.

(2) in Deinem FTP Tool die Dateirechte prüfen. Sind die so, daß PHP die Dateien lesen darf?

Beide Punkte müssten nach meinem Verständnis eigentlich bereits erfüllt sein, sonst dürftest Du im Backend auch nichts zu sehen bekommen.

Bin hier momentan etwas ratlos ...

[fiedsch]

Genau so ein Modul habe ich ebenfalls schon länger online: [chesstable]. Und dort hakt es genauso wie beim Tabellen- und beim Aufzählungselement. Ich trage die CSV-Daten in ein Textfeld ein (Typ mediumtext), schicke es ab und bei zu vielen Daten wird es einfach abgeschnitten. Dabei sollen ja angeblich 16,7 Mill. Bytes in mediumtext reinpassen. CSV-Daten mit z.b. 500 Zeilen und meinetwegen 80 Zeichen je Zeile werden dann einfach gekürzt. Klicke ich auf Speichern bleiben z.B. nur 300 Zeilen übrig.

Ich denke, der entscheidende Unterschied dürfte sein, daß bei meinem Entwurf (Erweiterung will ich das Ding noch nicht nennen, ist nur schnell druntergeschrieben) nicht die Daten per copy/paste übermittelt werden sondern die hochgeladenen Datei ausgewählt wird. Dabei brauchst Du erst mal keine besonderen Anforderungen an das Backend-Formular wie max_input_vars etc. Das einzige, was irgendwann beschränken wird ist wie überall das memory_limit. Wenn die angegebenen Datei eingelesen und gepasst wird muss sie in den Arbeitsspeicher passen und da ist irgendwann Schluss. Für normale Anwendungsfälle sollte es aber reichen.

Wenn Du etwas Zeit hast kannst Du es Dir vielleicht mal kurz anschauen und wir kommen dabei dem Problem in #36 auf die Spur, wo ich momentan keine Idee habe, wo es hakt.

[eisenherz]

Ich habe mir gerade noch einmal Dein root-Bild angeschaut.
Abgesehen davon, dass es keine gute Idee ist den root-Pfad contao zu nennen, sieht das aber ausgesprochen eigenartig aus und eine .htaccess sehe ich im root auch nicht.
Unabhängig von den derzeitigen Problemen empfehle ich einen Contao-Check mit Überprüfung der derzeitigen Installation.

Alles gut!Aber danke für die Tipps
bei dem Beispiel ginge mir nur um irgendein root Verzeichnis (Hier zu www.droplimits.de,das Bild hatte ich noch) ContaoCheck hatte ich schon gemacht, auch bei dem "wilden" root auf dem Bild, das übrigens seit Jahren recht stabil läuft.

[eisenherz]

PHP-Version kannst Du bei Hetzner übrigens in der Konsole unter Einstellungen -> Konfiguration -> PHP-Konfiguration einstellen

Danke.
Das sind Tipps mit denen ich wenigstens was anfangen kann.
Dort , in der Konsole , bei den PHP Einstellungen, stand übrigens auch schon der Hinweis, das ich mit einer uralten PHP Version arbeite

[eisenherz]

Hmm, kann das mit FastCGI zusammenhängen, dass php_value eventuell nicht funktioniert? Wäre dann allerdings stark vom Hetzner-Support, das so vorzuschlagen

Edit: Mal ganz abgesehen davon, dass PHP 5.3.29 und Contao 3.5.x eigentlich nicht zusammenpassen, du brauchst PHP 5.4.0 oder höher.

Ich habe die PHP Einstellung jetzt korrigiert ... vielleicht tut sich ja was ... mal ein paar Minuten abwarten.

Ich grinse innerlich immer noch über den Hinweis ... weil mich dieses Thema, gestreckt über Wochen und Monate jetzt schon viel mehr Stunden Aufmerksamkeit gekostet hat, als mir lieb ist.

Warum eine Nachtschicht? Mach' einfach das was dir der Support gesagt hat... füge diesen Code ... ein.

Klar wenn man alles richtig macht bzw. gemacht hat, könnte es so laufen ... nur wie oft läuft sowas reibungslos? Meist klemmt es irgendwo.
Mir ist klar, dass nicht alles idiotensicher programmiert werden kann, weil das System viel zu komplex ist. Idiotensicher geht nur wenn das System ganz einfach strukturiert wäre.

Ich will ja das komplexe System, um selber Ideen umsetzten zu können und nicht nur ein Schema "abklicken".

Ich freue mich allerdings meist mehr, wenn ich Tipps von ausgewiesenen Profis bekomme, die noch im Hinterkopf haben, dass es auch Menschen gibt die sich nicht semiprofessionell mit Contao beschäftigen und die eben nicht die gesamte Trickkiste parat haben, teilweise nichtmal ahnen das es passende "Stellschrauben" gibt.

Ohne einen Peter Müller, Bugbuster und viele andere von dem Kaliber hätte ich schon längst aufgegeben.

Nochmal danke für die geduldige Hilfe, die ich hier immer wieder bekommen habe.

[eisenherz]

Ist eigentlich recht eindeutig: Die Datei ContentCsvTable.php kann nicht geladen werden.

Eigentlich sollte sie mit der mitgelieferten config/autoload.php gefunden werden. Deine Verzeichnisstrukturen sind auch so, wie es dort vermerkt ist.

Könntest Du mal folgendes probieren

(1) Entwickler-Tools -> Autoload-Creator

table_from_csv ankreuzen
Bestehende Dateien überschreiben ankreuzen
Autoload-Dateiei erstellen klicken

das sollte eigentlich genau die gelieferte config/autoload.php neu erzeugen.

(2) in Deinem FTP Tool die Dateirechte prüfen. Sind die so, daß PHP die Dateien lesen darf?

Beide Punkte müssten nach meinem Verständnis eigentlich bereits erfüllt sein, sonst dürftest Du im Backend auch nichts zu sehen bekommen.

Bin hier momentan etwas ratlos ...

1 habe ich gemacht. Bei der Datenbankaktualisierung wurde das dann auch neu geschrieben.
2 habe ich nicht verstanden ... ist doch alles da, oder ... hab aber jetzt keine Zeit mehr das nochmal mit einem 3. FTP Programm zu testen. Mit Forklift und Cyberduck habe ich es schon probiert

Fehlermeldung sieht jetzt so aus

Warning: include(/usr/www/users/baslerd/Droplimits/system/modules/table_from_csv/elements/ContentCsvTable.php): failed to open stream: No such file or directory in system/modules/core/library/Contao/ClassLoader.php on line 148
#0 system/modules/core/library/Contao/ClassLoader.php(148): __error(2, 'include(/usr/ww...', '/usr/www/users/...', 148, Array)
#1 system/modules/core/library/Contao/ClassLoader.php(148): Contao\ClassLoader::load()
#2 [internal function]: Contao\ClassLoader::load('ContentCsvTable')
#3 [internal function]: spl_autoload_call('ContentCsvTable')
#4 system/modules/core/library/Contao/Controller.php(461): class_exists('ContentCsvTable')
#5 system/cache/dca/tl_content.php(1155): Contao\Controller::getContentElement(Object(Contao\ContentModel))
#6 system/modules/core/drivers/DC_Table.php(4202): tl_content->addCteType(Array)
#7 system/modules/core/drivers/DC_Table.php(366): Contao\DC_Table->parentView()
#8 system/modules/core/classes/Backend.php(622): Contao\DC_Table->showAll()
#9 system/modules/core/controllers/BackendMain.php(126): Contao\Backend->getBackendModule('article')
#10 contao/main.php(20): Contao\BackendMain->run()
#11 {main}

Warning: include(): Failed opening '/usr/www/users/baslerd/Droplimits/system/modules/table_from_csv/elements/ContentCsvTable.php' for inclusion (include_path='.:/usr/local/lib/php/') in system/modules/core/library/Contao/ClassLoader.php on line 148
#0 system/modules/core/library/Contao/ClassLoader.php(148): __error(2, 'include(): Fail...', '/usr/www/users/...', 148, Array)
#1 system/modules/core/library/Contao/ClassLoader.php(148): Contao\ClassLoader::load()
#2 [internal function]: Contao\ClassLoader::load('ContentCsvTable')
#3 [internal function]: spl_autoload_call('ContentCsvTable')
#4 system/modules/core/library/Contao/Controller.php(461): class_exists('ContentCsvTable')
#5 system/cache/dca/tl_content.php(1155): Contao\Controller::getContentElement(Object(Contao\ContentModel))
#6 system/modules/core/drivers/DC_Table.php(4202): tl_content->addCteType(Array)
#7 system/modules/core/drivers/DC_Table.php(366): Contao\DC_Table->parentView()
#8 system/modules/core/classes/Backend.php(622): Contao\DC_Table->showAll()
#9 system/modules/core/controllers/BackendMain.php(126): Contao\Backend->getBackendModule('article')
#10 contao/main.php(20): Contao\BackendMain->run()
#11 {main}

Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/baslerd/Droplimits/system/helper/functions.php:68) in system/modules/core/library/Contao/Template.php on line 255
#0 [internal function]: __error(2, 'Cannot modify h...', '/usr/www/users/...', 255, Array)
#1 system/modules/core/library/Contao/Template.php(255): header('Vary: User-Agen...', false)
#2 system/modules/core/classes/BackendTemplate.php(113): Contao\Template->output()
#3 system/modules/core/controllers/BackendMain.php(268): Contao\BackendTemplate->output()
#4 system/modules/core/controllers/BackendMain.php(130): Contao\BackendMain->output()
#5 contao/main.php(20): Contao\BackendMain->run()
#6 {main}

Warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/baslerd/Droplimits/system/helper/functions.php:68) in system/modules/core/library/Contao/Template.php on line 256
#0 [internal function]: __error(2, 'Cannot modify h...', '/usr/www/users/...', 256, Array)
#1 system/modules/core/library/Contao/Template.php(256): header('Content-Type: t...')
#2 system/modules/core/classes/BackendTemplate.php(113): Contao\Template->output()
#3 system/modules/core/controllers/BackendMain.php(268): Contao\BackendTemplate->output()
#4 system/modules/core/controllers/BackendMain.php(130): Contao\BackendMain->output()
#5 contao/main.php(20): Contao\BackendMain->run()
#6 {main} 

[Spooky]

Ich grinse innerlich immer noch über den Hinweis ... weil mich dieses Thema, gestreckt über Wochen und Monate jetzt schon viel mehr Stunden Aufmerksamkeit gekostet hat, als mir lieb ist.

vor einem Monat wurde dir schon gesagt, warum das Problem auftritt. Dass sich das Problem ungelöst nun schon über einen Monat streckt ist nur dir zu zu schreiben.

[fiedsch]

2 habe ich nicht verstanden ... ist doch alles da, oder ... hab aber jetzt keine Zeit mehr das nochmal mit einem 3. FTP Programm zu testen. Mit Forklift und Cyberduck habe ich es schon probiert

Die Frage war nicht, ob die Dateien "da sind" sondern ob der Server -- ganauer der Prozess der PHP letztlich ausführt -- sie auch lesen darf. Da ich Dein Setup nicht kenne, weiß ich nicht, wie das bei Dir aussehen müsste.

[eisenherz]

vor einem Monat wurde dir schon gesagt, warum das Problem auftritt. Dass sich das Problem ungelöst nun schon über einen Monat streckt ist nur dir zu zu schreiben.

Sowas dauert bei mir leider so lange, weil ich das eben nicht im Vorbeigehen erledigen kann und es mich dann eben doch Stunden kostet ... die habe ich in der (Fahrrad) Hochsaison nicht ... andererseits ist mein Anspruch aber so , dass ich die Website "vernünftig" haben will.
Ein "OverallRanking" nicht sauber abbilden zu können wurmt mich sehr ... kann aber nicht mal eben so ne Ausbildung zum Website Gestalter absolvieren. Das wird ein Spagat bleiben, der mal gut mal schlecht für mich ausgeht ... jetzt klemmt es gerade.
Ich hoffe du kannst das jetzt etwas besser nachvollziehen ... rollende Augen helfen mir da wenig.

[eisenherz]

Die Frage war nicht, ob die Dateien "da sind" sondern ob der Server -- ganauer der Prozess der PHP letztlich ausführt -- sie auch lesen darf. Da ich Dein Setup nicht kenne, weiß ich nicht, wie das bei Dir aussehen müsste.

Kann man das hier sehen?
PHP Konfiguration.jpg

[mlweb]

Sowas dauert bei mir leider so lange, weil ich das eben nicht im Vorbeigehen erledigen kann und es mich dann eben doch Stunden kostet ... die habe ich in der (Fahrrad) Hochsaison nicht ... andererseits ist mein Anspruch aber so , dass ich die Website "vernünftig" haben will.
Ein "OverallRanking" nicht sauber abbilden zu können wurmt mich sehr ... kann aber nicht mal eben so ne Ausbildung zum Website Gestalter absolvieren. Das wird ein Spagat bleiben, der mal gut mal schlecht für mich ausgeht ... jetzt klemmt es gerade.

Um das mal mit Deinem Fahrradladen zu vergleichen: Bei manchen Problemen gibst Du vielleicht Tips zur Reparatur eines Fahhrades. Wenn der Kunde Dir dann sagt, dass er gar keine Zeit hat sich richtig mit dem Problem auseinderzusetzen und sich beschwert, dass die Lösung Zeit kostet und sich vielleicht noch über ein Problem beschwert, welches Du gar nicht als Problem erkannt hast, weil es einfach für Dich eine Selbstverständlichkeit ist, bist Du wahrscheinlich leicht irritiert - auch wenn Verständnis dafür da ist das der unerfahrene Laie das nicht so einfach umsetzen kann wie Du.
Ich hoffe Du verstehtst meinen nächsten Hinweis nicht falsch. Auch wenn man viel am System selbst machen will, muss man nicht alles selbst machen. Für bestimmte Dinge die ins Eingemachte gehen, kann man sich auch einen Profi dazu nehmen. Bei einer vertrauensvollen Zusammenarbeit muss das auch nicht zwangsweise teuer sein, gerade weil Du ja in vielen Bereichen das System kennst. So etwas schont die Nerven, strapaziert die eigene Freizeit nicht über Gebühr und ist im Endeffekt vielleicht deutlich effektiver.

[mlweb]

Habe mir gerade noch einmal Deine phpinfo() angeschaut. PHP ist aktualisiert, die max_input_vars sind aber immer noch nicht gesetzt. Die Lösen Dein Problem mit ziemlicher Sicherheit.
Ich habe nämlich die Testumgebung bei Hetzner auch mit Deiner Tabelle gequält und konnte so wie von @spooky beschrieben den Fehler reproduzieren.
Wenn Du willst schick mir eine PN mit den Zugangsdaten (FTP) dann schau ich mal rein, warum das mit der .htaccess bei Dir nicht klappt.

[Spooky]

Ich habe nämlich die Testumgebung bei Hetzner auch mit Deiner Tabelle gequält und konnte so wie von @spooky beschrieben den Fehler reproduzieren.

Funktioniert bei deinem Hetzner Server das ändern von max_input_vars über php_value in der .htaccess?

[mlweb]

Funktioniert bei deinem Hetzner Server das ändern von max_input_vars über php_value in der .htaccess?

Ja klar, hatte ich gestern Nacht schon gestestet und weiter oben schon geschrieben - Hetzner Level 4 (ist bei Hetzner das kleinste Paket mit Datenbankanbindung).

[Spooky]

ah, hatte ich übersehen

[tab]

Irgendwas stimmt hier offenbar nicht! Der verlinkte Aufruf der pi.php zeigt zwar die ungeänderte Variable max_input_vars ... Aber, wenn man das Backend dieser Installation aufruft, dann steht da: "Contao Open Source CMS 3.4". Wie nun? 3.4 oder 3.5? Gibt es mehrere Installationen? Falls ja, wurde der Eintrag in der .htaccess auch in der richtigen Installation durchgeführt?

Edit: Ich sehe auch, dass phpinfo jetzt ein PHP 5.6.12 anzeigt in der verlinkten Contao 3.4 Installation. Wurde die neue PHP-Version auch in der eventuell vorhandenen 3.5 Installation ausgewählt?

[eisenherz]

Bei einer vertrauensvollen Zusammenarbeit muss das auch nicht zwangsweise teuer sein, gerade weil Du ja in vielen Bereichen das System kennst. So etwas schont die Nerven, strapaziert die eigene Freizeit nicht über Gebühr und ist im Endeffekt vielleicht deutlich effektiver.

Hallo!
Das ist kein Problem für mich. Da www.DropLimits.com aber ein reines Hobby ist, versuche ich soviel wie möglich selbst zu machen. Ich habe auch schon darüber nachgedacht den Nerven schonenderen Weg zu gehen ... darum hab ich mir ja auch die Rocksolid Vorlagen gekauft ... dann muss ich nicht immer ab Null schrauben.

Um auf den Vergleich zu Fahrrad zurück zu kommen. Die Kunden kaufen sich in der Regel ein Rad um damit zu fahren, nicht um daran zu schrauben ... ja,ja opensource ... ist mir alles klar. Mir ist nur (d)ein freundlicher Hinweis lieber als rollende Augen, das ist alles.

[Spooky]

Irgendwas stimmt hier offenbar nicht! Der verlinkte Aufruf der pi.php zeigt zwar die ungeänderte Variable max_input_vars ... Aber, wenn man das Backend dieser Installation aufruft, dann steht da: "Contao Open Source CMS 3.4". Wie nun? 3.4 oder 3.5? Gibt es mehrere Installationen? Falls ja, wurde der Eintrag in der .htaccess auch in der richtigen Installation durchgeführt?

Edit: Ich sehe auch, dass phpinfo jetzt ein PHP 5.6.12 anzeigt in der verlinkten Contao 3.4 Installation. Wurde die neue PHP-Version auch in der eventuell vorhandenen 3.5 Installation ausgewählt?

Ich glaube eisenherz hatte eine falsche Angabe zur verwendeten Contao Version gemacht. Ohne PHP 5.4 wäre er mit Contao 3.5 schon in ein paar andere Probleme gelaufen.

[mlweb]

Irgendwas stimmt hier offenbar nicht! Der verlinkte Aufruf der pi.php zeigt zwar die ungeänderte Variable max_input_vars ... Aber, wenn man das Backend dieser Installation aufruft, dann steht da: "Contao Open Source CMS 3.4". Wie nun? 3.4 oder 3.5?

Ja den Check hatte ich heute Nacht auch schon aufgerufen u.a. wegen dieser eigenwillige root-struktur (siehe oben), aber 7.9 ist doch auch kein aktueller Check. Der würde die 3.5.2 ja auch gar nicht erkennen. Deswegen ja auch diesbezüglich die Frage nach dem Check (s.o.) und das Angebot sich das mal anzuschauen warum die .htaccess nicht greift, ehe wir hier weiter Probleme suchen, die eigentlich gar nicht da sind.

Edit: Habe jetzt ne PN mit den Zugangsdaten und werde Euch berichten was ich rausfinden kann. Wird aber wahrscheinlich erst heute Abend.

[mlweb]

Ohne PHP 5.4 wäre er mit Contao 3.5 schon in ein paar andere Probleme gelaufen.

Stimmt, darüber das das gelaufen ist habe ich mich gestern auch schon gewundert.

[tab]

Der Check kann die Installation zwar nicht prüfen, zeigt aber eine Contao Version 3.4.5 an.

[tab]

Ich glaube eisenherz hatte eine falsche Angabe zur verwendeten Contao Version gemacht. Ohne PHP 5.4 wäre er mit Contao 3.5 schon in ein paar andere Probleme gelaufen.

Ja, das hatte ich auch schon gedacht. Andererseits war ich mir nicht ganz sicher, weil in den verlinkten Einstellungen die Fehlerausgabe deaktiviert war. Keine Ahnung wie sich das auswirkt und ob sich das dann noch anders bemerkbar machen würde, außer, dass vieles oder alles einfach nicht mehr gespeichert werden kann.

[fiedsch]

Kann man das hier sehen?
PHP Konfiguration.jpg

Nein, das zeigt die PHP Konfiguration im Hetzner Backend. Es geht um die hochgeladenen Dateien.

[eisenherz]

Irgendwas stimmt hier offenbar nicht! Der verlinkte Aufruf der pi.php zeigt zwar die ungeänderte Variable max_input_vars ... Aber, wenn man das Backend dieser Installation aufruft, dann steht da: "Contao Open Source CMS 3.4". Wie nun? 3.4 oder 3.5? Gibt es mehrere Installationen? Falls ja, wurde der Eintrag in der .htaccess auch in der richtigen Installation durchgeführt?

Edit: Ich sehe auch, dass phpinfo jetzt ein PHP 5.6.12 anzeigt in der verlinkten Contao 3.4 Installation. Wurde die neue PHP-Version auch in der eventuell vorhandenen 3.5 Installation ausgewählt?

Ja, ich habe einen Zahlendreher nicht bemerkt. Ich habe aus 3.4.5. bei mir im Kopf 3.5.4 gemacht ... und so hier geschrieben. Ich hoffe es kommen nicht noch mehr solche Faustpax zum Vorschein ... ich duck mich vorsorglich schon mal weg

[eisenherz]

Stimmt, darüber das das gelaufen ist habe ich mich gestern auch schon gewundert.

... und ich merk sowas nicht mal

[mlweb]

So nachdem ich den richtigen Zweig gefunden hatte, konnte ich auch die max_input_vars in der .htaccess einstellen. Das wird jetzt auch richtig in der phpinfo() angezeigt.
Wahrscheinlich hatte @eisenherz die .htaccess mit einem ungeeigneten Programm bearbeitet (am Mac?). Auf jeden Fall war diese Datei für mich (unter Windows) gar nicht lesbar.
Ich habe jetzt die .htaccess.default (Original aus dem core von Contao 3.4.5) hochgeladen und die angepasste .htaccess.

Edit: Und jetzt bin ich gespannt ob die Tabelle vollständig eingelesen wird.

[eisenherz]

So nachdem ich den richtigen Zweig gefunden hatte, konnte ich auch die max_input_vars in der .htaccess einstellen. Das wird jetzt auch richtig in der phpinfo() angezeigt.
Wahrscheinlich hatte @eisenherz die .htaccess mit einem ungeeigneten Programm bearbeitet (am Mac?). Auf jeden Fall war diese Datei für mich (unter Windows) gar nicht lesbar.
Ich habe jetzt die .htaccess.default (Original aus dem core von Contao 3.4.5) hochgeladen und die angepasste .htaccess.

Edit: Und jetzt bin ich gespannt ob die Tabelle vollständig eingelesen wird.

Hurra die Tabelle Overal Ranking funktioniert in voller Größe. Vielen Dank an @mlweb.
Ich hatte mit bbedit die .htaccess bearbeitet ... sind da Probleme bekannt?

Das was funktioniert sieht so aus

##
# Contao Open Source CMS
#
# Copyright (c) 2005-2015 Leo Feyer
#
# @license LGPL-3.0+
##

#Die folgende Einstellung wird zum Einlesen großer Tabellen benoetigt
## 04.09.2015 Maren Lange
php_value max_input_vars 5000

##
# Prevent access to the Contao template files 

Ich selber hatte es unten angehängt, aber auch schon ganz oben eingefügt, ohne Funktion. Die funktionierende Datei von mlweb ist 0,1kb größer !?

  ##
  # The following rules are required if you want to pass the language as first
  # URL parameter (added in Contao 2.11). The first rule rewrites the empty URL
  # to the front end controller, the second one adds a missing trailing slash.
  ##
  RewriteRule ^[a-z]{2}(\-[A-Z]{2})?/$ index.php [L]
  RewriteRule ^([a-z]{2}(\-[A-Z]{2})?)$ $1/ [R=301,L]

</IfModule>
php_value max_input_vars 5000 

[mlweb]

@fiedsch Habe gerade mal Deine kleine Erweiterung getestet. Da ist noch ein Fehler drin. Unter templates heißt Dein template cs_csvtable.html5 und nicht wie benötigt ce_csvtable.html5.
Wenn man das umbenennt klappt dann das Einlesen der "Problemtabelle" im Prinzip und zwar ohne max_input_vars zu erhöhen. Ein paar Probleme mit dem Zeichensatz habe ich hier bei mir auf dem lokalen Testserver unter Windows noch gesehen.

[fiedsch]

@fiedsch Habe gerade mal Deine kleine Erweiterung getestet. Da ist noch ein Fehler drin. Unter templates heißt Dein template cs_csvtable.html5 und nicht wie benötigt ce_csvtable.html5.

Danke! Soeben im Repo gefixt.

Ein paar Probleme mit dem Zeichensatz habe ich hier bei mir auf dem lokalen Testserver unter Windows noch gesehen.

Ich nehme mal an, daß liegt daran, daß mein Code einfach davon ausgeht, utf-8 kodierte Daten vorgsesetzt zu bekommen und Du unter Windows ein anderes Encoding hast.

[mlweb]

Ich habe mit bbedit die .htaccess bearbeitet.

Den Editor kenn ich nicht, aber ich glaube nicht, dass die Reihenfolge das Problem war. Du hattest die Anweisung gestern ja auch schon mal am Anfang.
Die von Dir auf dem Server abgespeicherte Datei hatte definitiv nicht das richtige Format/die richtige Kodierung und deshalb konnte Sie vom System nicht gelesen werden.

[fiedsch]

Die von Dir auf dem Server abgespeicherte Datei hatte definitiv nicht das richtige Format/die richtige Kodierung und deshalb konnte Sie vom System nicht gelesen werden.

Wenn der Apache eine .htaccess nicht lesen kann sollte man eigentlich einen 500 internal server error bekommen?

Wie hatte sich denn bei Deinem Bearbeitungsversuch das "nicht lesen können" geäußert?

Vielleicht waren ja "nur" die Zeilenenden (nur LF Unix) anders als unter Windows (CR+LF) erwartet?

Ist im Prinzip aber egal, jetzt klappt ja alles.

[tab]

Vielleicht waren ja "nur" die Zeilenenden (nur LF Unix) anders als unter Windows (CR+LF) erwartet?

Ist im Prinzip aber egal, jetzt klappt ja alles.

Ja, Hauptsache es funktioniert jetzt. An das CR+LF mag ich nicht glauben4. Jeder, der schon mal Dateien für Contao editiert hat, weiss ja, dass das mit den "normalen" Editoren nicht funktioniert. Ich nehme meistens Notepad++, das funktioniert ganz gut, während das "normale" Notepad die Datei zwar auch öffnen kann, sie aber schon mal falsch anzeigt und auch nicht als UTF8 ohne BOM abspeichert.

[mlweb]

Wie hatte sich denn bei Deinem Bearbeitungsversuch das "nicht lesen können" geäußert?

Vielleicht waren ja "nur" die Zeilenenden (nur LF Unix) anders als unter Windows (CR+LF) erwartet?

Das Zeilenende war es nicht. Schuld war die Dateibenennung. Am Ende des Dateinamens war ein Leerzeichen vorhanden. Das führte dazu, dass Windows und im übrigen übers Netzwerk auch der Mac gemeldet haben so eine Datei gibt es nicht, die kann ich nicht öffnen und auch nicht löschen, obwohl diese im Explorer, im SpeedCommander bzw. im Finder sichtbar war. Nach Umbennenung ist die Datei dann auch lesbar so wie sich das gehört.
Wußte bis jetzt auch nicht, dass sich ein Leerzeichen am Ende des Dateinamens so äußert.
Na ja, kleiner Fehler große Wirkung.