extreme verlangsamung von up- und downloads & mysql Fehlermeldung

Zitat von wvs

Ach so. Es gibt demnach eine Umwandlungstabelle - aber die ist unvollständig.

Die Liste ist nicht unvollständig, die Liste war nur vor Version 3.6 etwas unvollständig, da bis dahin Umlaute nur in a, o, u nicht aber ae, oe, ue umgewandelt wurden. Die restlichen Zeichen, die nichts in einem Dateinamen verloren haben, wurden auch in den Versionen davor bereits entfernt, wobei das aber nur Klammern und Satzzeichen betrifft. Da kann ja jeder selbst etwas drauf achten, dass er in Datei- und Verzeichnisnamen keine Glyphen und ähnliches aufnimmt.

Ob es nun daran liegt oder noch andere Fehler gibt, spielt ja eigentlich keine Rolle, doch die einfachsten Fehler sollten zumindest erst einmal beseitigt werden, bevor man nach weiteren Fehlern sucht. Im Augenblick kommt ein 500er Serverfehler, so das wohl noch mehr im Argen liegt.

Nun habe ich endlich mal eine verständliche Erklärung gefunden:

Zitat

Aus diesem Grund ist es immer noch sinnvoll, nur auf Zeichen aus dem ASCII-Vorrat zurückzugreifen.

http://de.wikipedia.org/wiki/URL-Encoding

Da aber der ASCII nur aus Zeichen besteht, welche auf einer englischen Schreibmaschinentastatur zu finden ist, erfolgt bei Umlauten eine Umwandlung. Nun gibt es zwar bereits Umlautdomains und was weiß ich, doch alles hat halt irgendwo seine Grenzen. Auf Zeichen, die nicht auf einer Tastatur zu finden sind, würde ich zumindest immer noch in einer URL verzichten. Und eine URL besteht nicht nur aus der Domain bzw. dem Namen des Hosts, sondern auch aus dem Pfad, welcher sich aus Verzeichnis- und Datenamen zusammensetzt.

Etwas anders verhält es sich bei einem QueryString, also der Teil, der hinter dem Fragezeichen beginnt. Da dieser für weitere Daten bestimmt ist, können diese entsprechend kodiert auch übergeben werden.

Ob es nun daran liegt oder nicht, das ist eine andere Frage. Möglicherweise liegen ja auch ganz andere Probleme mit Server oder mit der Datenbank oder der Verbindung zur Datenbank vor. Doch wer sich etwas an den erlaubten Zeichen in einer URL hält, schließt von vornherein mögliche Probleme aus, die damit zusammenhängen könnten. Das dadurch aber gleich ein 500er Serverfehler ausgelöst wird, wie es gestern am späten Abend der Fall war, obwohl bis zur Vorwoche noch alles reibungslos geladen wurde, wie Du schreibst, kann ich mir auch schlecht vorstellen.

Hoster sind mitunter auch Angriffen ausgesetzt usw., wodurch es auch zu Ausfällen kommen kann.

Zitat von wvs

Also: In den Bezeichnungen für den Pfad sind bestimmt keine Sonderzeichen enthalten. Da schreibe ich nur ohne Umlaute und verwende höchstens "-" oder "_" ....

Du verwendest schon dieses No mit hochgestellten o im Pfad. Wenn Du Beitragsname auswählst, wird ja der Beitragsname zu einem Bestandteil des Pfades und der lässt sich halt unabhängig vom Titel korrigieren. Das Zeichen wird jetzt nur als Fragezeichen dargestellt:

U+2116 ? e2 84 96 NUMERO SIGN

Also, Deine Ressource ist unter diesem Namen mit diesem Sonderzeichen erreichbar.

Zitat

Url-path
Der Pfad beschreibt eine bestimmte Ressource (diese kann sich beispielsweise mit der Verzeichnisstruktur des Zielsystems decken, also etwa eine Datei oder ein Verzeichnis) auf dem Server.

http://de.wikipedia.org/wiki/Uniform_R…ocator#Url-path
Ob dafür eine Datei existiert oder nur ein Eintrag in der Datenbank, spielt erst einmal keine Rolle, da das dann nur über Rewrite-Regeln richtig ausgelöst wird.

Mir fallen spontan 2 Dinge ein:

ich würde zunächst einmal in der Datenbank via phpMyAdmin nachsehen, ob sich da mit Tabellen reparieren/ optimieren etwas ändert und ob sich an der Struktur bzw. Größe der Tabellen etwas Auffälliges getan hat (ich hatte z.B. einmal Tausende von Datensätzen eines deinstallierten Plugins in der wp_posts-Tabelle).

Dann würde ich versuchen, die PHP-Error-Logs zu inspizieren, ob sich da vielleicht etwas Sprechendes ergibt.

Grüße!

Nachdem zwischenzeitlich gar keine Datenbankverbindungen mehr möglich und auch mal alle Datenbanken gelöscht waren, bin nicht sicher ob der hoster etwas gebastelt hat, er hat grad Mittagspause und ich kann nicht nachfragen.
Was mir aber auffällt ist, dass im Dashboard die Widgets wie "Eingehende Links" "Plugins" "Weitere Wordpress News" etc. nicht laden. Es kommt lediglich die Anzeige "Wird geladen ... ". Vielelicht gibt es eine Störung in der Kommunikation zwischen der Installationen und dem Wordpress Server, der diese Daten bereitstellt. Wen kann man denn da wo fragen, ob sie so freundlich wären mal nachzuschauen? Betrifft bei mir übrigens Version 3.5.2 ebenso wie 3.6.

Ich werde jetzt erstmal versuchen per functions.php die Widgets zu deaktivieren- mal sehen ob ich dann weiter komme.

Danke euch für alle eure Antworten habe schon wieder was gelernt :)
Gruß Theolina

Update: Im Moment laufen alle 3 Installationen bei Knallhart.de einwandfrei.
Die Widgets habe ich nicht erntfernen können (vllt. Stresstomaten auf den Augen) ...

Wenn die Widgets allerdings permament Anfragen stellen und versuchen nie neuesten Inhalte zu bekommen, ist es nur eine Frage der Zeit, bis der Server wieder sagt "Tschuldigung, zuuu viele Anfragen."

Wie groß ist den Knallhart?
Wenn es sich um eine Attacke handeln sollte, so würde darüber auch kurzfristig in anderen Foren berichtet, falls es sich um einen etwas größeren Hoster handelt. Mir sagte dieser Name bis gestern zumindest noch nichts, so riesig bekannt kann er wohl nicht sein und im Web finde ich noch keine neuen Beiträge zu einem Problem betreffend Knallhart. Doch bei Theolina läuft alles wieder?

Eine Möglichkeit die DB auf Erreichbarkeit zu testen, einfach mal eine kleine testdatei.php im Rootverzeichnis ablegen, vorher Zugangsdaten eingeben und 123 durch die ID eines Posts ersetzen, dann die Datei aufrufen. Anschließend die Datei wieder löschen, da nur zum Test gedacht.

<?php


$mysqli = new mysqli("DB_HOST", "DB_USER", "DB_PASSWORD", "DB_NAME");


if ($mysqli->connect_errno) {
    printf("Connect failed: %s\n", $mysqli->connect_error);
    exit();
}
if ($result = $mysqli->query("SELECT * FROM wp_posts WHERE ID = 123")) {


    $row = $result->fetch_assoc();
    echo htmlspecialchars($row["post_title"],ENT_QUOTES)."<br><br>\n";
    echo htmlspecialchars($row["post_content"],ENT_QUOTES)."\n";
    $result->close();
}
$mysqli->close();


?>

Mit Knallhart hatte ich telefoniert und es gab wohl in der Tat einige Probleme, die nicht näher erläutert werden wollten. Auf meine Frage hin ob es denn irgendwie mit den Wordpress-Installationen zusammenhänge sagte man mir, das könne er mir nicht sagen, er bedanke sich aber für den Hinweis. Ich weiss, daß sie gerade urlaubs- und krankheitsbedingt nicht voll besetzt sind und habe entsprechend Geduld.
Wie gesagt bei mir lief - und seither tut es - alles wieder soweit ich sehen kann gut.

Dass die Dashboard-Widgets nicht geladen haben lag an einem Konflikt mit nextgenGallery, sobald das Plugin deinstalliert ist laden sie auch wieder.
Oha, da fällt mir ein, ich habs noch gar nicht dem Entwickler gemeldet ... sogleich einmal nachholen.

Wirklich schlauer bin ich nun nicht. :shock:

Auch von mir nochmal Danke an euch
Theolina

Zitat von wvs

Eine kurze Mitteilung auf der Eingangsseite würde schon reichen - ich bin sicher, daß die Nutzer Verständnis hätten und froh wären den Grund für Verzögerungen zu kennen.

Aber keine Neukunden, die würden nach dem nächsten Anbieter mit einer möglichst hundertprozentigen Erreichbarkeit suchen. Wenn Du mal bei knallhart unter Infos August 2011 nachschaust, da wird von einer Attacke berichtet. Wenn sie aber jedes Jahr derartige Mitteilungen veröffentlichen würden, wäre das rufschädigend.

*Off-topic-on*
Auch wenn es jetzt nicht ganz hier hin gehört, weil es ein WP-Forum ist: Ich bin seit 2001 bei Knallhart und habe in all den Jahren so gut wie nie irgendwelche Probleme mit der Erreichbarkeit gehabt. Sie sind sehr zuverlässig und hilfsbereit und ich muss nicht detailgenau wissen, was los ist - wenn mal was los ist. Tickets (ich betreue mehrere sehr unterschiedliche Projekte, da kommen schonmal Fragen auf) werden spätestens nach 2 Tagen beantwortet.
Ich bin sehr zufrieden.
*Off-topic-off*

Die Dashboard Widgets kann man wohl in der functions.php deaktivieren. Unter Optionen (rechts oben) können sie auf nicht sichtbar gestellt werden, sind dennoch noch "da" und laufen mit, soweit ich verstanden habe. Über die functions.php können sie ganz deaktiviert werden. Hatte bei meinem ersten Mal noch nicht funktioniert, kann aber durchuas an mir gelegen haben :)

Einen sonnigen Gruß
Theolina

Habe dies gefunden:

function remove_dashboard_widgets() {      global $wp_meta_boxes;      unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_quick_press']);     unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_incoming_links']);      unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_right_now']);     unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_plugins']);      unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_recent_drafts']);     unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_recent_comments']);      unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_primary']);     unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_secondary']);  }  if (!current_user_can('manage_options')) {     add_action('wp_dashboard_setup', 'remove_dashboard_widgets' ); }