Beiträge von toscho

Bitte den Support doch mal, einen Blick ins Errorlog zu werfen, wenn du selber keinen Zugriff darauf hast. Die reagieren erfahrungsgemäß auch am Wochenende recht schnell und kompetent (hab dennoch Geduld ;)).

Hier meine .htaccess; ich habe auch ein Paket bei all-inkl.com, PHP läuft als Modul, nicht über CGI:

DirectoryIndex index.php
Options +MultiViews


# Spambots
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^.*Whacker.*$ [OR] 
RewriteCond %{HTTP_USER_AGENT} ^EmailCollector [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR] 
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR] 
RewriteCond %{HTTP_USER_AGENT} ^.*FileHound.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*TurnitinBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*JoBo.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*DigExt.*$ [OR]
RewriteCond %{REMOTE_ADDR} ^78.24.8. [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*adressendeutschland.*$
RewriteRule ^.* http://localhost [L,R=301]
</IfModule>


# Kanonischer Host
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} !^(labs\.)*toscho\.de$
RewriteRule ^(.*)$ http://toscho.de/$1 [L,R=301]
</IfModule>


# Spammer
Redirect permanent /_vti_bin http://localhost
Redirect permanent /css http://localhost
Redirect permanent /site http://localhost
Redirect permanent /blog http://localhost
Redirect permanent /s/ http://localhost
Redirect permanent /v/ http://localhost
Redirect permanent /html http://localhost
Redirect permanent /stil http://localhost


# WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Schreibt mal ganz oben in die .htaccess diese Zeile:

DirectoryIndex index.php

Die Texte, die du aus dem Portal beziehst, liegen in einer anderen Zeichenkodierung vor als das Blog: Im Portal ISO-8859-1, im Blog UTF-8.

Also laß erst [FONT="Courier New"]utf8_encode()[/FONT] über die eingebundenen Inhalte laufen, ehe du sie veröffentlichst. Oder stell das Portal auf UTF-8 um; das ist langfristig die bessere Lösung.

Nachtrag: Etwas zuverlässiger als [FONT="Courier New"]utf8_encode()[/FONT] ist diese Lösung: UTF-8 mit PHP erzwingen.

Du mußt einzelnen Listenpunkten ein [FONT="Courier New"]padding-top[/FONT] oder [FONT="Courier New"]margin-top[/FONT] geben.

Sieh mal in den Quellcode der HTML-Ausgabe: Da findest du bei jedem Menupunkt spezielle Werte im Attribut [FONT="Courier New"]class[/FONT]. Such du dir die passende – beispielsweise [FONT="Courier New"]page-item-1000[/FONT] – heraus, und dann schreib ins Stylesheet:

.page-item-1000 {
    padding-top: 1em;
}

Allerdings solltest du den zusätzlichen Leerraum nicht an eine willkürliche Stelle plazieren: Er suggeriert deinen Lesern eine logische Trennung. Wenn die anhand des Inhaltes nicht nachvollziehbar ist, produzierst du damit eine subtile Verwirrung.

Ich habe mal eine ausführliche Variante meiner Antwort in einen Artikel gegossen: Die beste URL-Struktur.

Google wertet Worte in der URL offenbar nur bis zum achten Trennzeichen aus. Also sollte die Basis möglichst kurz sein. Und WordPress wird langsam, wenn die Basis mit %category%, %tag%, %author% oder %postname% beginnt.

Daher halte ich folgende Linkstruktur für günstig:

• Domainname ohne www.
• Basis aussagekräftig aber kurz. Ich benutze nur das Jahr, damit man den Link zeitlich zuordnen kann: [FONT="Courier New"]/%year%/%postname%/[/FONT]
  Detaillierter braucht man es kaum.
• Sinnvoll gekürzte URLs für Einzelposts: Für Safari in CSS und Javascript ansprechen habe ich beispielsweise die URL-Form [FONT="Courier New"]safari-css-javascript[/FONT] benutzt.

Gruß
Thomas

Aktualisierung nicht erkannt

Ich habe auf die originale Version 2.7.1 aktualisiert (also nicht DE_de), aber das kapiert WordPress nicht. Siehe Bild.

Wie vollende ich das Update denn so, daß auch Wordpress selbst sich erkennt?

Gruß
Thomas

Sieh dir einfach den Code auf so einer Seite an. Meistens ist das ein sehr überschaubares Javascriptschnipsel, mit dem die Browserfunktion Strg+Plus/Minus/Mausrad nachgebaut wird.

Das Neustarten kannst du nicht verhindern. Aber durch Setzen eines entsprechenden Expires-Headers kannst du das Caching verbessern, damit nicht die ganze Datei neu heruntergeladen wird.

Gruß
Thomas

Die zweite Zeile wird für den Alternativtext benutzt. Sie kann daher eigentlich keine Beschreibung enthalten, denn das ist nicht die Aufgabe dieses Attributes.

Ein Beispiel:

<img 
  src="droschke.png" alt="Foto einer Droschke" 
  title="Sowas sieht man nur noch selten!"
>

Für jemanden, der keine Bilder sehen kann oder will, wäre die zusätzliche Beschreibung als Alternativtext komplett wertlos.

Ich schlage deshalb vor, dieses Feld »Alternativtext« oder »Ersatztext« zu nennen. Daß Wordpress diesen Wert für die Unterschrift verwendet und nicht den des richtigen Titels ist ein separater Bug, den die Übersetzung allein nicht lösen kann.

Gruß
Thomas

Wird die Klasse tab vielleicht im Druckstylesheet ausgeblendet?

Zitat von marX

das 2. "Titel"-Feld in unserer Übersetzung

Das ja eigentlich Alternativtext heißen muß.

Ich habe nie verstanden, warum WP den Alternativtext für die Beschreibung verwendet, obwohl es doch genau darüber ein Feld für die … Beschreibung gibt.
Dieses Durcheinander muß ja zu Verwirrung führen.

Gruß
Thomas

Zitat von caipurinho

Nee, ist leider schon UTF-8... Das habe ich auch schon überlegt, daran liegt es leider nicht. Wie würde man denn konvertieren?

Wenn du dir ganz sicher bist, verstehe ich leider das Problem nicht. Ansonsten: Hier ist eine kleine Beschreibung

Zitat

Was vielleicht gehen würde, ist die sql-Datei im Editor zu öffnen und einfach alle Umlaute zu ersetzen. Habe nur Angst, dass ich mir so was zerschieße und sieht im Blog natürlich ziemlich beschissen aus...

Du arbeitest natürlich mit einer Kopie des Original-Dumps, und du testest es lokal! Dazu empfehle ich dir die USB-Stick-Variante. Wähle dort Wordpress aus, und entpacke das fertige Archiv irgenwohin. Keine Installation nötig.

Dann importierst du den bearbeiteten SQL-Dump und siehst gleich, ob es Probleme gibt.

Gruß
Thomas

Sehr wahrscheinlich sind deine alten Texte in Windows-1252 oder so kodiert; Wordpress erwartet aber UTF-8.

Der Abbruch ist tatsächlich etwas Gutes (auch wenn es dir nicht so vorkommt ;)), denn er bewahrt dich davor, illegale Zeichen zu importieren und das Problem der falschen Zeichenkodierung dann in der laufenenden DB beheben zu müssen.

Konvertiere also erst die alte Datei nach UTF-8.

Gruß
Thomas

Du gehst mit einem FTP-Programm auf deinen Webspace und fahndest dort nach dem Verzeichnis wp-content/themes/ Und da wirfst du das Theme hinein. Alternativ fragst du eben deinen Anbieter.

Dann gib dem ersten li eine ID, und hebe für die den Rahmen wieder auf.

Bitte lies dir meine erste Antwort nochmal durch. Da steht, welche Änderungen du selbst vornehmen solltest.

Mein Blog läuft bei all-inkl.com. Mit eigener, aktueller Installation natürlich. Auf Nachfrage bekommt man die PHP-Version (4 oder 5), die haben möchte, ebenso die Einbindung (CGI oder Modul). Ich hatte keine Probleme bisher. Das will ich aber nicht verallgemeinern.

Gruß
Thomas

Es muß im Quellcode früher als die Conatiner kommen, die daneben stehen sollen, und es braucht ein float:left im Stylesheet. Wenn die nachfolgenden Container absolut oder relativ positioniert sind, dann mußt du deren top- und left-Werte anpassen.

Gruß
Thomas

Das eval kommt daher, daß der Autor des Themes nur <? verwendet, statt <?php. Das mußt du im Template ersetzen.
Ich sehe keine Rahmen bei den Bildern. Liegt wohl an deinem Browser.

Gruß
Thomas