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 erstellenUm nochmal sicherzugehen – dein Code sieht jetzt so aus, ja?
RewriteCond %{REQUEST_URI} ^/hiplounge(.*)$ [NC]
RewriteRule ^(.*)$ http://17hippies.de%1 [R=301,L]Hm, eigentlich sollte sogar eine Zeile reichen reichen:
RewriteRule ^/hiplounge(.*)$ http://17hippies.de$1 [L,R=301]Mein Code enthält an einer entscheidenden Stelle ein Prozentzeichen. Das hast du durch ein $ ersetzt.
Warum hast meinen Code nicht benutzt? Deiner kann nicht funktionieren; das habe ich dir schon erklärt. Gußeiserner Zaunpfahl: HOST vs. URI.
Dann passe ich den "nicht änderbaren Code (WP-Core)" meinen Vorstellungen/ Wünschen an und verzichte dann ggf. lieber auf Updates.
Also das wäre für mich die letzte Option. Falls du eine funktionierende Lösung findest, kannst du aber gerne einen Patch anbieten.
Anstatt meherer verschiedener Stylesheets möglichst alle zusammen in ein großes Stylesheet packen.
Ich habe einigermaßen stabile Codestandards für Stylesheets.
Eine Regel: Ein Stylesheet pro Ausgabemedium. Mobilbrowser bekommen die extrem optimierte Variante und müssen den Rest nicht laden. Print und Screen sind auch so unterschiedlich, daß es schneller geht, wenn das eine das andere nicht überschreiben muß.
Und wenn du deinen Server noch so konfigurierst, dass CSS Dateien auch durch den PHP Parser gejagt werden (oder alternativ alle Dateien in einem bestimmten Verzeichnis), dann kannst du sie (vorausgesetzt der anfordernde Browser unterstützt es - was die meisten aber ja tun) auch noch 'gzipt' ausliefern lassen:
Mache ich ohnehin. :) Dazu wollte ich auch mal was bloggen …
<?php if (strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== false) { header('Content-type: text/css'); ob_start("ob_gzhandler"); } ?> /* Deine ganz normale CSS-Datei ... */ <?php ob_end_flush(); ?>
[FONT="Courier New"]HTTP_ACCEPT_ENCODING[/FONT] mußt du nicht abfragen; das macht der ob_gzhandler sowieso.
Was du aber kontrollieren mußt: Läuft schon eine Kompression, und oder besteht die Verbindung zum Client noch per HTTP/1.0?
Außerdem solltest du einen Vary-Header setzen, denn das macht der Handler leider nicht zuverlässig.
In meiner HTTP-Klasse sieht das so aus:
private function compress()
{
if ( !is_null($this->compression)
and !zlib_get_coding_type()
and 'HTTP/1.1' == $_SERVER['SERVER_PROTOCOL']
)
{
ob_start( array ( 'ob_gzhandler', 9 ) );
header('Vary: Accept-Encoding');
// Sonst cacht der IE Win nicht.
$this->cache_control[] = 'private';
}
return;
}Weiterhin muß man dann die HTTP-Header genauer steuern; also beispielsweise den clientseitigen Cache gegen ETag oder Last-Modified validieren, sonst liefert man das Stylesheet bei jeder Anfrage neu aus, auch wenn der Empfänger es eigentlich schon hat.
Wenn man das nicht macht, verlangsamt das Komprimieren den Aufbau.
Und der IE 5.0 kann bei https keine komprimierten Stylesheets auspacken. Er behauptet aber, daß er es doch kann. Da ist dann leider Browsersniffing angesagt. :(
Zu den Snapshots: Sieh dich hier mal um: Implementations - websnapr - Website Thumbnails For Your Site – so ungefähr wird das funktionieren, wenngleich es auch von einem anderen Dienst kommen könnte. Google hilft.
Aber einer der Gründe, warum ich deine Sichtweise im Bezug auf die Permalinkstruktur nicht teile ist der, dass Hypertext Style: Cool URIs don't change.. Und genau das ist der Schwachpunkt an deinem System. Denn was machst du, wenn du einen "alten" Artikel aus 2008 in 2009 aktualisierst oder ergänzt?
Dann ist es immer noch ein Artikel aus dem Jahre 2008. Wenn ich das behandelte Thema inzwischen ganz anders betrachte, schreibe ich einen neuen Artikel. Ich schreibe keinen Artikel wieder und wieder um.
Auch deine Idee mit dem Slash (/) am Ende einer URL teile ich so nicht. Denn für mich impleziert das, dass ich nicht ein spezielles Dokument angefordert habe, sondern das Standarddokument des entsprechenden Verzeichnisses. Ich empfinde das als "irreführend".
Es geht dabei weniger um »Verzeichnisse« (so etwas gibt in einer URL nicht), sondern um URL-Butchering bei Anhängen. Das ist natürlich kein Dogma; hier kommt es im Wesentlichen darauf an, daß man konsistent bleibt.
Na ja, also ob ich jemals so viele Seiten zusammenkriege, dass das ein Problem wird, wage ich dann doch eher zu bezweifeln.
Das geht schneller, als du vermutest. Wenn die Performance eines Tages unter die Grenze des Zumutbaren rutscht – was machst du dann? Wirst du uncool?
Ich sehe das Problem auch aus der Sicht des Programmierers: Der nicht änderbare Code (WP-Core) ist suboptimal, also versuche ich daran vorbeizugehen. Und die Lösung sollte langfristig funktionieren.
Ich hätte hier halt gerne noch ein paar Tipps für das "Feintuning".
Viele Browser haben eine Maximalmenge der gleichzeitigen Verbindungen zu einem Server; meistens 8 oder 16. Da sie aber eine Subdomain als »anderen Server« betrachten, kannst du das Laden deiner Seite beschleunigen, indem du bestimmte Ressourcen (Skripte, Bilder) auf Subdomains legst. Ich bin gerade dabei, mein Theme entsprechend anzupassen und Bilder unter img.toscho.de abzulegen. Wenn du etwas besser machen willst als ich, dann sortiere gleich die Uploads in eine separate Subdomain.
Im Grunde bringt WordPress alles mit; du mußt es nur noch zusammenstecken:
Sieh dir die Widget-Funktion an, die WordPress mitbringt. Die sollte sich relativ leicht umschreiben lassen. Falls du noch etwas Geduld hast, warte auf Version 2.8, denn da ändert sich die API.
Desweiteren stellt sich natürlich auch noch die grundlegende Frage nach der Struktur der Permalinks.
Ich persönlich halte gar nichts davon, Meta-Daten wie bspw. das Datum in eine URL zu packen.
Meine Sicht auf dieses Thema: Die beste URL-Struktur. Ich möchte gerne wissen, wann ein Artikel geschrieben wurde. Wenn man das schon an der URL sieht, finde ich das sehr angenehm.
Nun stehe ich u.a. vor der Frage, ob ich meine Permalink Struktur bspw. nur mit /%postname% aufbaue, oder doch lieber mit /%category%/%postname% aufbaue?
Weder noch; beides wird die Performance deines Blogs gewaltig ausbremsen.
next_posts_link erzeugt kein Title-Attribut, sondern echten Text. Du mußt das Attribut also selber setzen.
Die Umleitung der Hauptadresse klappt nicht. Für example.com/ordner/ bleibt example.com/ordner/
Seltsam. Vergleichbares funktioniert bei mir problemlos.
example.com/ordner/seite/unterseite/ zu example.com/seite/unterseite/ funktioniert nur bei bestimmten Seiten.
Wie bestimmt? Wodurch unterscheiden sich diese Seiten von anderen?
Die Kategorien verhalten sich auch merkwürdig:
example.com/ordner/category/news wird zu example.com/news-archiv, also das /category/ fällt raus, und da es keine news-Seite gibt geht er zu /news-archiv/, denn die Seite gibt's.
Da greift WordPress’ interne Korrektur, die versucht, die passende Seite zu finden. Hat mit den Rewrite-Regeln nichts mehr zu tun.
Vielleicht postest du mal die reale Struktur der nicht korrekt umgeleiteten Seiten und deine komplette .htaccess. Ohne diese Details kann man nur stochern.
In der header.php muß dieses stehen:
<?php
wp_head();
?>Warum kannst du nicht, wie ich vorgeschlagen habe, einfach den letzten Eintrag des externen Feeds benutzen? Da hast du auch das Datum dabei.
Jetzt habe ich die URL der Seite geändert, sie lautet jetzt ohne Unterordner domain.de
Wenn dir die Adresse domain.de nicht gehört, verwende bitte example.com, die existiert genau dafür.
Jetzt möchte ich in der htaccess natürlich alle "alten" Aufrufe mit einem 301-rewrite umleiten auf die neue URL.
Das ist, was ich ganz oben, also vor dem von WP und dem von WPSuperCache erzeugten Einträgen in die htaccess im root eingefügt habe:Apache ConfigurationRewriteCond %{HTTP_HOST} ^\.domain.de/ordner$ [NC] RewriteRule ^(.*)$ http://domain.de/$1 [R=301,L]
%{HTTP_HOST} meint nur den Host, nicht Host + Verzeichnis.
Das $ am Ende der Bedingung sagt, daß der Request genau dort endet. Das willst du aber nicht.
Was eher funktionieren könnte (ungetestet):
RewriteCond %{REQUEST_URI} ^/ordner(.*)$ [NC]
RewriteRule ^(.*)$ http://example.com%1 [R=301,L]Im Footer unter dem Link »Hockey-Manager« findest du den Krempel. Die Suche nach »Blog gehackt« in diesem Forum sagt dir, wie es weitergeht. Mein ehrliches Beileid.
Ich finde es ein bißchen unübersichtlich, um mal den Ausdruck »Linkwüste« zu umschiffen. ;)
Also ein Plugin entpacken und das dort einbauen und wieder als Zip machen und dann hochladen.
Nein, das habe ich nicht geschrieben.
Nochmal ganz einfach: Im Anhang dieses Beitrages ist eine Datei namens ziptest.txt. Die speicherst du auf deinem Rechner. Dann benenne sie um in ziptest.php – aus .txt wird also .php.
Dann starte dein FTP-Programm und kopiere die Datei ins Hauptverzeichnis deiner Webseite.
Jetzt öffne deine Webseite im Browser, und gib oben in die Adresszeile hinter der URL dieses ein: ziptest.php. Wenn deine Webseite beispielsweise unter also http://example.com/ zu finden wäre, müßtest du das eingeben: http://example.com/ziptest.php.
Da bekommst du dann einen Satz zu Gesicht. Wenn er lautet »ZIP geht nicht.«, dann haben wir die Ursache.
Faß das bitte nicht böse auf – aber wenn du solche Probleme mit derart einfachen Dingen hast, solltest du mal überlegen, ob du den technischen Betrieb deiner Webseite nicht delegieren möchtest. Du sparst damit nicht nur erheblich Zeit, sondern gewinnst auch noch Sicherheit. Denn die Gefahr, daß du dir irgendwann mal versehentlich eine Sicherheitslücke einbaust, halte ich durchaus für gegeben.
Da ist offensichtlich kein Inhalt vorhanden, bzw. WordPress findet ihn nicht.
Und der zweite, wichtigere Teil der Antwort lautet?
Ein Hinweis noch: Wirf Tabindex raus. Wenn deine Webseite ordentlich strukturiert ist, braucht das niemand. Ansonsten mußt du für manche Browser alle Links und Formularelemente damit bestücken, weil sie sonst nicht erreichbar sind.
Kopiere den Text innerhalb des Code-Blocks in eine Datei, nenne sie ziptest.php und lade sie per FTP auf deine Seite. Dann rufe sie im Browser auf, und sieh nach, was sie sagt.
