Beiträge von Ammaletu

Noch mal als kleiner Nachtrag dazu eine Sache, die mir eben gerade Kopfzerbrechen bereitet hat: Folgt auf eine Zahl direkt ein (schließendes) Anführungszeichen, ersetzt WordPress das nicht korrekt durch das typographische schließende Anführungszeichen (Englisch: & #8221;) sondern durch das Zollzeichen (& #8243;). Bei mir war es eben eine Überschrift, die auf "2008" endete. Auch das aktivierte "InTypo"-Plugin hat daran nichts geändert.

Das Zollzeichen sieht irgendwie ähnlich aus, aber je nach Schriftart ist der Unterschied schon sichtbar, zumal in einer größeren Überschrift. Klar, an der Stelle kann WP ja nicht wirklich wissen, dass ich nicht die Einheit Zoll meine. Kommt mir irgendwie trotzdem blöd vor.

Naja, jedenfalls habe ich das jetzt für mich erstmal dadurch behoben, dass ich in wp-includes/formatting.php in Zeile 23 und 24 die beiden Konvertierungen für Zoll/Sekunden und Fuß/Minuten rausgenommen habe. Das sieht bei mir jetzt so aus... Edit: Ich würde es posten, aber das Forum zerhaut mir das immer. :-/
(WP 2.3.3)

Falls jemand eine schönere Lösung kennt, immer her damit. ;-)

Also ich denke, der Fehler liegt hier noch woanders. Die Kommentare im Quelltext sind ein bisschen irreführend, denn man kann da sehr wohl zwischen Teaser und Volltext umschalten, jedenfalls wenn der Feed die Kurzform im Tag "description" enthält und die Volltext-Variante (incl. HTML) im Tag "content". Zumindest deute ich den oben zitierten Quelltext-Schnipsel mal so.

Ich glaube, das Problem liegt eher darin, dass Frank das für RSS-Feeds angepasst hat (deswegen auch der Name des Plugins *g*). Und da steht der Volltext-Inhalt, bei mir zumindest, in einem Element namens "content:encoded". Das versucht er da auszulesen. In Deinem Atom-Feed heißt das Element dagegen nur "content" und wird deshalb vermutlich nicht gefunden. Soweit jedenfalls meine Vermutung. Aber ich frage Frank einfach mal. ;-)

Es ist diese Zeile hier, ca. Zeile 35/36:

<small class="commentmetadata"><a href="#comment-<?php comment_ID() ?>" title=""><?php comment_date('d F Y') ?> um <?php comment_time('H:i') ?> Uhr <?php edit_comment_link('edit','',''); ?></small>

Die sollte so aussehen:

<small class="commentmetadata"><a href="#comment-<?php comment_ID() ?>" title=""><?php comment_date('d F Y') ?> um <?php comment_time('H:i') ?> Uhr</a> <?php edit_comment_link('edit','',''); ?></small>

Falls das Theme veröffentlicht ist (also keine Eigenkreation), gib doch bitte auch dem Themeautor Bescheid, damit er den Fehler behebt.

Ähm, also dieses Thema haben wir mehrmals im Monat. Da müsstest Du mit der Suchfunktion eigentlich schon weiterkommen. Aber ich fasse noch mal zusammen: In der Quelltext-Ansicht von WP siehst Du normalerweise weder <br> noch <p>, die werden von WP beim Speichern ergänzt. In der Anzeige auf der Webseite müssten sie im Quelltext trotzdem drin sein. Ob Du die Absätze auch in der normalen Webseiten-Ansicht siehst, hängt vom Stylesheet ab. Schau mal nach, was da für margin oder padding für Absätze definiert ist.

Das wäre soweit der Normalfall. Bei Dir kann es natürlich auch noch an was anderem liegen, da hilft uns ggf. ein Link zur Seite weiter. ;-)

Das ist vermutlich ein einfach zu behebender Fehler im Theme. Geh mal in die comments.php Deines Themes und suche die Stelle, an der das Datum des Kommentars ausgegeben wird. Dieses Datum soll verlinkt sein mit dem Permalink des Kommentars, was es auch ist, aber der Link wird nicht wieder geschlossen. Vor das "<br />" am Ende der Zeile muss also noch ein "</a>".

Zitat

Mein Problem ist, dass das PlugIn zwar Überschriften darstellt (und wahlweise auch Description), aber eben NICHT den Volltext des Postings.

Das heißt, Du hast die Doku des Plugins gelesen und wie angegeben hier die dritte Zeile auskommentiert und an der fünften den Kommentar entfernt?

// Edit here:
// For import with pure text
//$desc  = $item['description'];
// For import with HTML
$desc  = $item['content']['encoded'];

Das ist zugegebenermaßen nicht optimal gelöst, dass man das Plugin manuell modifizieren muss. Das wäre als Option wesentlich besser aufgehoben.

Tja, und dann muss der Ziel-Feed natürlich auch den Volltext enthalten, klar. Und damit sollte es eigentlich wie gewünscht funktionieren. Mehr kann ich dazu aber auch nicht sagen, da ich nicht die Zeit habe, das selber auszuprobieren. Wenn es wirklich nicht geht, ist es entweder mit Atom oder mit der neueren WP-Version nicht kompatibel. Gegebenenfalls freut sich dann der Plugin-Autor sicher über einen Hinweis auf seiner Seite.

Also so ganz verstehe ich Dein Problem ehrlich gesagt nicht. Wenn ich mir die Plugin-Seite anschaue, dann hat das Plugin eine Option, auch den Inhalt darzustellen. Wahlweise auch den kompletten Inhalt incl. HTML. Funktioniert das jetzt mit Atom einfach nicht oder hast Du diese Optionen noch nicht entdeckt? ;-)

Irgendwie lässt mich das vermuten, dass die Dateien beim Hochladen beschädigt werden oder einige Dateien fehlen. Eventuell solltest Du ein anderes FTP-Programm ausprobieren. SmartFTP funktioniert bei mir z.B. recht gut.

Falls die geänderte Adresse in ihrer alten Form in den Optionen steht,musst Du das dort auf jeden Fall anpassen. Direkt in der Datenbank, wenn Du Dich nicht einloggen kannst. Nimm ein Tool wie phpMyAdmin und such in der wp_options-Tabelle nach der URL.

Wenn sich die Adresse des Blogs geändert hat, muss das in den WP-Optionen geändert werden. Da gibt es ein oder Optionen, welche die Blogadresse enthalten, und wenn das nicht mit der tatsächlichen URL übereinstimmt, fällt einem das "canonical URL"-Feature von WordPress auf die Füße. WP leitet ja alle Aufrufe über alternative URLs auf die eingetragene URL um.

Falls Du in Deinen älteren Beiträgen eigene Beiträge mit der kompletten URL verlinkt hast, müsstest Du diese Links natürlich auch ändern, wenn der Blogaufruf generell dann wieder klappt.

Wieso Dein Provider Deine Website so verschiebt, dass sich die Blog-Adresse ändert, wäre natürlich noch mal eine ganz andere Frage. Ich meine, war das Absicht? So sind dann ja alle Links auf den Blog kaputt, incl Google.

Ein anderes sehr schönes Plugin dafür ist InTypo:
http://dossier.dunker.de/intypo

Ich kenne Typographical Improvements nicht, aber InTypo nutze ich schon länger und bin sehr zufrieden damit. Eigentlich denke ich auch immer noch, dass so ein Plugin der deutschen WP-Version beiliegen sollte, da es WP alleine ja nun mal nicht richtig hinkriegt. :-/

Mögliche Ursachen:
- Das Senden von Trackbacks ist im zweiten Blog deaktiviert oder das Empfangen von Trackbacks im ersten. Letzteres kann global oder am Posting gemacht werden.
- Das erste Blog ist nicht öffentlich, z.B. per .htaccess mit einem PW geschützt. Da kommt der Ping natürlich nicht durch.
- Akismet oder ein anderes Plugin hat den Trackback als Spam eingestuft. Dann müsstest Du ihn im Backend in der entsprechenden Ansicht wiederfinden.
- Die Serverkonfiguration lässt keine Trackbacks zu. Details kenne ich nicht, aber wir hatten mal einen Kundenserver, wo wir das auch partout nicht hinbekommen haben.

Ok, das waren jetzt nur mal ein paar spontane Ideen dazu... :-)

Ich bin mir ziemlich sicher, dass das daran liegt, dass entweder TinyMCE selber oder TinyMCE mit TinyMCEadvanced das Stylesheet Deines Themes lädt. Da ist das sicher angegeben, oder? Ob man das verhindern kann, weiß ich aus dem Kopf gerade nicht. Aber die kurze und schmerzlose Lösung wäre es sicherlich, die Styles einfach in ein anderes File auszulagern. Ich habe bei mir z.B. in der style.css im Themeverzeichnis nur den Header stehen, den WordPress für die Anzeige in der Themeauswahl braucht. Alle anderen Styles habe ich im Untrordner "css" in eine neue style.css gelegt, die dann in der header.php des Themes natürlich auch eingebunden werden muss. Dann würde TinyMCE (nach dem Leeren des Caches) nur noch die quasi leere Styledatei sehen und Du hättest Deine Ruhe vor solchen Effekten.

So, hoffe, das war richtig geraten. ;-) Aber ich erinnere mich, dass bei meinem TinyMCE z.B. Linkformatierungen plötzlich im Editor auftauchten, aus genau diesem Grund. Natürlich kannst Du TinymCE auch einfach komplett abschalten, dann sollte das Problem auch nicht mehr auftauchen und es arbeitet sich eine ganze Ecke besser. ;-)

Also ich kann wie üblich nur raten, aber ich probier's mal.

A) Das hängt mit dem Tool "suPHP" zusammen, das auf Deinem Server offensichtlich eingesetzt wird. Man könnte die angezeigte Meldung so interpretieren, dass sich suPHP über diese Schreibrechte beschwert, so dass Du mal probieren könntest, die Schreibrechte dieses Ordners nur für Deinen User zu setzen.

Davon abgesehen rät die suPHP-Website zu einem Update auf Version 0.6.3, was Du ggf. Deinem Hoster ja mal mitteilen könntest:
suPHP - Home

B) Die suPHP-Meldung hat mit dem eigentlichen Fehler nichts zu tun und steht da nur zufällig. Dann würde ich doch mal hoffen, dass im PHP-Errorlog die eigentliche Fehlermeldung steht. Da solltest Du mal nachschauen.

Wie gesagt, nur geraten, aber vielleicht hilft es Dir ja weiter. Viel Glück! :-)

Hallo Silvi!

Kein Problem... dachte ich, aber offenbar gibt es die benötigte Funktion noch nicht in WordPress. Aber dann schreiben wir die halt selber (kann sein, dass es sie in 2.5 auch schon gibt, das müsste mal jemand anders ergänzen). Das hier einfach in die function.php Deines Themes:

/**
 * Check if the current post has the given tag assigned.
 * 
 * @param tag The name of the tag to search for.
 */
function has_tag($tag) {
  global $post, $blog_id;
  
  // check that a tag is given
  if (empty($tag)) {
    return false;
  }
  
  $tags = get_object_term_cache($post->ID, 'post_tag');
  if ($tags === false) {
    $tags = wp_get_object_terms($post->ID, 'post_tag');
  }
  return array_key_exists($tag, $tags);
}

Dann schließt Du die Anweisungen, die auf einigen Seiten nicht erscheinen sollen, einfach so hier ein (in der single.php, im Loop):

<?php if (!has_tag('gemeinsamer_tag_name')) { ?>
  erstellt von: 
  erstellt am:
  usw.
<?php } /* end if */ ?>

Damit würden diese Angaben nicht ausgegeben werden, wenn der aktuelle Beitrag das Tag "gemeinsamer_tag_name" hat.

Grüße,
Johannes

Also ich würde jetzt zuerst mal versuchen sicherzustellen, dass der DB-Umzug korrekt geklappt hat. Der Autor von Mysqldumper lässt sich hier recht ausführlich zu der Problematik aus:
MySQLDumper-Board :: Thema anzeigen - Die Umlautproblematik - was, wieso, was tun?
Falls Du also nicht die Version 1.22 oder neuer dieses Programmes nutzt, lohnt es sich eventuell, den DB-Umzug noch mal zu wiederholen.

Und dann muss natürlich der PHP-Fehler noch weg. dazu hatte ich hier schon mal was geschrieben:
http://forum.wordpress-deutschland.org/installation/3…-auf-2-5-a.html
Da hatte ich vermutet, dass das an den kaputten Text-Widgets in der DB liegt. Enthält Deine alte DB Text-Widgets für die Sidebar, welche Umlaute enthalten?! Dann sollte das hoffentlich wieder gehen, wenn die Umlaute in der DB stimmen. Schlimmstenfalls müsste man die Text-Widgets manuell aus der DB löschen und neu setzen. Gespeichert sind sie in der wp_options-Tabelle.

Also zuerst mal müsstest Du Dir klar machen, wie WordPress funktioniert: Die Daten werden in eine Datenbank gelegt, sind also im Dateisystem nicht zu finden. Wie Du sie dann aufrufst, über welche URL, ist bei WordPress einstellbar. Schau mal unter Einstellungen > Permalinks. Das default-Format ist etwas wie "localhost/wordpress/index.php?page=1" oder so. Das sollte immer gehen. Dann kann man aber auch schönere Links einstellen, etwa "localhost/wordpress/test". Damit die gehen, muss der Server aber einige Voraussetzungen erfüllen, mod_rewrite muss aktiviert sein unter anderem.

Falls Du das lokal unter WAMPP testest, musste noch etwas im Apache eingestellt werden. Ich weiß, dass die Permalinks bei mir auch erst nicht gingen, bis ich das ergänzt hatte. Bin mir nur gerade nicht sicher, was es war, aber schau mal, dass Du diese Anweisungen in Deiner Apache-Config stehen hast:

<Directory "D:/webapps/wordpress/">
    Options FollowSymLinks
    AllowOverride FileInfo
    Order allow,deny
    Allow from all
  </Directory>

Das hatte ich in einem anderen Thread vor ein paar Tagen eigentlich schon geschrieben, dachte ich. Das hier verursacht IMHO das Problem: "open_basedir restriction in effect. File(/tmp/) is not within the allowed path(s)". Steht ja eigentlich alles da: Es wird versucht, auf ein temporäres Verzeichnis zuzugreifen, welches nicht erlaubt ist. Wenn Du nicht Deinen eigenen Server managst, müsstest Du da mal beim Support Deines Hosters nachfragen, was man daran machen könnte.

Zitat

Die Tabellen sind in latin1

Meinst Du damit die exportierten Tabellen oder die neue Datenbank? So wie es aussieht werden da UTF-8-Sonderzeichen als ISO-8859-1 ausgelesen, was falsch ist. Gegebenenfalls reicht es ja, die Encoding-Einstellung in WordPress (Einstellungen > Lesen?!) und in der wp-config.php zu UTF-8 zu ändern.

Und magst Du näher ausführen, was "funktioniert nicht" heißt? Das Plugin hast Du wieder entfernt, oder? Und um welche WP-Version geht es überhaupt?