Erst Sicherheitsabfrage, dann RequestURI too large, dann geht gar nichts mehr

[FONT=verdana]- Adresse zum Blog: true-crime.info und schwarze-lilie.net

- WordPress-Version: 3.5.2? (glaub ich, kann grade nicht nachschauen. Jedenfalls die aktuellste)

- Verwendetes Theme, verwendete Plugins: Suffusion, Tablepress, wp Kalender, Encyclopedia Pro, Tiny MCE advanced, mehr fällt mir jetzt auf Anhieb nicht ein.

- Zuletzt gemachte Änderungen: Keine ausser Artikel zu ändern und zu aktualisieren (zumindest den Versuch unternommen)

- (falls vorhanden) Fehlermeldungen:

Zunächst mal: Mein Provider war so nett, meine Websites auf php 5.2 zurückzusetzen und das ging ein paar Tage soweit ganz gut. Aber jetzt gehts wieder los, seit dem Upgrade auf WP 3.5.2 (glaube ich). Beim Versuch, einen Artikel zu speichern (egal ob neu erstellt, Entwurf oder Aktualisierung eines vorhandenen Artikels), habe ich folgende Probleme:

Entweder

1. kommt die WP-Sicherheitsabfrage "Bist Du sicher, dass Du das tun möchtest?" oder
2. die Fehlermeldung "RequestURI too large" (sorry, die sind auch nicht länger als früher und da klappte es ja) oder (Supergau)
3. meine IP wird auf dem Host-Server gesperrt. Das Error-Log sagt folgendes:
[/FONT]
[FONT=verdana][Tue Jul 16 22:22:17 2013] [error] [client 217.248.94.34] ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '217.248.94.34', file '/home/ajrrgraj/schwarze-lilie.net/arthoria-blog/wp-admin/admin.php', line 109), referer: http://schwarze-lilie.net/arthoria-blog/…=edit&message=1
[/FONT]
[FONT=verdana]Memory hab ich 128, was eigentlich mehr als genug ist.

Und ja, ich hab schon sämtliche Plugins deaktiviert, einige sogar ganz entfernt. Alles ohne Erfolg.

Ich krieg hier echt bald nen Schreikrampf.

Gibt's hier irgendjemanden mit ner echten Lösung? Bin auch gerne bereit, der- oder demjenigen nen Zugang einzurichten (sobald ich wieder auf meine Seite(n) zugreifen kann), damit sie oder er sich das Chaos mal vor Ort zu Gemüte führen kann.

Danke schon mal und Grüße,

Nina
[/FONT]
P.S. Und irgendwie habe ich hier im Forum ne eindeutig erkennbare Suchfunktion gesucht.

Erst Mal: Wow, danke für die Tipps. Dummerweise kann ich noch immer nicht auf die Websites zugreifen dank der IP-Sperre. FP funktioniert, außerdem hat mein Provider seinen Kunden die Möglichkeit eingeräumt, einige Einstellungen selbst zu ändern, z.B. php-Version, shorttag und ähnliches.
Gibt es denn eine Möglichkeit, das "zu Fuß" zu erledigen? Und wenn ja, wie? Da ich zwar php-files nach exakter Anleitung editieren kann, ansonsten aber keinen blassen Dunst davon habe, wäre es echt lieb, wenn man mir das hier detailliert aufdröseln würde. ;-)

Danke schon mal. :-)

Zitat von r23

Prima - dann verwende eine aktuelle PHP Version: http://www.php.net und verwende keine shorttag. Was darfst du noch ändern?

So, hier mal ne Liste der Einstellungen, die ich über den Kundenbereich meines Providers verändern kann und die Werte, die eingtragen sind:

[TABLE="class: grid-table tGrid1 pad body-only rounded mb"]

[tr]

[TD="class: dark strong"]Verfügbar[/TD]
[TD="class: igc"]Aktuelle Einstellung[/TD]
[TD="class: igc"]kann geändert werden[/TD]

[/tr][tr]

[TD="class: dark strong"]Zeichensatz: STD: UTF-8
[/TD]
[TD="class: igc"] UTF-8 => Globaler Zeichensatz [/TD]
[TD="class: igc"]ja, in alle möglichen
[/TD]

[/tr][tr]

[TD="class: dark strong"] PHP Schnittstelle: STD: Safe Mode: on[/TD]
[TD="class: igc"]PHP-CGI mit Wrapper (Safe Mode off)
[/TD]
[TD="class: igc"]ja, in Webserver PHP Modul (Safe-Mode: on)
[/TD]

[/tr][tr]

[TD="class: dark strong"] PHP Version: STD: Version: 5.3[/TD]
[TD="class: igc"]5.5 (hab ich grad geändert)
[/TD]
[TD="class: igc"]ja, in off, bzw. Versionen von 5.2 bis 5.5
[/TD]

[/tr][tr]

[TD="class: dark strong"] PHP Shorttag: STD: Nein[/TD]
[TD="class: igc"]nein (hab ich auch grade geändert)
[/TD]
[TD="class: igc"]ja, in Shorttag nein
[/TD]

[/tr][tr]

[TD="class: dark strong"] PHP Globale Variablen: STD: Nein[/TD]
[TD="class: igc"]nein
[/TD]
[TD="class: igc"]ja, in "ja"
[/TD]

[/tr][tr]

[TD="class: dark strong"] PHP Eval Anweisung: STD: Ja[/TD]
[TD="class: igc"]ja
[/TD]
[TD="class: igc"]ja, in "nein"
[/TD]

[/tr][tr]

[TD="class: dark strong"] PHP URL Include: STD: Nein[/TD]
[TD="class: igc"]nein
[/TD]
[TD="class: igc"]ja, in "ja"
[/TD]

[/tr][tr]

[TD="class: dark strong"] PHP Quotes-GPC: STD: Ja[/TD]
[TD="class: igc"]ja
[/TD]
[TD="class: igc"]ja, in "nein"
[/TD]

[/tr][tr]

[TD="class: dark strong"] PHP Session encrypt: STD: Ja[/TD]
[TD="class: igc"]ja
[/TD]
[TD="class: igc"]ja, in "nein"
[/TD]

[/tr][tr]

[TD="class: dark strong"] Zend Optimizer: STD: Nein[/TD]
[TD="class: igc"]nein
[/TD]
[TD="class: igc"]ja, in "ja"
[/TD]

[/tr][tr]

[TD="class: dark strong"] ionCube Loader: STD: Nein[/TD]
[TD="class: igc"]ja
[/TD]
[TD="class: igc"]ja, in "nein"
[/TD]

[/tr][tr]

[TD="class: dark strong"] CGI Schnittstelle: STD: CGI ausgeschaltet[/TD]
[TD="class: igc"]CGI mit Wrapper
[/TD]
[TD="class: igc"]ja, in CGI ausgeschaltet, CGI mit Wrapper, CGI ohne Wrapper
[/TD]

[/tr][tr]

[TD="class: dark strong"] Verzeichnis auflisten: STD: Verzeichnisse nicht auflisten[/TD]
[TD="class: igc"]Verzeichnisse nicht auflisten
[/TD]
[TD="class: igc"]ja, in Verzeichnisse auflisten
[/TD]

[/tr][tr]

[TD="class: dark strong"] Emails empfangen: STD: Ja, Emails empfangen[/TD]
[TD="class: igc"]Ja, Emails empfangen
[/TD]
[TD="class: igc"]ja, in "nein, Emails inaktiv"
[/TD]

[/tr]

[/TABLE]

Das wäre dann mal die aktuelle Übersicht. Bin auch grade in Kontakt mit meinem Provider, damit er mir meine IP wieder aktiviert und kann dann auf die Websites und somit auch das Dashboard zugreifen.

Meldung meines Providers:
[COLOR=black]
Memory limit 128, nicht veränderbar
suhosin.request.max_vars ist derzeit bei 64000
post ebenfalls [/COLOR]

Ich hab jetzt alles auf Standard-Werte zurückgesetzt, incl. PHP von 5.5 auf STD: 5.3 gesetzt. Eval von ja auf nein, ionCube auf nein, CGI-Schnittstelle ausgeschaltet.
Zugriff auf Dashboard hab ich wieder, hab dabei folgendes entdeckt:
WP-System Health hängt sich bei der Test-Suite auf. Er testet und testet und testet und wenn er nicht gestorben ist, dann testet er noch übermorgen.

Meine Plugins:

[TABLE="class: wp-list-table widefat plugins"]
[TR="class: active"]
[TD="class: plugin-title"]Akismet
[/TD]
[/TR]
[TR="class: active"]
[TD="class: plugin-title"]Duplicate Post
[/TD]
[/TR]
[TR="class: active"]
[TD="class: plugin-title"]Encyclopedia Pro
[/TD]
[/TR]
[TR="class: active"]
[TD="class: plugin-title"]Shortcodes Ultimate
[/TD]
[/TR]
[TR="class: active"]
[TD="class: plugin-title"]Table of Contents Plus
[/TD]
[/TR]
[TR="class: active"]
[TD="class: plugin-title"]TablePress
[/TD]
[/TR]
[TR="class: active"]
[TD="class: plugin-title"]TinyMCE Advanced
[/TD]
[/TR]
[TR="class: active"]
[TD="class: plugin-title"]WP-Polls
[/TD]
[/TR]
[TR="class: active"]
[TD="class: plugin-title"]WP Calendar
[/TD]
[/TR]
[TR="class: active"]
[TD="class: plugin-title"]WP Post Sorting
[/TD]
[/TR]
[TR="class: active"]
[TD="class: plugin-title"]WP Sanitize
[/TD]
[/TR]
[TR="class: active"]
[TD="class: plugin-title"]WP System Health
[/TD]
[/TR]
[TR="class: active"]
[TD="class: plugin-title"]WP YouTube Lyte
[/TD]
[/TR]
[/TABLE]

Da ist meines Erachtens nichts dabei, was jetzt furchtbar viel Speicher frisst. Und eines hab ich auch grade festgestellt: wenn ich auf dem Host Eval deaktiviere, krieg ich im AP ne weisse Seite, wenn ich mir meine installierten Plugins anzeigen lassen möchte. Ergo: Eval wieder akiviert, Plugins werden angezeigt.

Zitat von r23

Wenn das Problem noch besteht

ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value .... file '/srv/httpd/vhosts/http://www.domain.de [Mehr Informationen] /htdocs/wp-admin/admin.php', line 109)

Zitat
http://www.laub-home.de/wiki/PHP_Suhosin_Speicherprobleme

zum xten mal
Abhilfe:
Hier hilft es den default Suhosin Wert suhosin.memory_limit von 0 auf einen entsprechenden Wert zu setzen (http://http://www.hardened-php.net/suhosin/configuration.html#suhosin.memory_limit) - dieser kann auch geringer als das PHP memory_limit Wert sein. Anscheinend ist hier im Suhosin ein fester 64M Wert vorgegeben, welcher hier Probleme macht. /etc/php5/conf.d/suhosin.ini

1. Surprise, surprise, ich kann lesen. Was aber nichts dran ändert, denn
2. der Link bringt mir nen Seitenladefehler, auch wenn ich das erste http:// weglasse, was uns zum nächsten Punkt führt:
3. WO??? soll/ kann ich den ändern? config.php? Oder im Dashboard oder was? WHERE? OU? DONDE?

Hab übrigens grade versucht, die aktuelle WP-Ausgabe brandfrisch auf einer unbenutzten Domain zu installieren und krieg nur White Pages. Was mich zu einer globalen Frage bringt: Was ist aus dem guten alten "Never change a running system" geworden?

Es ist einfach... traurig.

Man stelle sich vor, man hätte es nicht mit einem AOL-User zu tun, der sich auf einer "Blogs für alle zum Billigpreis mit eigener Subdomain" ergiesst, sondern mit jemandem - nennen wir ihn Flummi, weil er auf der Suche nach kompetenter Hilfe von hier nach dort springt -, der ein klein wenig Ahnung von html hat, der über einen simplen Text-Editor verfügt, auf dem er nicht nur seinen Einkaufszettel verfasst, sondern tatsächlich tags benutzt. Flummi benutzt darüber hinaus einen Web-Editor, mit dessen Hilfe er sowohl die wysiwyg- Ansicht überprüfen als auch in der Code-Ansicht diverse Änderungen vornehmen kann (z.B. beim Versuch, die config-sample.php durch die Eingabe diverser Daten in eine config.php verwandeln, mit dem Effekt, dass sich die aktuellste WP-Version dann trotzdem nicht installieren lässt, obwohl drei andere Versionen im Vorfeld supersimpel installiert wurden und bis zu einem bestimmten Upgrade auch ohne Probleme dort liefen). Man stelle sich darüber hinaus vor, Flummi würde bereits seit etwas über einer Dekade eigene Domains bei einem Provider betreiben und hätte dort über ein FTP-Programm wie File-Zilla etliche Systeme wie z.B. SMF-Boards, Media-Wikis und auch WP-Blogs sowie selbt erstellte html-Seiten auf den Shared-Server installiert und zum Laufen gebracht. Warum nen Shared-Server, mag man sich fragen. Weil Flummi einfach keinen eigenen Server braucht. Letztendlich will Flummi ja nicht selbst programmieren, herumdoktern und basteln, sondern schlicht und ergreifend diverse Seiten mit Inhalten füllen. Und dann passiert, was nicht passieren sollte: Es gibt technische Probleme, die das Wissen von Flummi übersteigen. Also sucht er Hilfe. Er stellt seine Frage in möglichst leicht verständlicher Form und hofft, dass er auch eine Antwort in möglichst leicht verständlicher Form erhält. Stattdessen erhält Flummi seine Antworten in ihm unbegreiflichem Fachchinesisch und wird zu diversen externen Webseiten gejagt, auf denen wiederum nur fachchinesisch gesprochen wird. Schließlich findet Flummi eine Seite, auf der ihm leicht verständlich klargemacht wird, wie er sein Problem lösen kann.

Aber nicht hier... hier hält (und behandelt) man Flummi für (wie) einen der Millionen Internet-User, die von Tuten und Blasen keine Ahnung haben und sich auf Blogs für alle zum Billigpreis mit eigener Subdomain ergiessen will.

Seis drum. Flummi weiss, was er ist und kann und sucht sich Hilfe bei Leuten, die ihn respektieren.