Beiträge von msi

Zitat von jottlieb

Also auf der Startseite steht doch gleich als erster Text das: [...] Und darunter der Link zu den Vorraussetzungen.

Geh einfach mal von der eingetretenen Situation aus: jemand liest die Voraussetzungen "PHP? ja, hab ich. MySQL? ja, hab ich. Installation von WordPress? Klappt nicht. Wieso 'Datenbank'?" Es soll tatsächlich Leute geben, die mit den Begrifflichkeiten nicht viel anfangen können. Das ist nicht böse gemeint, aber der Fragesteller hat es bewiesen. Wüsste er, wozu MySQL gut ist, hätte er wohl nicht nach dem Sinn einer Datenbank gefragt. ;)

Dein Blog liegt also direkt auf der TLD (top level domain). Rein technisch funktioniert dann die Umleitung per ".htaccess" im Hauptverzeichnis der Domain mit

RewriteEngine on
RewriteRule .* http://www.beispiel.tld/$1 [R=301]

(wie im verlinkten Beitrag gezeigt). Die Anfrage an die alte Domain berücksichtigt die Domain selbst nicht; es wird nur der Teil ab dem Slash / geprüft. Und was da kommt, wird 1:1 an die neue Domain weitergereicht.

Schwerer wird es, wenn du nur bestimmte Beiträge umleiten lassen willst. Beiträge aus bestimmten Kategorien oder Monaten. In dem Fall kannst du nicht auf .* (= alles) prüfen, sondern du musst es durch die Angabe der Kategorien bzw. der Monate weiter eingrenzen.

Ohne mehr Informationen nicht.

Wenn du den kompletten Blog auf eine andere Domain umziehst, dann kannst du das Beispiel aus dem verlinkten Beitrag nutzen. Du musst dafür sorgen, dass alle normalen Webseiten auf der alten Domain weiter erreichbar sind, während Anfragen an den Blog umgeleitet werden.

Wenn du nur Teile des Blogs (bestimmte Kategorien o.ä.) auf die neue Domain umziehen willst, dann ist das Prinzip so ähnlich wie im verlinkten Beitrag. Anfragen an bestimmte Kategorien gibst du dann eben an die neue Domain weiter, während die restlichen Anfragen vom Blog auf der alten Domain bearbeitet werden. Könnte dann so aussehen:

RewriteRule ^kategoriename/.* http://neuedomain/kategoriename/$1

(ungetestet)

Na ja, dann musst du beim Aufruf der Domain B noch den "wordpress"-Ordner anhängen.

RewriteRule .* http://domainB/wordpress/$1

Ich schrieb ja: mein Beispiel geht davon aus, dass der Blog über die Hauptdomain "domainA.tld" erreichbar ist und dann die Anfragen auf "domainB.tld" umgeleitet wird.

Na ja, das Thema Umleitung hatten wir gestern erst. Wenn du aber sagst, es soll nur teilweise umgeleitet werden, dann wird das schon schwieriger. :confused:

Na ja, wenn du willst, hängst du (mit Leerzeichen) noch

[R=301]

am Ende ran.

Zitat von jottlieb

Dann war mein Tipp mit der index.php schon richtig

Müsste man den nicht mal anpassen? Seit Version 2.3 muss man nicht mehr im PHP-Code fummeln. Okay, eigentlich schon, weil es ja die "index.php" ist. :mrgreen: Aber ich spreche eigentlich vom JavaScript-Output recht weit am Anfang der Datei:

<script type="text/javascript">
    jQuery(function() {
        jQuery('#incominglinks').load('index-extra.php?jax=incominglinks');
//        jQuery('#devnews').load('index-extra.php?jax=devnews');
//        jQuery('#planetnews').load('index-extra.php?jax=planetnews');
    });
</script>

Einfach mit Doppelslash // auskommentieren, dann wird ein Kommentar im JavaScript draus, der nicht weiter berücksichtigt wird. Mein Tellerrand zeigt so nur die eingehenden Links.

Versuch es auf Domain A mal so:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteRule .* http://domainB/$1
</IfModule>

Müsste ggf an deine Domain/Verzeichnisstruktur angepasst werden. Das Beispiel geht davon aus, dass der Blog direkt über die Domain "domainA.tld" aufrufbar ist (auch wenn die WordPress-Dateien meinetwegen im Unterordner "blog" liegen).

Kann man auch in 3 Zeilen setzen, wenn man die TLD zusammenfasst:

RewriteCond %{HTTP_REFERER} !^http://(www\.)?domain\.(de|net|org)(/.*)?$ [NC]

Hast du daran gedacht, nach dem Update die "wp-admin/upgrade.php" auszuführen? Und ggf deaktiviere mal die Plugins; evtl. spielt eins von denen verrückt, weil es zu alt ist.

PageLink-Manager-Plugin. ;)

Gut, dass du lesen kannst. :D

Das verlangt zum Glück auch niemand. Und falls wirklich mal jemand eine Frage zu K2 hat, dann kann ich ja auch einspringen.

K2 denkt nicht mit, das muss schon der Blogger machen. Aber K2 schreibt in die Klassenangaben im <body>-Tag den Namen der Kategorie, des Tags, des Autoren, usw:

<body class="... home ..." >
<body class="... s-category-job s-tag-job ..." >
<body class="... s-category-automobil s-author-AutorName ..." >

Und da ich voraussetze, dass du dich mit CSS auskennst, dürftest du wohl wissen, dass man per

#header {
    background-image: url('bild1.jpg');
}


body.s-tag-job #header{
    background-image: url('bild2.jpg');
}


body.s-category-job #header,
body.category-job #header {
    background-image: url('bild3.jpg');
}


/* usw. */

die Bilder tauschen kann, ohne in den PHP-Dateien fummeln zu müssen.

btw, Ironie und Hochnäsigkeit sind feine Sachen. Man sollte allerdings sicher sein, nicht an den Falschen zu geraten. :mrgreen: Mein Blog nutzt das K2-Thema, und ich habe 1 Standardbild für die meisten Beiträge, 1 spezielles Bild für eine bestimmte Kategorie, und früher hatte ich auch mal ein eigenes Bild für das Impressum (statische Seite).

Die gezeigten Beispiele gelten zwar für das Headerbild in K2, aber das lässt sich ja trotzdem auch für Hintergrundbilder nutzen.

Puh, da lobe ich mir aber Themen wie K2, die Infos zur Seite direkt im Body als Klasse angeben. So kann man die PHP-Dateien des Themas in Ruhe lassen und die gewünschten Bilder einfach per "style.css" laden.

Hast du an das "domain/blog/wp-admin/upgrade.php" gedacht?

Zitat von selm

Jetzt meine Frage: ich nutze ja das K2-Theme und habe dieses an vielen Stellen im style.css individuell angepasst.

Nutze ich auch, und K2 unterstützt doch separate Styles; d.h. du lässt die originale "style.css" unverändert und packst deine eigenen Definitionen in den Unterordner "styles/deinstil/deinecss.css" rein und wählst selbige im K2-Admin-Board aus.

Bei laufen die SVN-Versionen von WP und K2 problemlos. Off- und online. Ich habe auch ein paar Änderungen vorgenommen, und weil ich keine Lust hatte, das ständig per Hand zu machen, habe ich mit "diff" Patchdateien angelegt. Ein Shellskript zieht z.B. die aktuelle SVN-Version, kopiert die Dateien in meinen lokalen Blogordner und ruft dann "patch" auf, um meine Änderungen einzuspielen. Ich muss nur dann wieder aktiv werden, wenn sich eine der Dateien so verändert, dass der Patch die zu ändernde Zeile nicht mehr findet. ;)

Zitat von Ammaletu

Kann es sein, dass das unter Mac einfach nicht funktioniert mit den Permalink-Weiterleitungen? Bei mir unter Win-XP ist es jedenfalls so, da klappt das mit dem Standard-Apache nicht, weswegen ich in meinem lokalen Testblog die Links auch auf "klassisch" gestellt habe.

Ist wohl eher ein Zusammenspiel zwischen WordPress und der ".htaccess"-Datei (ggf mal die Apache-Logs prüfen). Bei mir lokal unter Linux klappt es wunderbar mit den Permalinks.

Die Frage wäre, ob es wirklich ausschließlich am Tool liegt. Ein Export der Datenbank (mit phpMyAdmin) würde ja zeigen, wie Umlaute und Sonderzeichen in der Textdatei gespeichert werden. Sind sie ebenfalls falsch gespeichert, hat WP zumindest eine Teilschuld.

In einem Punkt muss ich aber zustimmen. Wenn man es nicht separat einstellt, dann legt WordPress (obwohl die Zeicheneinstellung in den Optionen auf UTF-8 gestellt ist) latin-Tabellen an. Warum die beiden Einträge

define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

in der "wp-config.php" nicht standardmäßig aktiv sind, ist mir ein Rätsel. Sind die nämlich drin, und man startet den Installer für die Ersteinrichtung des Blog, dann werden auch die Tabellen korrekt erzeugt und es gibt keine Probleme mit den Umlauten.