Archive Wordpress
Bibra-OnlineWordpress
1. September 2014

Recently, my provider had updated the server my webspace is hosted on to PHP 5 and while at first I didn’t notice anything wrong, there actually was a creeping background problem: all WordPress installations refused to send out any emails and in some cases even timeout error messages appeared from the PHPMailer module.

After some unsuccessful digging, I found a post on the bugtracker of PHPMailer regarding an incompatibility with PHP 5.2 – apparently there is a problem with this particular PHP version related to the Regex function. So if you suddenly have those error messages, like a timeout in class-phpmailer.php on line 879 in the case of WordPress, check what PHP version your webserver is running. In my case, the server defaults to 5.2, but I was able to switch it with the line AddHandler php55-cgi .php in the .htaccess file to 5.5 and then everything worked again.

If your webhost supports this method of switching to different PHP versions, this will fix the problem – if not, you have to ask your webspace hoster to switch versions or install a higher version yourself. Reportedly anything above 5.3 works, but I only tested it with 5.5 and it works fine with WordPress 3.9.2 and the release candidate of 4.0.

WeblinksWordpressWWW
14. December 2013

Another six months have come and gone and it’s again time for a new version of WordPress, this time with a complete visual overhaul of the admin interface. I like the slick new design with OpenSans as the new default font and while there are a few isolated things I don’t particularly like, I upgraded my websites anyway. But after each major upgrade, I have to redo a couple of small alterations in the code to make the built-in editor a little more comfortable – even with version 3.8 they are still necessary, so here they are again with some minor amendments.

HTML-Editor: The HTML source editor has been using Consolas as a fixed-width font since version 3.2, but the line height is still a bit to generous especially on smaller screens. The corresponding CSS definition can be found in the file wp-includes/css/editor.css, in which it is possible to change line-height: 150%; in the definition wp-editor-area (formerly textarea.wp-editor-area) to 120% or another desired value.

Visual Editor: The display font of the visual editor is still Times New Roman, but it can be changed in the CSS file wp-includes\js\tinymce\themes\advanced\skins\wp_theme\content.css by altering the font definition in the main .body tag from font-family: Georgia […] to another font like Verdana. There is also now the possibility to let the current theme decide what font is used in the visual editor – this apparently works by placing an editor-style.css file into the CSS directory of a theme, but it seems the only theme that supports it is the new TwentyFourteen coming with this new release of WordPress, which switches the font to OpenSans. I have not yet found out if the font style of the visual editor can be changed directly from the CSS of a theme, but it seems that the new default theme calls up the editor-style.css to make exactly this happen.

Get Shortlink: The shortlink button next to the permalink line sometimes pops into the next line on displays 1024 pixels wide, but the button description can be changed into something less huge. Searching for the string “Get Shortlink” in the file /wp-admin/edit-form-advanced.php and just changing it into something else does the trick. The button can, of course, also be completely removed by deactivating the Jetpack module WP.ME-Shortlinks, but this is of no use if the feature is needed and the button is still too big.

And, of course, it needs to be said that I do not provide any guarantee for these “hacks” – you have to know what you’re doing if you are tinkering around in the innards of the WordPress system files. But if you’re careful and know your way around, these changes will not harm you WordPress installation at all – they are only a cosmetic makeover and no change in the program code is made.

Google+Wordpress
15. September 2013

The post title says it all: it seems that Google is rethinking its stance against remote posting to Google+. A recent article on the main WordPress blog called Your Blog, Plus One: Connect and Share on Google+ announces that you can now share directly to Google+, link your blog to your G+ account, integrate comments and even embed G+ articles into WordPress posts. It’s the first one I’m very excited about, but at the moment all this still applies only to blog hosted on WordPress.com – however they promise that most of the features will also come to the Publicize module of the Jetpack plugin for self-hosted blogs. I just hope that most doesn’t mean that the sharing functionality will be left out!

The whole point of this is that I’ve become very fond of Google+ since I joined at the end of last year. At the beginning I was very reluctant to post because I couldn’t do it directly from WordPress, but over time I’ve found out that it works very well for me especially on the Photography Blog. The interaction between the users is what I like most – it’s not just about getting +1’s, the G+ equivalent of Likes, but really meeting other people, talking about what we like and what matters to us, and, of course, lots and lots of inspiration. Posting remotely from WordPress like I do on Facebook and Twitter will not change any of that – except that I may be able to plan better ahead when I’m actually able to post automatically. This is what Google doesn’t want to allow – but I don’t see anything wrong with e.g. letting the blog post an article and then later come back and see if there are any comments to answer. I’m certainly not going to abuse that, but it would make everything much easier.

I actually have one rule for myself: I will not post exclusively to Google+ or any other social network – everything that appears there will also be on one of my websites, with small exceptions like the occasional quick reshare and, of course, commenting. I may actually embed Google+ comments on my blogs in the future, because most people tend to comment on my postings over on G+ and hardly on the blogs itself – which I fully understand, because I’m also guilty of it myself. I would just like to link the WordPress postings to the comments on the corresponding Google+ article. But, in the light of what happened to CosmoQuest recently, I may decide against a direct comment integration – maybe just a backlink to the G+ article would be better if it can be done automatically.

But first let’s see what happens when the next Jetpack update comes – fingers crossed that this will really include posting from WordPress!

[Update 22.09.: There was a fairly large Jetpack update a couple of days ago with lots of Google+ connection stuff in there, but the Publicize module has not changed yet, so it’s still not possible to post from a self-hosted WordPress site to G+. They promised, however, that this is going to be implemented soon… but when is unclear.]

Bibra-OnlineWordpress
4. August 2013

It’s been over eight months since the last major release, but now WordPress 3.6 has been released, which meant an update marathon for me – and I haven’t even checked out the new features like the media player! After each major upgrade, I have to redo a couple of small alterations in the code to make working with the built-in editor more comfortable. I had last described the changes in December in a German-language article, but this time I’m translating the updated tips into English.

HTML-Editor: The HTML source editor has been using Consolas as a fixed-width font since version 3.2, but the line height is still a bit to generous especially on smaller screens. The corresponding CSS definition can be found in the file wp-includes/css/editor.css, in which it is possible to change line-height: 150%; in the definition wp-editor-area (formerly textarea.wp-editor-area) to 120% or another desired value.

Visual Editor: The display font of the visual editor is still Times New Roman, but it can be changed in the CSS file wp-includes\js\tinymce\themes\advanced\skins\wp_theme\content.css by changing the font definition in the main .body tag from font: 13px/19px Georgia […] to another font like Verdana.

Get Shortlink: The shortlink button next to the permalink line sometimes pops into the next line on smaller 1024x displays, but the button description can be changed into something less big. Search for the string “Get Shortlink” in the file /wp-admin/edit-form-advanced.php and just change it into something else. The button can, of course, also be completely removed by deactivating the Jetpack module WP.ME-Shortlinks, but this is of no use if the feature is needed and the button is still too big.

And, of course, it needs to be said that I do not provide any guarantee for these “hacks” – you have to know what you’re doing if you are tinkering around in the innards of the WordPress system files. But if you’re careful and know your way around, these changes will not harm you WordPress installation at all – they are only a cosmetic makeover and no change in the program code is made.

Bibra-OnlineWebdesignWordpressWWW
16. December 2012

Es ist mal wieder ein halbes Jahr rum und mit WordPress 3.5 ist vorige Tage das nächste große Update erschienen. Die Änderungen halten sich äußerlich wieder in Grenzen, geschraubt wurde vor allem in den Innereien – aber das ist ja kein Grund nicht zu updaten. Wie jedesmal habe ich wieder meine alten Tips zur Editor-Optimierung ausprobiert und wieder festgestellt, daß alles immer noch genauso funktioniert:

HTML-Editor: Der HTML-Quellcode-Editor verwendet schon seit Version 3.2 Consolas als Zeichensatz, aber die Zeilenhöhe ist immer noch zu groß. Die entsprechende CSS-Definition ist seit Version 3.3 in der Datei wp-includes/css/editor.css vorhanden: man kann unter textarea.wp-editor-area die Zeile line-height: 120%; hinzufügen oder auf einen anderen gewünschten Wert ändern.

Visual Editor: funktioniert genauso wie bei den vorherigen Versionen. Der Anzeige-Font des Visual Editors läßt sich immer noch nur über die CSS-Datei wp-includes\js\tinymce\themes\advanced\skins\wp_theme\content.css verändern. Dort genügt es, die Zeichensatzdefinition im Body-Tag von font: 13px/19px Georgia […] auf einen gewünschten Font wie Verdana zu ändern.

Get Shortlink: hat sich gegenüber V3.3 auch nicht geändert. Um die Beschriftung dieses zu großen Buttons, der auf kleinen Displays manchmal in die nächste Zeile umbricht, zu ändern, muß man in der Datei /wp-admin/edit-form-advanced.php nach dem Text “Get Shortlink” suchen (ist nur einmal vorhanden) und ihn auf eine kürzeren Text ändern. Deaktivieren läßt sich der Buttons übrigens auch, indem man im Jetpack-Plugin das Modul WP.ME-Shortlinks ausschaltet – aber das nützt nichts, wenn man die Shortlinks trotzdem braucht und der Button doch zu groß ist.

Und was wie üblich gesagt werden muß: ich übernehme keinerlei Garantie für diese “Hacks”, man sollte also schon wissen, was man tut, wenn man in den Innereien von WordPress herumbastelt.

Bibra-OnlineWebdesignWordpress
14. June 2012

WordPress 3.4 ist gestern erschienen, und die ganzen Upgrades waren doch nicht so Zeitintensiv wie ich gedacht hatte. Version 3.4 ist kein riesiges Update, denn soviel hat sich auf den ersten Blick gar nicht getan – gebaut wurde hauptsächlich unter der Oberfläche. Die Tips zur Editor-Optimierung, die ich seit jeder neuen Version wieder neu einbauen muß (und die natürlich immer noch nicht implementiert wurden), funktionieren auch mit der neuen Ausgabe, allerdings hat sich bei der ersten Bastelei etwas verändert.

HTML-Editor: Der HTML-Quellcode-Editor verwendet vernünftigerweise schon seit Version 3.2 Consolas als Zeichensatz, aber die Zeilenhöhe ist immer noch zu groß. Die entsprechende CSS-Definition ist jetzt in einer anderen Datei zu finden als in Version 3.3: in wp-includes/css/editor.css kann man jetzt unter textarea.wp-editor-area die Zeile line-height: 120%; hinzufügen oder auf den entsprechenden Wert ändern (bei meiner Installation war die Zeile schon da und stand auf 150%.)

Visual Editor: funktioniert genauso wie bei Version 3.3. Der Anzeige-Font des Visual Editors läßt sich immer noch nur über die CSS-Datei wp-includes\js\tinymce\themes\advanced\skins\wp_theme\content.css verändern. Hier genügt es aber jetzt, die Zeichensatzdefinition im Body-Tag von font: 13px/19px Georgia […] auf einen gewünschten Font wie Verdana zu ändern.

Get Shortlink: hat sich gegenüber V3.3 auch nicht geändert. Um die Beschriftung dieses oft zu großen Buttons zu ändern, muß man in der Datei /wp-admin/edit-form-advanced.php nach dem Text “Get Shortlink” suchen (ist nur einmal vorhanden) und ihn auf eine kürzeren Text ändern. Deaktivieren läßt sich der Buttons übrigens auch, indem man im Jetpack-Plugin das Modul WP.ME-Shortlinks ausschaltet – aber das nützt nichts, wenn man die Shortlinks trotzdem braucht und der Button doch zu groß ist.

Und was gesagt werden muß: ich übernehme keinerlei Garantie für diese “Hacks”, man sollte also schon wissen, was man tut, wenn man in den Innereien von WordPress herumbastelt.

Bibra-OnlineWebdesignWordpressWWW
15. May 2012
B

Schon wieder über einen Monat Funkstille, aber diesmal habe ich einen besonderen Grund gehabt: das neue Template ist fertig und ich wollte vorher nichts neues mehr posten. Fast genau vier Jahre, nachdem ich Bibra-Online auf WordPress umgestellt hatte, gibt es jetzt ein Design-Facelifting: Version 3.0 der Webseite ist weniger eine komplette Umgestaltung als ein völliger technischer Neuaufbau des Templates, das ich nun komplett von Grund auf selbst geschrieben habe und dabei viele Probleme und Ungenauigkeiten beseitigen konnte. Wie ich schon im letzten Posting erwähnt hatte, gab es bei der Umsetzung vom HTML-Gerüst ins WordPress-Template ein paar Rätsel zu lösen, aber nachdem ich die letzten Nüsse geknackt hatte, ging es relativ schnell und streßfrei.

Der größte Unterschied befindet sich unter der Haube, denn das Template verwendet CSS3-Technik und benutzt für Zeichensätze, runde Ecken und Farbverläufe keine Grafiken mehr, sondern nur noch reinen CSS-Code. Dadurch ist vieles viel einfacher geworden und Sachen, für die vorher eine eigene Grafik notwendig gemacht haben, können jetzt durch eine kleine handvoll CSS-Befehle erzeugt werden. Sogar das Logo rechts oben ist keine Bitmap mehr, sondern nur ein CSS-Rahmen mit Farbverlauf und ein großer Buchstabe mit eingebundenem Font. Einen Nachteil hat das ganze allerdings: während die neuesten Versionen vom Firefox, Opera, Chrome und Safari problemlos damit zurechtkommen, klappt es mit keiner Version des Internet Explorers mehr, auch nicht 8 und 9. Deswegen gilt ab jetzt das, was ich schon vor einiger Zeit angekündigt hatte: diese Seite funktioniert nicht mehr mit dem Internet Explorer! Es ist im Moment noch keine Browserweiche eingebaut, aber in Zukunft werde ich wohl eine Warnung für Besucher anzeigen, die mit dem Microsoft-Browser unterwegs sind.

Die Änderungen an der Oberfläche halten sich in Grenzen, aber ich habe einige völlig redundante Elemente wie den ganzen Blog-Header rausgeworfen, das Logo ins Hauptmenü gesetzt und einige Links aus dem Header in die Sidebar gepackt. Statt Grafiken wird nun ein per @font-face eingebundener Zeichensatz für die Logos und Buttonns verwendet, für den ich leider den früheren Font, HandelGothic, nicht benutzen konnte, da ich keine Webfont-Lizenz für ihn besitze – stattdessen habe ich nach langer Suche bei Fontsquirrel Sansation gefunden, den ich schon für das Logo von Bibra-Medien benutzt hatte und der mir hier noch besser gefällt. Außerdem habe ich das Kommentar-Formular komplett neu gestaltet und viele kleinere Änderungen im Design gemacht, um die ganze Webseite ein klein bißchen professioneller aussehen zu lassen. Ganz konnte ich mich aber nicht von dem alten Design trennen, aber vielleicht kommt das mit Version 4.0 in ein paar Jahren.

Das Facelifting betrifft im Moment nur das Blog selbst – wenn man auf die anderen alten Seiten klickt, erscheint noch der frühere Header. Ich habe noch keine Lust gehabt, das zu ändern, weil sich der neue Header nicht ganz so einfach in das alte Frame-Layout einbauen läßt und ich dafür die alten Seiten nochmal überarbeiten müßte. Das kommt dann in Phase 2, die ich auf jeden Fall im Laufe des Jahres angehen werde: die Seiten Bücher, Musik, Computer, Spiele und Sim werden dann ins WordPress-System integriert und auf deren jeweiligen Einstiegsseiten werden Postings aus der passenden Kategorie von der Hauptseite angezeigt. Dazu muß ich mir aber noch etwas zur Gestaltung einfallen lassen, denn die derzeitigen Seiten sind so alt, daß man sie im Prinzip nur noch wegwerfen kann. Und das werde ich nach und nach demnächst auch tun und mal etwas ganz anderes zu den Themen versuchen.

Das neue Template für Bibra-Online ist erstmal ein kleiner Renovierungs-Schritt, der hauptsächlich dazu da ist, mich zu motivieren, hier in Zukunft wieder mehr zu schreiben. Ich werde zwar nicht wieder damit anfangen, dauernd die Artikel vom DVDLog und vom Foto-Archiv zu doppeln, aber mit dem neuen Design habe ich auch wieder Lust, mehr zu anderen Themen zu schreiben. Jetzt muß ich aber erstmal noch eine kleine Pause einlegen, aber danach gehts mit irgendetwas weiter :-).

Bibra-OnlineWebdesignWordpress
15. December 2011

Es ist mal wieder soweit, WordPress 3.3 ist fertig und damit ist wie immer auch eine Update-Orgie verbunden, die ich zum Glück jetzt schon hinter mir habe. Die neue Version hat gegenüber der vorherigen Ausgabe einige interessante Neuerungen mit sich gebracht – insbesonders ist der Admin-Bereich noch schlanker geworden und macht auch auf kleineren Auflösungen jetzt keine Probleme mehr. Meine Tips zur Editor-Optimierung, die ich im September 2010 das letzte Mal gepostet hatte, funktionieren wegen dem stark veränderten CSS-Code leider nicht mehr so wie damals angegeben, aber ich habe mir das mal angeschaut und die wichtigsten beiden Änderungen wiedergefunden:

HTML-Editor: Der HTML-Quellcode-Editor verwendet vernünftigerweise schon seit Version 3.2 Consolas als Zeichensatz, aber die Zeilenhöhe ist immer noch zu groß. Die entsprechende CSS-Definition in der Datei wp-admin/css/wp-admin.css heißt jetzt textarea.wp-editor-area, zu der man die Definition line-height: 120%; hinzufügen sollte.

Visual Editor: Der Anzeige-Font des Visual Editors läßt sich immer noch nur über die CSS-Datei wp-includes\js\tinymce\themes\advanced\skins\wp_theme\content.css verändern. Hier genügt es aber jetzt, die Zeichensatzdefinition ganz am Anfang im Body-Tag von font: 13px/19px Georgia […] auf einen gewünschten Font wie Verdana zu ändern.

Get Shortlink: Um die Beschriftung dieses oft zu großen Buttons zu ändern, muß man in der Datei /wp-admin/edit-form-advanced.php nach dem Text “Get Shortlink” suchen und ihn auf eine kürzeren Text ändern. Deaktivieren läßt sich der Buttons übrigens auch, indem man im Jetpack-Plugin das Modul WP.ME-Shortlinks ausschaltet – aber das nützt nichts, wenn man die Shortlinks trotzdem braucht und der Button trotzdem zu groß ist.

Wie immer übernehme ich keine Garantie für diese “Hacks”, man sollte also schon wissen, was man tut, wenn man in den Innereien von WordPress herumbastelt.

Bibra-OnlineDVDLogWebdesignWordpress
26. August 2011

Ich bin ja jetzt schon einige Jahre mit meinem Webseiten im Internet präsent, aber das ist mir noch nie passiert: am 23. und 24. August ist ein Teil meiner Webseiten gehackt worden. Genauer gesagt hatte sich jemand mit einer rumänischen IP-Adresse Zugang zu den FTP-Servern von Bibra-Online.de und DVDLog.de verschafft und dort fremden Code in zahlreiche Dateien eingeschleust. Was genau dieser Code letztendlich verursacht, ist mir noch unbekannt, aber aufgefallen ist mir der Angriff zuerst, weil meine Webseiten anfingen von fremden Domains irgendetwas nachzuladen.

Ich kann aber Entwarnung geben: in einer Mords-Aktion habe ich noch gestern Abend sämtliche manipulierten Dateien durch saubere Backups ersetzt. Ich kann bei den tausenden von Dateien nicht ausschließen, daß ich dabei etwas vergessen habe, aber alles im Hauptverzeichnis von Bibra-Online inklusive den DVD-Kritiken sowie die WordPress-Installationen sind jetzt wieder sauber. Der Angriff scheint nicht von WordPress ausgegangen zu sein und es wurden sowohl reine HTML-Dateien als auch PHP-Skripte manipuliert.

Wer aber vom Abend des 23. bis zum Abend des 25. August auf Bibra-Online oder DVDLog zugegriffen hat und dem dabei etwas merkwürdiges aufgefallen ist – bitte unbedingt bei mir melden! Ich hoffe, daß ich mit meinen Webseiten durch diesen Zwischenfall keine Viren oder ähnliches verbreitet habe, aber ganz ausschließen kann ich das im Moment noch nicht. Allerdings habe ich in dieser Zeit auch auf die Webseiten zugegriffen und mein Virenscanner hat nicht angeschlagen, so daß da hoffentlich nicht drastisches passiert ist.

Im Moment bin ich noch dabei, die Scherben aufzufegen und mehr über den Angriff herauszufinden – sollte es Neuigkeiten dazu geben, werde ich mich an dieser Stelle natürlich wieder melden.

[Update vom 27.8.: Wie der Angriff zustande gekommen ist, bleibt nach wie vor völlig unklar. Mein Provider meint natürlich, daß es nur an ausgespähten Passwörtern gelegen haben kann, was ich aber auf meiner Seite wiederum hundertprozentig ausschließen kann. Was genau die manipulierten Webseiten angestellt haben, weiß ich auch noch nicht genau, da ich noch nicht dazu gekommen bin, mir die gesicherten Dateien unter kontrollierten Bedingungen anzuschauen. Auf den Webservern befinden sich aber definitiv keine infizierten Dateien mehr und es hat auch keine neuen Angriffe mehr gegeben.]

WebdesignWordpress
23. March 2011

Wer auf seinen eigenen WordPress-Installationen das Statistik-Plugin von WordPress.com benutzt, wird seit letzter Woche bemerkt haben, daß einiges durcheinander gekommen ist. Ich war nicht der einzige, bei dem im Dashboard nur noch eine Fehlermeldung angezeigt wurde, daß der WordPress.com-User keine Erlaubnis zum Anschauen der Statistik besitzt. Bei mehreren Blogs, die den gleichen WordPress.com-Account für die Statistiken benutzen, ging außerdem anscheinend die Verknüpfung verloren, so daß die Statistiken erst gar nicht mehr im globalen Dashboard von WordPress.com angezeigt wurden.

Der Grund für diese Probleme ist bis jetzt noch unbekannt und offenbar hat sich von WordPress noch niemand dazu geäußert, aber es gibt zum Glück eine einfache Lösung: das Statistik-Plugin deaktivieren und stattdessen Jetpack installieren. In dieser Sammlung von verschiedenen Tools, die von WordPress.com angeboten werden, sind auch die Statistiken enthalten und wenn man Jetpack mit dem gleichen WordPress.com-Account verknüpft, mit dem man auch das alte Plugin betrieben hat, sind alle alten Statistiken noch da. Zum Anschauen der Statistiken braucht man jetzt nicht mehr zwingend einen eigenen, für die Statistiken authorisierten WordPress.com-Account, sondern muß nur registrierter Benutzer auf dem jeweiligen Blog sein. Die anderen Funktionen von Jetpack kann man deaktivierten, unter anderem auch den von mir so ungeliebten Get Shortlink-Knopf im Editor, aber andere Sachen wie die Integration von Youtube & Co. sind vielleicht doch ganz nützlich.

Mehr zu der neuen Version 3.1 von WordPress demnächst noch in einem eigenen Artikel.