No big deals. Just a few stories from my life.
Das Plugin “Jetpack” (für WordPress) hat aus seinen Statistikdaten einen Jahresrückblick für 2013 für diesen Blog erstellt.
Wen es interessiert, der kann die Daten unter:
http://jetpack.me/annual-report/44218100/2013/
aufrufen. Ist durchaus interessant und lesenswert. Vor allem, wenn man sich mal so ein paar Details rauspickt, kann man schon recht interessante Schlüsse ziehen. 😉
Wenn ihr dieses Zeilen lest, dann hat sich mein Zugrundeliegens CMS bereits auf die Version 3.8 aktualisiert. Heute ist nämlich diese Version von WordPress erschienen. Nach dem Update (bei mir von 3.7.x) auf 3.8 fällt als erstes das neue Backend-Theme ins Auge und ich muss sagen, dass mit das neue Layout und die damit einhergehende neue Typographie (Open Sans als Schriftart) sehr gut gefällt. Die neue Optik im Adminbereich wirkt ausgeräumter und frischer. Einfach irgendwie zeitgemäßer. Bei der Farbwahl bin ich beim dunklen Standard geblieben. Wirkt auf mich am schlüssigsten und wirkt edel.
Ansonsten fallen erst mal keine großartigen Veränderungen im Backend auf. Was vielleicht auch gut ist, da man sonst vielleicht die User zu sehr überfordern würde.
Für mehr Infos empfehle ich folgende Seite: http://wordpress.org/news/2013/12/parker/
Auch das neue WordPress Theme “Twenty Fourteen” gefällt mir und finde ich deutlich gelungener als dessen Vorgänger aus den vorangegangenen Jahren. Ich war davon so angetan, dass ich es auf einem Partner-Blog gleich mal aktiviert habe, weil mir das Layout dort eh etwas altbacken vorkam. Werft mal einen Blick rüber zu: www.apple-swat.de 😉
Abschliessend möchte ich sagen, dass ich die WordPress Version 3.8 als gelungen und einsatzfähig halte und jeden (bis jetzt) mal zu dem Update raten kann.
Eine Bekannte von mir, die leidenschaftlich gerne Videos mit iMovie macht, wollte ihre Filme in ihren WordPress Blog integrieren, diese aber jedoch nur einen überschaubaren Nutzerschaft anbieten. Die erste Hürde war die Datenmenge. ein 16 minütliches Video hat in mp4 und “mittlerer Größe” (Export-Einstellung im iMovie) ca. 190 MB. Also garnicht so wenig. Im Webhosting Paket bei STRATO nachgeschaut, ok wird hätten 5 GB Speichervolumen.
Allerdings kann man bei Strato das Upload Limit nicht höher als auf 30 MB setzten, womit die Filme schon mal ausscheiden. Also haben wir uns überlegt, dass wir dann eine Online-Video-Plattform für die Speicherung und das Bereitstellen verwenden wollen. Aufgrund der sehr weiten Verbreitung haben wir erst mal bei YouTube geschaut.
Dort kann man ein Video hochladen und dieses dann auf “Privat” setzten. Anschliessen könnte man verschiedene Emailadresse eingeben, die diesen Film ansehen dürfen. Problem hierbei ist, dass diese Emailadresse von Google/YouTube Account sein muss. Nun möchten wir aber nicht jeden dazu verdonnern, sich einen solchen Zugang anlegen zu müssen.
Also haben wir weiter geschaut und sind bei Vimeo fündig geworden. Dort ist es nämlich möglich nach den Video-Upload den Film mit einem Passwort zu schützen. Nur wer dann dieses Kennwort weiß und eingibt, darf den Film (online) ansehen. Somit ist kein gesonderter Account bei Vimeo von Nöten.
Des weiteren kann man dann in den Sharing-Option einen Code erstellen lassen, der dann das Video in einem iFrame laufen lässt. Dort kann man einiges einstellen. Wie zum Beispiel, ob der Titel oder der Ersteller im Thumbnail zu sehen sein soll oder nicht. Hat man all diese Einstellungen nach seinen Bedürfnissen vorgenommen, so kopiert man sich den kompletten Code und für diesen in der “HTML-Ansicht” (also im WordPress-Editor nicht mit “Visuell”, sondern im “Text”-Modus) ein. Schwupps und schön läuft das Vimeo-Video in einem WordPress Artikel oder aber auch in einer WordPress Seite. Und alles ist mit einem Passwort geschützt, damit nur die Personen, denen wir dass Passwort zukommen lassen auch das Video einsehen können. Perfect Day. 🙂
Ich habe bei “Jetpack” einen recht interessanten Artikel gefunden, der beschreibt, wie man ein Default-Fallback-Bild in WordPress definieren kann, wenn beim Artikel kein Bild gefunden werden kann.
Den Beitrag findet ihr unter: http://jetpack.me/2013/10/15/add-a-default-fallback-image-if-no-image/
Muss mir dass mal bei Gelegenheit genauer anschauen…
Dies ist nur für mich als Gedächtnisstütze, da ich heute etwas Zeit vertan habe, bis ich einen Bereich in einem CSS scrollbar machen konnte.
article { display: block;
max-width: 980px;
height: 600px;
overflow: scroll;}
Ich wollte heute bei einer WordPress-Seite nicht, dass irgendwas von der WordPress-Kommentarfunktion im Frontend zu sehen ist. Ich verwendete das “Nano”-Theme von Yoothemes.com und nach etwas suchen bin ich auch einen sehr eleganten Weg gestossen, wie man dies anstellen kann.
Ich habe es so gemacht, dass ich die Datei “comments.php” im Verzeichnis “wp-content/themes/yoo_nano_wp/warp/systems/wordpress3.0/layouts” einfach umbenannt habe und schon war nichts mehr von irgendwelchen Kommentarmöglichkeiten zu sehen.
Ein weiteres Background-Image-Manager-Plugin hab ich gefunden, welches eine Unzahl an Einstellungen mitbringt. Und genau das ist der große Vorteil von “Background Manager“. Man kann alles, aber wirklich alles einstellen. Wenn dies gewünscht oder gefordert ist, dann ist dieses Plugin die erste Wahl.
Plugin-URL: http://wordpress.org/plugins/background-manager/
Heute hatte ich mal die Anforderung, dass ich in einer WordPress-Seite ein Hintergrund einbauen sollte. Ich hab so was schon mal gemacht, aber dazu bin ich damals in die CSS-Dateien gegangen und hab dort von Hand das Hintergrundbild eingefügt.
Nachdem wir verschiedene Hintergründe testen wollten, hab ich mir gedacht, ich schau mal, ob es nicht einen einfacheren Weg als die CSS-Variante gibt. Und bin fündig geworden.
Das WordPress Plugin “Simple Full Screen Background Image” fügt auf elegante und simple Art und Weise Hintergrundbilder für einen Blog ein. Dazu berechnet es die Bildgröße neu, wenn man das Browserfenster in der Größe verändert.
Das war genau das, was ich gesucht habe. 😉
In einem Anflug von “Kreativität” hatte ich heute mal den Gedanken, dass es doch ganz nett wäre, wenn meine Instagram-Fotos auch in meinem WordPress-Blog (also hier) auftauchen würden. Ich bin auf ein Plugin gestossen, dass genau diese Funktionalität mitbringt und war davon begeistert, wie schnell und einfach man es zum Laufen bekommt.
Dank hier auch an Peter “Bodenseepeter”, durch dessen guten Artikel ist erst auf das Plugin aufmerksam wurde. Seinen Post findet ihr unter: http://www.bodenseepeter.de/2012/10/31/instagram-schon-in-wordpress-integrieren/
Das Plugin selbst könnt ihr dann unter folgender Adresse runterladen und im Anschluss installieren:
http://wordpress.org/plugins/instagrate-to-wordpress/
Folgende Einstellung hab ich bei mir am Laufen:
Irgendwie hat mich das schlechte Gewissen schon seit längerem geplagt, weil ich kein Sicherungskonzept für meine WordPress-Webseiten am Start habe und mach sich doch Gedanken macht, was wäre, wenn diese Daten futsch sind.
Erneut aufmerksam auf dieses Thema wurde ich vor einigen Tagen durch einen guten Artikel auf ElmaStudio (http://www.elmastudio.de/wordpress/sichere-deine-wordpress-seite-mit-regelmaessigen-backups/), in dem die verschiedenen Backup-Möglichkeiten vorgestellt wurden. Neben den kostenpflichtigen Diensten (wie VaultPress) wurde auch mein “alter Bekannter” BackWPup erwähnt und vorgestellt.
Ich hab dieses WordPress-Plugin auch in der Vergangenheit schon des öfteren ausprobiert, jedoch immer ohne Erfolg. Der Sicherungsauftrag wurde immer wegen irgendwelcher gravierender Fehler abgebrochen und somit nicht fertig gestellt. Wobei es bei mir egal war, ob ich die Sicherungsdateien auf die Dropbox, Amazon S3 oder mir per Email schicken lassen wollte.
Den Post hab ich nun zum Anlass genommen, dass ich mir dieses Plugin wieder anschaue und die neuste Version bei mir installiere. Meine Hoffnung war, dass sich durch den aktuellsten Programmstand irgendwas verändert hat, was eine erfolgreiche Sicherung bei mir ermöglicht.
Mir würde an diesem kostenlosen Plugin gefallen, dass es erstens nichts kostet und zweitens vielfältige Konfigurations-Möglichkeiten hat. Doch leider lief auch die aktuellste Version bei mir wieder nicht und mein Backup-Versuch auf die Dropbox schlug wieder fehl.
Die Fehlermeldung, die in den Log-Files auftauchte lautete:
FEHLER: Allowed memory size of 268435456 bytes exhausted (tried to allocate 234618881 bytes)
Ok, hab ich mir gedacht, vielleicht reicht der Speicher nicht, jedoch ich aus der Fehlermeldung nicht erkennen konnte, ob der RAM oder “Festplatten”-Speicher gemeint war. Ich hatte auch noch kurz den Verdacht, ob es vielleicht am vom mir getesteten Email-Versand lag und hier die max. Speichergröße für Nachrichten überschritten wurde. Somit stellte ich in meinem nächsten Versuch bei der Nachrichtengrößte die “0” (Null) ein, was bedeutet, dass es keinerlei Beschränkung geben würde.
Aber leider schlug auch der nächste Test mit obiger Fehlermeldung fehlt.
Irgendwann kam mir dann der Gedanke, dass wenn es möglicherweise am RAM-Speicher liegen könnte, dass es vielleicht im Zusammenhang mit dem verwendeten Packformat (ZIP) zusammen hängt. Und so stellte ich einfach mal kurzer Hand auf das TAR-Format um und änderte den Ablageort von der Dropbox zu einem lokalen Ordner.
Und siehe da. die Sicherung läuft nun durch. Und was auch bemerkenswert ist, die Sicherung, die davor nach ca. 1 Stunde abbrach, ist jetzt in ca. 3 Minuten erfolgreich durchgelaufen.
Ein Blick mit einem FTP-Programm (bei mir Transmit von Panic) in den Ordner auf dem Server zeigte mir dann eine TAR-Datei mir rund 1,2 GB Größe. Damit diese Datenmenge nicht meinen Server dicht macht, hab ich mir die Sicherungsdatei dann auf meinen lokalen Rechner geholt und lege sie hier hab.
Fazit und Erkenntnis:
Vielleicht wäre das WordPress-Plugin BackWPup auch schon früher bei mir erfolgreich gelaufen, wenn ich die richtigen Einstellungen verwendet hätte. Ich möchte euch somit hiermit den Denkanstoss auf den Weg geben, nicht nur die für euch am bequemste Sicherungsmethode auszuprobieren, sondern auch mal einen anderen Weg (bei mir TAR mit Sicherung in einen Ordner) auszutesten.
Ich bin jetzt erst mal froh, dass die Sicherung nun bei mir läuft und werde in den kommenden Tagen noch etwas damit rum experimentieren. Vielleicht finde ich ja noch was heraus, was den Sicherungslauf etwas mehr automatisiert und ich mir dann nicht mehr die Dabei per FTP holen muss. 😉
Vor einiger Zeit bekam ich bei dem Versuch mich ans Backend dieses Blog anzumelden folgende Fehlermeldung. Das Ganze kam mir relativ komisch vor, weil mir nichts bewusst war, was ich verändert hätte. Keine Dateiänderungen per FTP oder irgendwelche WordPress-Updates, die ich installiert hätte.
"Forbidden. You don't have permission to access /wp-login.php on this server."
Also hab ich mich auf die Suche gemacht, was dieses Fehler auslösen könnte. Bei Google bekommt man dazu eine Vielzahl von Lösungsansätzen, von denen ich auch verschiedene probiert habe, die jedoch nicht zum Erfolg, sprich zur Lösung des Problems, geführt haben.
Was mir jedoch schon aufgefallen ist, was, dass sich viele Vorschläge mit der .htaccess-Datei befasst haben. Als ich dann versucht habe, diese Datei umzubenennen, konnte ich mich plötzlich wieder am WordPress-Backend anmelden.
Also hab ich mit die .htaccess-Datei mal näher angeschaut und siehe da, da befindet sich ein neuer Eintrag drinnen, der weder von WordPress, noch von mir stammt. Die zusätzlichen Zeilen wurden von meinen Webhoster ueberspace.de eingetragen, mit dem Vermerk, dass sie diese Datei gesperrt haben, weil sich sehr viele Attacken auf diese Datei konzentriert haben.
Eigentlich finde ich die Initiative von uberspace.de höchst löblich, doch ich hätte mir gewünscht, dass ich eine kurze Mail dazu erhalten hätte, dann hätte ich mir einiges an Sucherei ersparen können. 😉
Folgende Zeilen wurden der .htaccess-Datei von uberspace.de hinzugefügt:
# 2013-08-13 hallo@uberspace.de # massive Attacken von Tausenden von IPs auf diese Datei RewriteRule wp-login.php - [F]
Wenn man die dritte Zeile mit einem “#” auskommentiert, dann kann man sich wieder anmelden. 🙂
Ich setze nun schon seit vielen Monaten das WordPress-Plugin “Mini Twitter Feed” von webdevdesigner.com ein und bin damit rundum zufrieden. Nun ist mir vor einigen Tagen auf meiner Webseite (https://ostermeier.net/twitter/) aufgefallen, dass keine Tweets mehr angezeigt werden. Erst dachte ich mir, dass Twitter vielleicht ein Problem hätte und hab dem Vorfall keine größere Bedeutung zugemessen und erst einmal auch nichts unternommen. Doch als die Tweets mehrere Tage nicht gingen hab ich doch mal etwas genauer geschaut.
Und siehe da, Twitter ist nicht “ausgefallen”, aber sie sind trotzdem schuld. Auslöser war ein API-Update von Twitter von der Version 1 auf die Version 1.1
Dadruch bedingt muss man sich für die “Anwendung” (mini Twitter Feed) eine neue ID bei Twitter generieren und dann auch im Plugin hinterlegen.
Das Erstellen einer neuen ID ist ziemlich einfach (https://twitter.com/login?redirect_after_login=%2Fsettings%2Fwidgets%2Fnew), aber das Einbinden bzw. Hinterlegen dieser neuen ID im Plugin hat mir doch etwas Kopfzerbrechen verursacht. Aber es ist dann doch einfach als “befürchtet”. 😉
Ab besten gibt man die ID in WordPress direkt beim Shortcode des Plugins mit an. Dies könnte dann ungefähr so aussehen:
minitwitter username="ostermeiernet" limit="20" id="123456789123456789"
Und weil wir schon gerade so schön beim “shortcoden” sind. In der Beschreibung des Plugins steht, dass man die letzten 100 Tweets anzeigen lassen könne. Bei mir werden aber nur die letzten 20 Einträge angezeigt, egal, was ich bei Limit=”xxx” reinschreibe. Ist das bei euch auch so? Oder an was liegt das?
Nachtrag / Hinweis / Nennt es wie ihr wollt:
Ich glaube ein ähnliches Problem könnte das Jetpack-Plugin für WordPress auch haben. Auch hier aktualisieren sich meine Tweets nicht mehr. Jedoch habe ich in dem Plugin keine Einstellung gefunden, wo ich eine neue Twitter-App-ID anfordern oder eintragen könnte. Ich hoffe jetzt einfach mal auf ein Plugin-Update 😉
Nachtrag zum Nachtrag:
War etwas verplant, als ich sagt, dass es sich im ein Jetpack-Plugin handle, welches ich in der Sidebar eingebaut hätte und das jetzt nicht mehr funktioniert. RICHTIG ist, dass es sich um ein Twitter-Widget aus dem Widgetkit von Yoothemes handelte, welches ich mal mit meinem Theme damals erstanden hatte und welches nicht mehr ging. Als Lösung kann man das Jetpack “Zeitleisten-Widget” verwenden. Das funktioniert. Dafür muss man aber wieder eine Twitter-APP-ID anlegen…was aber nicht tragisch ist. 😉
Andreas Weck von t3n.de hat einen guten Bericht geschrieben, was Betreiber (Blogger), die WordPress im Einsatz haben, beachten oder beherzigen könnten, damit ihre Seite sicherer, besser bedienbar und schneller wird.
Hier kurz die Tipps im Überblick, der Link zum vollständigen Artikel findet ihr unter der Auflistung:
Den kompletten Post mit allen Details findet ihr unter:
http://t3n.de/news/wordpress-10-tipps-blogger-469490/
Das CMS WordPress ist vor kurzem 10 Jahre alt geworden. Zu diesem Anlass hat Ellen von elmastudio.de eine Umfrage gestartet, was den Usern vom WordPress an diesem System besonders gefällt und warum sie es einsetzten.
Die Antworten spiegeln zu einem sehr großen Teil aus die Gründe, die für mich für WordPress sprechen. Ich möchte euch hier nur kurze die Schlagworte/Überschriften zeigen, für weitere Infos lest bitte den Originalblog-Eintrag von Ellen. Diesen findet ihr auf ihrer Webseite unter:
http://www.elmastudio.de/wordpress/10-grunde-fur-die-man-wordpress-einfach-lieben-muss/?utm_source=feedly
Hier aber nun die Top-Ten, warum WordPress eingesetzt wird:
In der bitundso Folge Nr. 330 (LINK zur Folge) hat Gerrit ein Tool vorgestellt, welches sich “LiveReload” nennt und speziell für Leute interessant sein dürfte, die sich hin und wieder mit Webseiten beschäftigen. Ich selber bin davon auch immer wieder “betroffen” und wer kennt nicht die umständliche Arbeitsweise:
Datei lokal bearbeiten, (per FTP *) auf den Server schieben und dann im Browser (per Reload) kontrollieren, ob alles passt. Genau hier setzt LiveReload an und möchte einem das Leben leichter machen. Es überwacht quasi, ob ein Speichern-Button gedrückt wurde und nimmt dies dann zum Anlass im Browser einen Reload durchzuführen. Die App findet ihr auf: http://livereload.com und im MacApp-Store und kostet US$9.99 bzw. 8,99 EURO. Das Programm ist derzeit für den MAC in der Version 2, für Windows als Beta-Version und für Linux als Browser-Erweiterung “guard-livereload” zu bekommen.
Ich halte diese App für ein sehr nützliches Tool und möchte nicht mehr darauf verzichten. Also einfach mal einen Blick darauf werfen – es lohnt sich.
* Was auch gehen müsste, was ich aber noch nicht selber getestet habe: Man müsste eine Verknüpfung mit einem FTP Programm und LiveReload machen können. Zum Beispiel mit “Transmit” von panic. Und dann würde wenn man etwas in einem Editor bearbeitet (z.B. Coda von panic) sowohl die Datei per FTP auf den Server geschoben werden, als auch eine Sofort-Vorschau im Browser angezeigt werden. Dies funktioniert deswegen so gut, weil LiveReload auch das Temp-Verzeichnis vom “Transmit” überwacht und die Voraschau mit den lokalen Dateien erzeugt.