Beiträge

[WordPress] Kommentarlinks einfach mit external, (no)follow und target=_blank

/10 Kommentare/in /von

Hallo,

heute mal wieder einen Tipp zu WordPress.

Es ist hart umstritten… Kommentarlinks mit external oder ohne, follow oder nofollow und welchen target soll der Link haben. Die einen sagen Hü, die anderen Hot. Egal, jeder soll machen wie er mag. Doch wie macht man wie man mag?

Eigentlich ganz einfach. Zumindest wenn man alle Kommentarlinks gleich haben will. Also zum Beispiel sollte rel=“external“ immer drin stehen, denn schließlich sind die Kommentarlinks external, es sei denn man selbst Kommentiert.

Dazu ruft man einfach seine „functions.php“ in einem Editor auf und fügt am Ende, vor „?>“ den folgenden Code ein. Natürlich dabei den Linkcode so bearbeiten wie man es mag.


    // Kommentarlinks in neuem Tab / Fenster
    function comment_author_link_window() {
	    global $comment;
	    $url = get_comment_author_url();
	    $author = get_comment_author();
	
	    if ( empty( $url ) || 'http://' == $url) {
	    	$return = $author;
    	}
    	elseif(stristr($url, get_home_url())) {
	    	$return = "".$author."";
    	} else {
	    	$return = "".$author."";
    	}
	    return $return;
    }
    add_filter('get_comment_author_link', 'comment_author_link_window');

Und schon werden alle Kommentarlinks mit den Attributen versehen die man haben möchte.

Ich persönlich habe alles gesperrt. Also rel=“external nofollow“ und auch target=_blank. Viele werden jetzt denken „Was für nen Arsch.“. Aber externe Links sind nunmal „external“. Bei den Kommentaren die ich hier bekomme weiß ich manchmal nicht mehr ob es nur zum Abgreifen eines Links ist oder nicht. Daher „nofollow“ und gut. Wer einen Kommentar schreibt, der tut es weil er etwas zu meinem Artikel beitragen möchte und nicht damit seine Seite besser rankt. Und external… ich mag meine Leser und möchte bitte auch das Sie auf meiner Seite bleiben! Finish :)

Bug in WordPress XMLRPC wp.uploadfile – Dateiupload funktioniert nicht!

/0 Kommentare/in /von

Gerade habe ich einen Bug in der XMLRPC-Schnittstelle von WordPress gefunden. Anscheinen nutzt diese Funktion aber wohl kaum jemand, wenn es noch keinem Aufgefallen ist. Ich habe aber genau diese Klasse kopiert und in einem anderen Projekt verwendet, um es mir mal einfacher zu machen. :-)

Der Bug befindet sich in der wp.uploadFile aka mw_newMediaObject Funktion. Mit dieser Funktion können Dateien über die XMLRPC-Schnittstelle in den Blog geladen werden.
Das Problem, es funktioniert nur nicht wirklich. Die Daten müssen per base64_encode codiert werden. Hab ich auch brav gemacht, nur werden sie im Blog nicht wieder decodiert und damit genau so gespeichert wie sie übertragen werden. Das kann jedoch nicht funktionieren.

Also habe ich mich auf die Suche gemacht und den Fehler gefunden. Die XMLRPC Klasse von WordPress (class-IXR.php) erkennt auf der Client-Seite Base64-Codierte Strings nicht. Ich habe im Netz auch keine Möglichkeit gefunden wie man prüfen kann ob ein String im Base64-Format vorliegt. Daher habe ich zu einer anderen Möglichkeit gegriffen den Bug zu fixen.

Wir gehen mal wieder in den Code. Achtung: Wenn diese Änderung im Blog selbst vorgenommen wird, wird es beim nächsten Update überschrieben!
Als erstes nehmen wir uns ca. Zeile 35 vor. Hier sollte folgendes stehen:


foreach ($this->data as $key => $value) {
     $this->data[$key] = new IXR_Value($value);
}

Das ändern wir in:


foreach ($this->data as $key => $value) {
     if($key == "bits") $this->data[$key] = new IXR_Value($value, "base64");
     else $this->data[$key] = new IXR_Value($value);
}

Soweit ich gesehen habe gibt es den „bits“ Parameter nur ein mal in der Schnittstelle. Und zwar genau dort wo der Base64-String unserer Datei drin ist. Also sagen wir „Wenn Parameter ‚bits‘ ist, dann ist es Base64. Und schon schalten wir die automatische – und falsche – Erkennung des Variablen-Types aus und sagen gleich das es Base64 ist.

Dann gehen wir noch zu einem anderen Bug. Der ist ca. in Zeile 114. Die Originalzeile heißt:


     case 'date':
     case 'base64':
          return $this->data->getXml();
          break;

Das gibt einen Fehler. Die Funktion getXml() gibt es unter $this->data nicht und wäre auch Schwachsinn.  Die Zeilen müssen wie folgt aussehen:


     case 'date':
          return $this->data->getXml();
          break;
     case 'base64':
          return '<base64>'.$this->data.'</base64>';
          break;

So, jetzt sollte es funktionieren.

Wie gesagt, wenn ihr die Klasse kopiert habt und in einem anderen Projekt verwendet, dann ist es ok. Wenn ihr es im WordPress selbst ändert dann wird es beim nächsten Update überschrieben.

[WordPress] FTP Daten für automatische Updates festlesen

/0 Kommentare/in /von

Da wir heute gerade schon mal beim Thema waren. Hier gleich noch ein Beitrag zu den automatischen Updates. Normalerweise fragt WordPress immer nach den FTP Daten um die Updates zu installieren. Man kann diese jedoch auch in der wp-config.php selbst (und fest) vorgeben. Dann müssen sie einerseits nicht mehr ständig eingegeben werden und es verringert auch das Sicherheitsrisiko (sagen jedenfalls die Experten :-) ).

Also wp-config.php öffnen und irgendwo – am besten nach den SQL Daten – die folgenden Parameter eintragen (und konfigurieren natürlich).

define('FTP_HOST', 'musterdomain.de');
define('FTP_USER', 'ftp_user');
define('FTP_PASS', 'ftp_paswort');

Die folgenden Zeilen müssen nicht angegeben werden. Wenn Du weißt was Du tust, dann kannst Du auch hier eigene Einstellungen vornehmen.

 
define('FTP_SSL', true); //SSL Verschlüsselter Upload
define('FTP_BASE', '...'); //Root Verzeichnis der WordPress Installation
define('FTP_CONTENT_DIR', '...'); //wp-content Verzeichnis
define('FTP_PLUGIN_DIR', '...'); //wp-plugin Verzeichnis
define('FS_METHOD', 'direct'); //FTP Methode

[WordPress] Automatisches Update funktioniert nicht

/0 Kommentare/in /von

Ich habe schon seid einer Weile ein Problem mit meinen automatischen Updates im WordPress. Er bricht das Update gleich mit der Fehlermeldung: „Das Verzeichnis „wp-content“ konnte nicht gefunden werden.“ ab.

Dazu muss ich sagen das ich auf einen Webspace umgezogen bin und nun alles irgendwie in einem Root Verzeichnis, in verschiedenen Unterverzeichnissen, liegt. Das ganze wird über einen FTP Zugang gemanaged.

Schnelle Abhilfe schafft man sich indem man WordPress einfach den richtigen Pfad vorgibt. Dann weiß WordPress wieder wohin mit den Daten und alles ist schick ;-)
Dazu einfach den folgenden Code in die wp-config.php einfügen, irgendwo.

putenv('TMPDIR=' . ini_get('upload_tmp_dir'));

Speichern, hochladen und alles sollte wieder laufen.

1und1, WordPress Blogs und der 500 Internal server error

/0 Kommentare/in /von

Hallo,

da hatte ich doch gerade mal wieder ein Problem. Kommt ja ab und zu mal vor :-) Und wie es scheint habe ich den nicht alleine. Es gibt schon einige User mit dem Problemchen.

Ich wollte auf einem 1und1 Webspace einen WordPress Blog installieren (V. 3.0.01) und bekam probt einen „500 Internal Server Error“.

Die Lösung ist einfach, aber normalerweise kommt man darauf selbst nur schwer, da er absolut unnatürlich ist :-)

Den folgenden Code in die .htaccess einfügen und der Blog sollte laufen.

 
AddType x-mapp-php5 .php 
AddHandler x-mapp-php5 .php

[WordPress] HTML-Dateiendung in Artikeln, Seiten, Tags und Kategorien

/5 Kommentare/in /von

Hallo zusammen,

ich spiele ja in der letzten zeit auch endlich mal ein bisschen mit SEO rum und überhaupt hat es mich schon eine weile gestört das in wordpress keine vernünftigen dateiendungen integriert sind. Google mag es mit sicherheit nicht wenn eine url auf „…/category/fun“ endet… ohne slash ohne „.html“ … ohne alles. Einfach zu ende.

Nun ist es sehr einfach bei wordpress an jeden artikel ein „.html“ anzuhängen. Das kann man ganz einfach in den permalinks in den optionen einstellen. Möchte man das auch bei seiten und sogar bei den kategorien machen… hat man schon ein problem.
Und so habe ich mich auf die suche begeben und bin fündig geworden.

Ich bin über 10 ecken auf das plugin „.html on pages“ aufmerksam geworden. Das ist erst einmal teilweise was ich suchte. Denn das dieses plugin fügt nur bei seiten die dateiendung „.html“ hinzu… nicht bei kategorien. :-(

Also selbst ein bisschen rumgefummelt und siehe da… nun geht es auch bei den kategorien. :-) Da mein blog noch immer code nicht vernünftig darstellt habe ich das überarbeitete plugin einfach noch mal gezippt und du kannst es >hier< downloaden. Ich habe auch die readme.txt noch mal erweitert.

Nun gab es aber gleich noch ein problem. Mein blog besteht ja nun schon eine weile und es gibt schon so einige urls die auch bei google indexiert sind und verlinkungen zu anderen seiten. Also würden alle anfragen auf die alten urls auf der 404 seite landen. Das wäre natürlich nicht so toll.
Daher musste noch ein 301 redirect her. Der kommt in die .htaccess über die regeln von wordpress – logisch. Hier der htaccess code:

RewriteCond %{REQUEST_URI} ^/[^.]+[^/]$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1.html [L,R=301]

Damit werden alle seiten ohne .html und ohne slash (/) am ende mit der endung „.html“ versehen. … Damit haben wir es … oder?

Nee, leider immer noch nicht. Ein kleiner fehler ist mir – bis jetzt – aufgefallen. Möchte ich meinen rss-feed abrufen… schickt er mich auf die 404-seite (seite nicht gefunden). Warum? Auch er bekommt ein „.html“ angehängt… aber der feed kann damit nicht aufgerufen werden. Er funktioniert immer noch ohne. Also schnell noch ein eintrag in der .htaccess. Am besten ganz oben:

RewriteRule ^feed$ feed/ [L,R=301]

So, jetzt bekommt er ein slash und wird damit von der anderen regel ignoriert.

Nun haben wir es erst einmal. :-)
Bitte beachtet das eine änderung in den permalinks im adminmenü die .htaccess änderungen unter umständen wieder rausschmeißt.

—-

Ach gleich das nächste problem. Ok, durch die rewrite rule wird nun überall .html hinzugefügt. Das ist nicht immer schön. Ich habe noch die nextgen galerie installiert. Die arbeitet nun natürlich auch nicht mehr. :-( Denn auch sie kann mit den html-endungen nicht umgehen. Mist…
Also wer noch andere urls braucht der muss die htaccess regel modifizieren. Ich habe meine jetzt geändert zu:

RewriteCond %{REQUEST_URI} ^/[^.]+[^/]$
RewriteCond %{REQUEST_URI} !^/nggallery/[^.]+[^/]$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1.html [L,R=301]

Damit sage ich „nur wenn in der url nicht ’nggallery/‘ enthalten ist.

Ich hoffe es geht alles gut :-)

CU
Gordon

Update:
Da muss ich gleich noch mal ein Update hinterherschießen. Habe gerade festgestellt es gibt ja auch noch die Tags. :-) Habe das Plugin auch gleich noch mal modifiziert. Jetzt werden die urls für seiten, kategorien und tags unterstützt. Artikel urls kannst du ja selbst im administrationsbereich einstellen.

[WordPress] Geheime Einstellungsmöglichkeiten

/0 Kommentare/in /von

Hallo zusammen,

gerade habe ich weder einmal etwas dazugelernt.

Ich wollte meinen RSS-Feed bei portalen eintragen und da meinte eines doch glatt das sie keine englischen feeds aufnehmen… :-o Wie, english? Wie kommen die denn darauf?
Ganz einfach, weil mein rss-feed auf english (en) steht.

Gut… wie ändere ich das jetzt? Alle einstellungsseiten durchgesehen… nix gefunden. Ich wollte schon wieder in den quellcode gehen als ich noch eine andere, höchst interessante, lösung fand. Es gibt nämlich bei wordpress eine einstellungsseite auf die man normalerweise nicht gelangt. Kein link im menü führt dorthin… eine geheime einstellungsseite quasi :-)

Wie kommt man nun dort hin. Erst einmal ins backend einloggen. Dann nach „wp-admin/“ options.php eingeben. Also so das die url in etwa so aussieht: http://www.domain.de/wp-admin/options.php

Hier gibt es (zwischen den vielen anderen) die einstellmöglichkeit „rss-language“… hier muss man „de“ eingeben. Und schon ist der rss-feed auch in deutsch.

Aber auf der seite gibt es noch zig andere einstellmöglichkeiten… in denne niemand rumfummeln sollte der nicht weiß was er tut… deswegen ist sie auch so gut versteckt ;-)

Viele Grüße
Gordon

Gordon’s Chaosblog goes to facebook…

/0 Kommentare/in /von

Hallo zusammen,

die meisten wird das gar nicht interessieren… ein paar vielleicht schon. Nämlich die die selbst über facebook applikationen nachdenken.

Ich kann und will hier nicht noch ein how to do schreiben… dafür gibt es schon genug. Also werd ich es kurz und bündig machen :-)

Warum sollte man einen blog bei facebook einbinden? *pfff* Keine ahnung… jeder hat so seine eigenen gründe ;-) Für mich ist es einerseits spaß und andererseits brauche ich ein bisschen erfahrung für eine andere applikation. Und ein bisschen bei bestenden anwendungen abgucken kann ja nicht schaden :-)

Was macht die applikation? Es handelt sich dabei um ein plugin für wordpressblogs. Das plugin heißt WPBook. Es macht eigentlich nichts anderes als den RSS-Feed deines blogs in facebook zu veröffentlichen. Das geht sogar in deinem profil… allerdings nur in der widget bar… als profilreiter hatte ich probleme vorhin.

So… wie installiere ich das nun? ich habe es ja schon gesagt, ich werde hier kein neues how to do schreiben. Zum einen sollte man sich natürlich die installationshinweise des plugin machers anschauen (auch hier). Und ein sehr gutes tutorial hat DrWeb geschrieben.
Damit lässt sich das plugin und die applikation sehr gut einrichten. Und vorweg… es ist sehr leicht… also keine angst. ;-)

So… ich warte jetzt auf meine millionen besucher täglich und werde bei bedarf mal einen ansichtskarte von meiner eigenen südsee insel schicken. :-)

Viele Grüße (noch von der süd europa insel)
Gordon

Problem mit dem Email-Versand bei WordPress

/0 Kommentare/in /von

Hallo zusammen,

ich habe das Problem schon seid Tagen im Auge… aber irgendwie nie die Zeit gefunden. Heut hat es mich dann aber genervt. Der ein oder andere kennt das Problem vielleicht… Es wird ein Kommentar zu einem Artikel abgegeben und kurze Zeit später bekommt man eine Email vom MAILER DAEMON mit dem Betreff „failure notice“.

Nein, das ist weder Spam noch wird ihr Server als Spamschleuder missbraucht. Das ganze hat einen simplen Hintergrund. Sobal ein nicht Registrierter User einen Kommentar schreibt (oder auch bei div. anderen Aktionen) schickt WordPress automatisch eine Email an den Administrator (Seitenbetreiber). Das dumme dabei ist nur das diese Emailadresse anscheinend nicht vorgegeben werden kann und sie sich somit wir folgt zusammensetzt: „wordpress@“ + Domainname. Zum Beispiel „wordpress@domain.de“.
Existiert diese Emailadresse nun real gar nicht dann gibt es, unter umständen, eben den obigen Fehler da der Empfänger prüft ob die Absenderadresse wirklich existiert… tut Sie das nicht dann verweigert er schlichtweg die Annahme. Das registriert der Absenderserver und schickt ihnen obige Email die Sie einfach darüber informiert das die Email nicht zugestellt werden konnte. :( Blöd. Noch blöder ist das diese „wordpress@…“ Emailadresse im Script verankert ist und nicht so einfach geändert werden kann. Warum auch immer. Besonders da man im Adminbereich eine Admin-Emailadresse angegeben hat bzw. angeben kann.

Das nächste Problem was ich hatte ist das WordPress emails nur per mail() verschickt. Normalerweise sollte das kein Problem darstellen, bei mir schon.

Ich habe gerade, mal wieder, 2 Stunden in den Eingeweiden von Worpress rumgefummelt bis alles funktioniert hat. Dabei habe ich mir nicht jeden Schritt gemerkt und kann daher hier leider auch keine Detailierte Anleitung geben wie Sie das abstellen können.

Wenn es nur um Problem mit der „wordpress@…“ Adresse geht dann können Sie folgendes Probieren:

Schritt 1)

Öffnen Sie die „./wp-config.php“ mit einem Editor und fügen Sie nach allen anderen Werten die folgenden Zeilen hinzu:
//email
define (‚STD_MAIL‘, ‚***‚);
Ersetzen Sie die 3 Sternchen mit ihrer Emailadresse. Diese Variable setzen wir in der wp-config.php damit wir diese Emailadresse später schnell ändern können und nicht wieder in den Code müssen.

Schritt 2)

Öffnen Sie die Datei „./wp-admin/includes/upgrade.php“ mit einem Editor und suchen Sie nach der Zeichenkette „wordpress@“ (ca. Zeile 118). Die Zeile sollte wie folgt aussehen…
$message_headers = ‚From: „‚ . $blog_title . ‚“ <wordpress@‘ . $_SERVER…
… ändern Sie diese nun wie folgt ab…
$message_headers = ‚From: „‚ . $blog_title . ‚“ <‚ . STD_MAIL . ‚>‘;

Schritt 3)

Öffnen Sie die Datei „./wp-includes/pluggable.php“ mit einem Editor und suchen Sie nach der Zeichenkette „wordpress@“… Treffer 1 ca. bei Zeile 350 und ändern Sie diese wie folgt (die originalzeilen habe ich leider nicht mehr):
$from_email = STD_MAIL;
und Treffer 2 ca. bei Zeile 896:
$wp_email = STD_MAIL;

Das sollte es gewesen sein. Einfach mal ausprobieren. Falls ich etwas vergessen habe, schreibt bitte einen Kommentar hier im Artikel.

Zum Umstellen von Mail() auf SMTP kann ich leider noch weniger sagen. Nur das es einem nicht einfach gemacht wird. Auch hier könnte man im Adminbereich eine weiche einbauen… hat man aber leider nicht. Warum auch immer. Also wieder ab in den Code.

In der Datei „./wp-includes/pluggable.php“ nach der Zeile „$phpmailer->IsMail();“ suchen (ca. Zeile 377). Das ändern in $phpmailer->IsSMTP();. Dann gehts in die „./wp-includes/class-phpmailer.php“. Hier sind in der Datei weit oben die Variablen. Einige sind belegt und andere leer. Hier müssen Sie die SMTP VARIABLES mit ihren Werten ausfüllen. Dabei am besten gleich noch mal die $Mailer auf „smtp“ setzen.
Weiter unten im Script die Funktion „CreateHeader“ suchen und die folgende Zeile ändern:
if($this->Mailer != „mail“)
in
//if($this->Mailer != „mail“)
Also einfach auskommentieren. Sonst hat die Email keinen Betreff. Warum das da überhaupt drin ist frage ich mich… aber ok. Man muss nicht alles wissen, hauptsache es funktioniert.

Damit sollte auch der SMTP-Versand funktionieren.

Gruß
Gordon

Hinweis: Die verwendung meiner Codeschnipsel erfolgt auf eigene Gefahr! Ich übernehme auch keine Garantie auf Funktionstüchtigkeit (jeder Server ist anders konfiguriert. Bei Problemen können Sie hier aber gern einen Kommentar schreiben und wir suchen eine Lösung. ;)

WordPress – Kommentare sortieren

/0 Kommentare/in /von

Wo ich heute eh gerade in den Eingeweiden von WordPress rumfummel… ist mir auch gleich noch etwas aufgefallen. Bei mir zumindest, werden die Kommentare so sortiert das die neusten ganz unten stehen. Sorry, aber das find ich mal total doof. Falls doch mal etwas heißer Diskutiert wird, dann muss man jedes mal nach ganz unten scrollen. Ich finde es schöner wenn der letzte Eintrag ganz oben steht… und so gehts.

Öffnen Sie die Datei „7wp-includes/comment-template.php“ in einem Editor und suchen Sie die Function „function comments_template()“. Diese ist nicht sehr groß und damit gut Übersichtilich. Sie beinhaltet 3 SQL-Abfragen. In jeder dieser Abfragen findet man den String:

…ORDER BY comment_date“, …

Diesen Teil ändert man wie folgt ab:

…ORDER BY comment_date DESC„, …

Speichern und das wars. ;) Schon werden alle Kommentare andersrum sortiert ausgegeben.

Bitte beachten Sie. Alle Angaben auf dieser Seite sind ohne Gewähr und nur auf eigene Gefahr zu verwenden!

Gruß
Gordon