Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenich nutz cachify und einiges an htaccess Einträgen dazu ...
Bei Deinen beiden Seiten beantworten ja auch der/die Server die erste Anfrage in unter 0,5 Sekunden, was wohl damit zusammenhängt. Bei seiner Seite kam die erste Response gestern aber erst nach Sekunden hier an und heute auch in unter 0,5 Sekunden. Würde mich deshalb schon interessieren, ob er ähnliche Schritte unternommen hat und wenn ja, welche oder ob sein Server gestern nur Waschtag hatte.
Der Server reagiert heute wesentlich schneller als gestern, hast Du etwas verändert oder hatte der gestern nur einen Trödeltag?
Zu deinem JavaScript Problem steht bei Google folgendes:
Es nutzt nur nichts, irgendetwas zusammenfassen und erst nach onload nachladen zu wollen, so lange jedes kleine Plugin dennoch mit einer Funktion ähnlich der nachfolgenden daherkommt. Die Plugins würden ihre Dateien halt zusätzlich noch über oder unter der von Google vorgeschlagene Lösung einfügen.
add_action("wp_head", "binde_css_oder_js_datei_in_den_head_ein");
Da ich es aber nicht ausprobiert habe, lasse ich mich gern eines Besseren belehren, wenn es denn vernünftig getestet wurde.
Doch die Lösung von Google ist gut, wenn Du die JS-Dateien eigenständig in einem Editor im Head, Body oder Footer einer Seite notieren würdest und diese Aufgabe nicht länger den Plugins überlässt. Dass eine oder andere Plugin könnte jedoch verschnupft darauf reagieren, wenn eine Funktion noch nicht bei Aufruf der Funktion zur Verfügung steht.
Und diese AllowOverride Einstellungen vom Server bestimmen ja mit darüber, was per htaccess erlaubt wird und was nicht.
Ist schon einige Jahre her, denke das war 2004 bis 2006 so, da konnte man zwar bei einigen Strato-Paketen eine htaccess anlegen, jedoch keine Weiterleitung per htaccess. Jeder Versuch führte zu einer Endlosschleife.
Falls keine Subdomain eingerichtet ist oder eine Weiterleitung nicht möglich, weil die Subdomain immer wieder auf die Domain verweist oder ...
Sollte sich leichter mit Aufrufen wie "http://www.example.com/liesmich.html" testen lassen.
Fällt mir auch gerade noch ein, handelt es sich um einen Apache?
Füge doch die Zeilen einfach mal ein, dann wirst Du doch sehen was passiert, schlimmer kann es doch wohl nicht mehr werden. Cache löschen ist wichtig zwischen den Tests.
Und rufe nicht WP auf, sondern eine einfache, vorhandene Seite, wie die liesmich.html, weil die nicht über WP-Rules läuft.
Wer erzeugt diese Schleife, WP oder der Server?
Weil Du die internen Rules und Verweise nicht angepasst hast?
Falls WP, dann solltest Du schon eine der Varianten testen, wie in den FAQ beschrieben.
Falls der Server, könnte es sein, dass Du auf einer anderen Ebene noch gegensätzliche Einstellungen definiert hast?
Wenn
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]dann sollte auch die Seite ohne www nicht mehr erreichbar sein, es sei denn eine Weiterleitung per htaccess greift nicht. Wenn die dann gar nicht mehr erreichbar ist, kannst Du WP entsprechend anpassen, nachdem Du die Zeilen wieder auskommentiert hast und zwischen zwei Tests jeweils den Cache löschst.
Ich glaube irgentwo ist noch eine Weiterleitung aktiv, denn ohne den Präfix www. funktioniert alles bestens.
Wäre nicht mehr erreichbar, wenn Du eine Standard-Domain definieren würdest, bzw. bei Eingabe ohne www würde eine Weiterleitung auf mit www erfolgen.
Lesen: http://faq.wpde.org/wordpress-url-aendern/
Zusätzlich ändern:
Apache Configuration# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC] RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301] RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress
Im Übrigen, mysql_ gilt ab PHP 5.5 als veraltet, nur wird darauf bei php.net in der deutschen Version noch nicht hingewiesen. Somit ist es fraglich, ob mysql wirklich in einer späteren Version entfernt wird. Ich denke eher nicht, weil dann das Internet zusammenbrechen würde, täglich kommen ja noch neue Seiten hinzu, welche die veraltete mysql API nutzen.
Habe ja schon einiges gesehen und wenn es sich nur um kleinere Fehler handelte, nicht extra darauf hingewiesen, weil es kaum fehlerfreie Seiten gibt, doch wenn ich so etwas im Quelltext sehe,
<div class="pie-gallery alignGalleryLeft"; z-index: 10>
<div class="pie-item" style="margin: 5px 10px 5px 10px;", z-index: 10>
na dann möchte ich zumindest die Benutzung eines Validators mal empfehlen. Lade mal Deine Seite im Validator http://validator.w3.org/ und beseitige die 14 Errors, 4 warning(s) und wenn das erledigt ist, wird es möglicherweise bereits ohne weitere Schritte mit dem Seitenaufbau funktionieren. Falls nicht, kann man dann immer noch weiter suchen.
Doch vielleicht kannst Du ja zwischendurch schon einmal erklären, wofür bitte wurde der Z-Index auf 10 gesetzt und dann noch außerhalb von CSS notiert, wenn nichts überlappen soll?
Das erste Script kannst Du Dir eventuell komplett sparen, wenn Du auf die von WP zur Verfügung gestellten Funktionen und Methoden zurückgreifst.
global $wpdb;
$tabelle = $wpdb->prefix."name_der-tabelle";Suche mal nach $wpdb und da solltest Du dann weitere Beispiele finden:
Was meinst du mit Editor? Die Inhalte wurden direkt über das WP-Backend eingefügt...
Weniger die Artikel oder Beiträge, doch zum Beispiel einzelne Dateien oder ein Plugin, welches nach dem Download auf dem eigenen Computer entpackt und eventuell bearbeitet wurde, um es dann per FTP hochzuladen. Solange keine Umlaute enthalten sind, auch nicht in den Kommentaren, spielt es keine Rolle. Sind jedoch Umlaute enthalten und sei es nur in den Kommentaren, so ist darauf zu achten, dass diese Dateien mit UTF-8 ohne BOM abgespeichert werden.
nur die posttitle liegen kodiert in der datenbank.
Jetzt muss ich mal fragen, welcher posttitle?
Wenn ich mir meine letzte Sicherung betrachte oder die Datenbank per phpMyAdmin aufrufe, so habe ich da den Inhalt der Tabelle (Präfix)_posts, in der das Feld post_title enthalten ist, wobei der Inhalt von post_title jedoch nicht kodiert dargestellt wird.
Ich sehe Dein Banner vor <!-- END PARTNER PROGRAM --> und somit ist doch wohl beinahe alles richtig?
Falls nicht, dann Tee trinken, Cache löschen, Tee trinken und dann sollte es zu sehe sein.
Mir ist noch eingefallen, ich hatte das nur mit einem Einzeiler getestet, da ein Kommentar aber länger ist, es könnte sein, dass außer dem i hinter / noch ein s als Modifier benötigt wird. Schreibe da mal lieber ]/is" am Ende des Musters.
Dass Du von diese Datei vorher eine Kopie beiseite legst, die Du notfalls gleich wieder per FTP hochschieben kannst, wirst Du wohl nicht vergessen.
Die Tipps waren eigentlich als praktische Tipps gedacht, dass Du mal einen Blick in die Datenbank riskierst, um zu sehen, wie die Umlaute dort abgespeichert werden. Auch mal nachschauen, was in der wp-config angegeben ist.
define('DB_CHARSET', 'utf8');Und der Frage nachzugehen, wurden einzelne Dateien, die Umlaute enthalten, mit einem Editor bearbeitet aber nicht mit UTF-8 abgespeichert.
Die Seite enthält einige Zeichen, die scheinbar doppelt kodiert sind. So wird die Seite im FF mit UTF-8 und
<p>Die BeweidungÂ
ausgewertet und im IE mit Westeuropäisch und
<p>Die BeweidungÂÂ
Warum das so ist, keine Ahnung, da derartige Probleme auch mit der Datenbank oder mit anderen Einstellungen zusammenhängen können. Zum Beispiel wenn die Dateien mit einem Editor bearbeitet wurden, Umlaute enthalten, dann aber nicht mit UTF-8 gespeichert wurden. Die Angabe des Zeichensatzes im Head der Seite wird praktisch kaum bis nicht beachtet, weil der Browser sich vorher entscheidet, wie er eine Seite darstellt.
Falls es mit den Einstellungen der Datenbank zusammenhängt, so lassen sich diese Fehler oftmals nur schwerlich finden. Du könntest dennoch einmal kontrollieren, ob die Umlaute in der Datenbank richtig angezeigt werden.
Echt niemand eine Idee?
Du hast doch die Ideen. Alles was Du nun noch tun müsstest, Dich mit dem Quelltext diese Seiten auseinandersetzen und deren CSS und JavaScripts näher zu betrachten.
Doch aber die hatte ich mobil hochgeladen über die App
Mit den Ladezeiten ist es ähnlich wie bei anderen Dingen, zuerst kommt die Einsparung. Einsparung, sowohl was die zu ladenden Kilobytes anbelangt, als auch was die Anzahl der Request anbelangt. Wenn Du einen Blick in den anderen Thread wirfst, da hatte Gerd-E den Begriff Sprites erwähnt, womit CSS Sprites gemeint ist und wodurch sich bei kleineren Grafiken die Anzahl der erforderlichen Anfragen an den Server verringern lässt.
Wo sich die Anzahl der Anfragen nicht verringern lässt, sollte nach Möglichkeiten gesucht werden, einen Teil der Dateien erst dann zu laden, wenn diese wirklich benötigt werden und somit wenn die Seite vollständig geladen ist bzw. wenn der Dokumentenbaum fertig aufgebaut ist.
Nur etwas Bestehendes verändern zu wollen, traue ich mir oft kaum zu. Wer schreibt die Dateien in den Head? Sicherlich mal dieses und mal jenes Plugin und bei einfachen Veränderungen könnte es sein, dass diese Plugins nicht mehr ihre Arbeit verrichten. Ich denke, dass müsste dann mit jedem Plugin einzeln getestet werden.
Der Server scheint von sich aus bereits nicht der schnellste zu sein, schrieb ich schon.
Ah das ist aber nicht im Slider das Bild. Sondern ein Beitrags Bild.
Ja, gut, sah ich auch gerade, nicht das einzige und die werden genau aus welchem Grund in der Größe geladen? Um die Ladezeiten zu verlängern? Oder würde es nicht genügen in den Artikeln zwei Nummern kleiner einzubinden und nur auf eine größere Ausführung zu verlinken?
