Ich hatte seit längerem Probleme auf den Visual Editor meiner WordPress-Installation zuzugreifen. Da ich allerdings in letzter Zeit auch nicht viele Artikel geschrieben hatte, war es nicht ein eklatantes Problem, da ich einige Artikel auch per Smartphone erstellt habe. Als ich nun mehrere Artikel, die ich in meiner Pipeline habe bearbeiten wollte, fiel es mir wieder auf

Nach den üblichen Kontrollen, ob der “Visual Editor” evtl in der Software bzw. meinem Benutzerprofil abgeschaltet war, wurde ich auf die folgende Lösung aufmerksam zu der man eine Anpassung durchführen muss.In der Datei “wp-config.php” habe ich folgende Erweiterung durchgeführt:

// Anpassung zum Script Debugging

 define(‘SCRIPT_DEBUG’, true);

Dieses muss vor der Zeile hinzugefügt werden ab der man nichts mehr ändern soll.

Entsprechend stehen mir nun wieder alle Funktionen des “Visual Editor” zur Verfügung.

Nach dem Schreiben des gestrigen Artikels fiel mir auf, dass gar kein Twitter-Post versandt wurde. Dabei viel mir ein, dass mein Blog mir angezeigt hatte, dass ich das WordPress-Plugin “Twitter-Tools” nicht mehr nutzen könnte und auf  das Plugin “Social” wechseln sollte.

Die Installation des Plugins selber sowie auch die Verknüpfung ging reibungslos. Als erstes entfernte ich aus der Formatzeile, welche unter “Einstellungen” – “Social” zu finden ist, die Variable “{content}” und fügte das bereits bekannte “BlogPost:” hinzu. Dieses wird von manchen Lesern bei mir extra positiv oder auch negativ gefiltert.

Beim ersten Test wurde mir leider der Link im WP.me-Format in einer von mir nicht gewünschten Art eingefügt. Aus diesem Grund deaktivierte ich die Funktionalität der WP.me Kurzlinks. Dieses brachte mich zwar der Lösung einen Schritt näher. Nun wurden die Links im WordPress-Standard (wordpress.tld/?p=0000) angezeigt.

Nach ein wenig Recherche im Plugin fand ich 4 Zeilen, die man anpassen muss, um dort den von mir favorisierten Permalink einzufügen:

Datei: wp-content\plugins\social\lib\social\service.php

Version 2.5: Zeile 386
Version 2.6: Zeile 401
Version 2.7: Zeile 398
Version 2.8: Zeile 398

$url = get_permalink($post->ID);

Version 2.5: Zeile 462
Version 2.6: Zeile 483
Version 2.7: Zeile 481
Version 2.8: Zeile 481

$url = get_permalink($comment->comment_post_ID);

Datei: \wp-content\plugins\social\social.php

Version 2.5: Zeile 140
Version 2.6: Zeile 139
Version 2.7: Zeile 140
Version 2.8: Zeile 140

$url = get_permalink($post->ID);

Version 2.5: Zeile 1121
Version 2.6: Zeile 1142
Version 2.7: Zeile 1146
Version 2.8: Zeile 1146

$shortlink = get_permalink($post_id);

Nun werden die Links wieder wie gewohnt angezeigt und auch entsprechend versandt.

Kleiner Tipp am Rande:

Wenn man dieses Plugin aktiviert ist es auch möglich die Kommentarfunktion per Twitter oder Facebook-Authentifizierung zu nutzen, dieses kann man in den Einstellungen unter “Advanced Options” mit einem Haken bei der Option “Disable Social’s comment display (use standard theme output instead). ” unterbinden.

In der letzten Woche wollte ich aus diesem meinem Blog ein paar vorbereitete Code-Zeilen kopieren und Sie in einem Programm verwenden. Dieses wurde, trotz keiner Änderung am kopierten Code, mit reichlich Fehlermeldungen quittiert. Ich wusste, dass diese Code in genau dieser Form und der selben Umgebung bereits funktioniert hatte.

Nach einer längeren Analyse vielen mir nun doch Veränderungen am Code auf, der technisch zwar richtig war, aber aufgrund des Designs im Blog leider “angepasst” wurden. Um dieses zu umgehen habe ich ein Plugin installiert und alle mir bekannten Artikel mit Code-Zeilen am Wochenende aktualisiert.

Bei dem Plugin handelt es sich um “DevFormatter”, der bis zu 202 Programmiersprachen unterschiedlich darstellen kann. Somit sollte nun allen der Zugriff auf die Codezeilen erleichtert worden sein.

Link

Seit gestern ist die englische Version von WordPress 3.1.2 verfügbar.
Diese wurde aufgrund eines Sicherheitsproblems zur Verfügung gestellt:

This release addresses a vulnerability that allowed Contributor-level users to improperly publish posts

Ein Update ist wie gewohnt über das WordPress-Dashboard möglich.
Erfahrungsgemäß lässt dann die deutsche Version nicht lange auf sich warten.

Weitere Informationen:
Link

Update:
Die deutsche Version ist auch verfügbar und machte bei der Installation in meinem Blog keine Probleme

Gestern Abend stand ein Update eines Plugins in einer meiner WordPress-Umgebungen an, die ich zum Testen verwende.
Nach dem das Update durchgeführt wurde, konnte ich allerdings weder auf das Frontend oder noch auf das Backend zugreifen., da eine nich von mir erstelle Wartungsseite erschien.

Da ich eine Dateiüberwachung auf dem Blog eingerichtet hatte, wurde mir dort deutlich angezeigt, dass eine Datei “.maintenance” im Root-Verzeichnis des Blog erstellt wurde. Als ich mir diese mit einem Editor ansah, fand ich die zuvor gesehenen Angaben auf der Wartungsseite wieder.

Durch ein Umbenennen der Datei bekam ich wieder den gewohnten Zugriff und das Update wurde mir erneut als zu installieren angezeigt. Dieses versuchte ich dann direkt noch einmal, was diesmal auch ohne Probleme funktionierte. Inzwischenzeit habe ich die “schuldige” Datei auch gelöscht und bin somit wieder auf dem aktuellen Stand der Updates

Wie ich bereits gestern berichtete, habe ich mich mit Sperrungen von WordPress-Seiten beschäftigt. Dazu gehörte auch, dass trotz des Einsatz des Tools Authenticator, ein Abruf der RSS-Feeds möglich war und so entsprechend auf die veröffentlichten Daten hätte zugegriffen werden können.

Um die Feeds zu deaktivieren muss im jeweiligen Theme der folgende Code in die functions.php eingebunden werden:

function fb_disable_feed() {
    wp_die( __(‘Kein Feed erreichbar, besuchen Sie doch bitte die <a href=”‘. get_bloginfo(‘url’) .’”>Startseite</a>!’) );
}

add_action(‘do_feed’, ‘fb_disable_feed’, 1);
add_action(‘do_feed_rdf’, ‘fb_disable_feed’, 1);
add_action(‘do_feed_rss’, ‘fb_disable_feed’, 1);
add_action(‘do_feed_rss2′, ‘fb_disable_feed’, 1);
add_action(‘do_feed_atom’, ‘fb_disable_feed’, 1);

Sollte diese Datei nicht existieren, kann diese um die Funktionalität umzusetzen, angelegt werden.

Aufgrund einer persönlichen Anfrage habe ich mich am Wochenende mit der Sperrung von WordPress-Blogs beschätigt.
Der Hintergrund: Auf diesen Blog sollen nur gewisse Personen Zugriff erhalten. Standardmäßig ist allerdings ein Blog für alle Lesbar bzw. die Artikel können per Passwort geschützt werden.

Nach ein wenig Recherche kam ich an das Tool Authenticator. Dieses schaltet bei nicht angemeldeten Benutzern automatisch die WordPress-Loginseite vor den Blog. Somit muss man erst seinen Benutzernamen und sein Passwort eingeben, bevor man zu einem Artikel oder den Blog Zugriff erhält. Gepaart mit dem bereits vorgestellten Plugin Limit Login Attempts ist das eine sehr akzeptable Lösung ungewollte Zugriffe zu vermeiden.

Desweiteren sollte man natürlich auch die Suchmaschinen über die Einstellungen des Blogs verbannen, dann ist die Gefahr, dass der Blog gefunden wird auch bereits deutlich geringer.