Habe heute das Plugin “TinyMCE Advanced” kennen und schätzen gelernt. Dieses ersetzt den WordPress-eigenen Tiny-Editor und bietet dann eine Vielzahl von weiteren Editier-Funktionen. Was aber für mich entscheidend war, es gibt bei den Plugin-Einstellungen einen Haken, den man setzen kann, damit nicht die Zeilenumbrüche entfernt werden. Was für mich ziemlich störend war, wenn ich Tabellen im HTML-Mode editiert habe.

Und noch schnell ein Pich für eine OS X App. Dieses Mal möchte ich die App “Color Chooser” erwähnen. Eigentlich müsste man garnicht viel zu dem Programm sagen, dann es tut genau das, was der Name aussagt. Man sucht sich eine Farbe auf dem Bildschirm aus, klickt diese an und bekommt dann dazu die passenden Farbwert in HEX oder RGB. Das Programm selbst nistet sich in der Mac Menubar ein und mit einer Lupe sucht man sich die Farbe aus, von der man Informationen benötigt. Für mich ist dies eine ziemliche Erleichterung, da ich nicht immer in irgendeinem Malprogramm nach den Farbwerten suchen muss. Weitere Infos zu dem Programm findet ihr auf der Hersteller-Webseite unter http://www.colorchooserapp.com/ im Mac AppStore.
Ach ja, momentan ist das Programm auch noch preisreduziert und ist für 0,79 Euro (statt 2,99 Euro) zu haben.

Das ist ja wieder einmal ein dämliches Wortspiel als Überschrift…
Aber ich wollte kurz auf eine App für OS X hinweisen, die ganz nützlich sein kann. “Appy Days” ist ein kleines Programm, welches Apps für iPhone, iPad oder Mac OS X aus dem jeweiligen App-Store anzeigt, die kostenlos oder gefeatured sind.
So behält man ziemlich leicht einen Überblick und verpasst vielleicht nicht so schnell ein Super-App-Schnäppchen.

Irgendwie hab ich mir so eine Holz-Rückseite für mein iPhone gewünscht, weil ich finde, die schaut irgendwie edel aus. Nach dem ich nun einige Zeit gesucht habe, (und nichts wirklich gutes gefunden habe), hab ich mich wieder an einen etwas älteren Post vom iphoneblog.de erinnert und das Alex da mal was geschrieben bzw. getestet hat und sehr zufrieden damit war.
Ich hab jetzt mal auf den Webseiten von www.einzigartigeARTIKEL.de geschmökert und die  Sachen gefallen mir wirklich gut. Ok, vom Preis her sind sie nicht unbedingt ein Schnäppchen, aber wenn dann die Qualität passt, dann ist es ja auch wieder ok. Also wir reden da von ca. 65 EUR was so ein Backcover kosten würde – wahlweise auch mit individueller (Laser)Gravur, dann ist man ca. 20 EUR mehr schuldig.
Ich hab jetzt mal vorsichtshalber bei der Firma angefragt, ob die Holz-Rückseiten auch für das iPhone 4S passen würden und in deren Antwort (ca. 3 Minuten später!) wurde mir mitgeteilt, dass sie derzeit noch keine (Holz- oder Metall)Rückseiten für das 4S im Programm hätten und die in ca. 2 Wochen (also so um den 25. November 2011) soweit sei. Sie würden mich dann per Mail daran erinnern. Da bin ich ja mal gespannt.

Es gibt auch einen firmeneigenen FlickR-Kanal, der viel Photos bereit stellt.
http://www.flickr.com/photos/einzigartigeartikel/ 

Nachtrag vom 30. November 2011:
Mittlerweile gibt es auch die Holz-Rückseiten für das iPhone 4S. Zu finden direkt unter:
http://www.einzigartigeartikel.de/Backcover-iPhone4S 

Nachdem ich in den letzten Tagen und Wochen wieder mal mit WordPress recht aktiv bin, häufen sich “unabsichtlich” die Posts dazu.
Nun hatte ich in den letzten Tagen (und nicht Wochen) bei meiner Privaten-Webseite, also der www.ostermeier.net, das Problem, dass ich Menü-Eintäge nicht mehr verschieben liessen. Erst dachte ich, es wäre ein Problem von meinem (Mac) Browser “Safari” (Version 5.1.1), doch auch auf dem Firefox und dem Google Chrome funktionierte es nicht. Sogar ein Versuch unter (einem richtigen) Windows 7 mit Internet Explorer 9 wollte nicht klappen. Dann hatte ich meinen privaten Webserver in Verdacht. Da dieser schon “ewig” durchläuft und auf einem alten Mac G5 installiert ist, dachte ich dass vielleicht ein Reboot nicht schaden könnte und im Anschluss der Fehler behoben sei. Doch leider falsch gedacht.
Ich habe zur Zeit die WordPress Version 3.2.1 im Einsatz, was auch zum heutigen Tag die aktuellste Fassung ist. Des weiteren haben ich einige Plugins am Start. In einem Forum hab ich gelesen, dass evtl. ein Theme oder ein Plugin daran schuld sein könnte, dass sich Menü-Einträge nicht verschieben lassen. Das Theme (von Yoothemes.com, Names “Nano”) konnte ich ausschliessen, da ich dieses auch noch auf einer anderen Webseite (www.der-buetten-drucker.de) in der gleichen WordPress Version am Laufen habe. Also blieben nur noch die Plugins übrig. da ich keinen Nerv hatte ein Zusatzmodul nach dem anderen auszuprobieren, habe ich einfach mal alle deaktiviert und siehe da, die Menü-Einträge lassen sich wieder verschieben.
So hab ich nun die neuen Einträge ins Menü gemacht und im Anschluss wieder alle Plugins aktiviert. Somit kann ich leider nicht genau sagen, welches Plugin schuld war, aber im Anschluss eine Liste meiner derzeit installieren Zusatzmodule, vielleicht hilf es ja dem einen oder anderen von euch weiter:

• Askimet
• All in one Favicon
• All in One SEO Pack
• Better Tag Cloud
• Category Specific RSS Menü
• Exec-PHP
• Google Analytics Dashboard
• Google Analytics for WordPress
• Google XML Sitemaps
• Image Banner Widget
• MapPress Easy for WordPress
• MCE Table Buttons
• NextGEN Gallery
• Simple Tags
• Smart YouTube
• Visitor Maps and Who´s Online
• Widgetkit
• WP-Memory Usage
• WP-RSSImport
• WP Time Machine (for Backups)
• WP to Twitter

In der letzten Woche sind eigentlich nur zwei neue Plugins dazu gekommen, wodurch der Verdacht nahe liegt, dass eines dieser beiden der “Schuldige” ist. Das wären “WP-Memory Usage” und “WP Time Machine for Backup”.
Vielleicht hat ja einer von euch ähnliche Problem mit den Menüs und kann mal schauen, welche Plugins bei ihm am Start sind, vielleicht können wir den “Übeltäter” gemeinsam einkreisen.

Nachtrag:
Ich hab nun doch nachgeforscht, welches Plugin mit Probleme bereitet und habs gefunden. Das “WP Time Machine for Backup” war schuld. 

Hatte heute den Fall, dass ich bei einem relativ frisch installierten WordPress-System irgendwann aus heiterem Himmel die Meldung bekam, dass ich zu viel Speicher (RAM) belegen würde.
Die genaue Meldung was: Allowed memory size of 25165824 bytes exhausted (tried to allocate 112203 bytes) …
Hab dann etwas gegoogled und da wurden die wildesten Tipps gegeben, wie man selbst die Speichergrenze ausloten bzw. höher setzten kann. Die meisten Hinweise versuchten die mit einem Eintrag in die .htaccess-Datei. Andere wiederum versuchten ihr Glück in der wp-config-php. Das alles brachte bei mir jedoch keinen Erfolg.

Erst als ich über das Plugin “WP-Memory-Usage” gestolpert bin, konnte ich nach dessen Installation im Dashboard vom WordPress erkennen, dass bei dem betreffenden Webserver ein Speicherlimit von 24MB hatte. Ein Anruf bei meinem Hoster und 5 Minuten später war dieses Limit auf 64MB erhöht

In meinem letzten Artikel hab ich beschrieben, wie man mittel FTP WordPress relativ gut backupen kann. Leider ist hierbei jedoch die Datenbank nicht dabei. Nun habe ich etwas weiter geforscht und bin über ein Plugin gestolpert, welches ein Online-Backup des eigenen WordPress-Blogs zu Dropbox oder Amazon´s S3 schieben würde.
Vom Prinzip her hätte mir das sehr gut gefallen und ich hab das Plugin jetzt am unter www.ostermeier.net installiert. Seltsam ist nur, dass obwohl ich die Dropbox-Daten richtig eingegeben habe und das Plugin auch ca. 2-3 Minuten mit einem “Backup” beschäftigt ist, es keine Sicherungsdatei auf der Dropbox ankommt.  In den Plugin-Einstellungen kann ich mir dann von Hand die gezippte TAR-Datei runterladen, was ja bedeutet, dass das “Sichern” schon mal funktionieren würde. Leider wird bislang diese Sicherung nicht auf meinen Online-Speicher geschoben. An was das liegen könnte, habe ich noch nicht heraus gefunden.

Nachfolgend noch eine Übersicht, was sich bei mir alles in der Sicherungsdatei befand:

• index.php
• license.txt
• readme.html
• wp-activate.php
• wp-admin (Verzeichnis)
• wp-app.php
• wp-atom.php
• wp-blog-header.php
• wp-comments-post.php
• wp-commentsrss2.php
• wp-config-sample.php
• wp-content (Verzeichnis)
• wp-cron.php
• wp-feed.php
• wp-includes (Verzeichnis)
• wp-links-opml.php
• wp-load.php
• wp-login.php
• wp-mail.php
• wp-pass.php
• wp-rdf.php
• wp-register.php
• wp-rss.php
• wp-rss2.php
• wp-settings.php
• wp-signup.php
• wp-trackback.php
• xmlrpc.php

Muss aber ganz ehrlich gestehen, dass ich bei der Durchsicht des Sicherungs-Verzeichnisses bzw. der Datei nichts von einem Datenbank-File gefunden habe. Muss da mal nochmal schauen…

Ich hatte vor einigen Tagen das Problem, dass ich eine neue Webseite erstellt habe und dafür (wie üblich) das CMS-System WordPress verwendet habe. Allerdings ergab sich bei der neuen Seite ein Problem (passwortgeschütze Seiten funktionierten auf Teufel komm raus nicht), welches ich einfach nicht lösen konnte und ich so schlussendlich zu dem Entschluss kam, dass ich eine Neuinstallation des CMS machen müsse.
Nun hatte ich aber schon einiges an Arbeit in des Layout der neuen Webseite gesteckt und ich wollte mir nicht die ganze Arbeit nochmal von vorne machen, so dass ich überlegt habe, wie ich was am besten sichern könne, damit ich nach dem neu aufsetzen von WordPress relativ schnell wieder auf dem aktuellsten Stand sei. Zum Glück hatte ich inhaltlich noch so gut wie garnichts in die Datenbank geschrieben, mal abgesehen, von einigen Musterseiten mit Blindtext.
Nachfolgend möchte ich ein paar Tipps los werden, wie ich das ganz angestellt habe und welche Dateien / Ordner ich dabei gesichert habe:

• alle nachfolgenden Dateien/Ordner habe ich einfach per FTP mir vom Webserver geholt.
• ganz wichtig, wenn die Neuinstallation auf dem selben Webserver erfolgt, dann wie wp-config.php aus dem WordPress-Root-Verzeichnis sichern. Dann hat mal schon wieder die Datenbankeinstellungen.
• Ich für meinen Teil habe dann noch aus dem wp-content-Verzeichniss das “Plugins”-Verzeichnis kopiert. Das wäre jetzt zwar nicht zu viel Arbeit gewesen, die Plugins erneut zu installieren, aber wenn man es sich sparen kann, dann muss es ja auch nicht sein.
• aus dem wp-content-Verzeichniss bzw. aus dem “Themes”-Verzeichniss habe ich mir den Ordner des verwendeten (und schon bereits angepassten) Themes gesichert.

Sollte man aber auch in der Datenbank schon Einträge haben, so muss man sich diese auch sichern. Ich für meinen Teil bin mir noch nicht ganz schlüssig, ob ich lieber einen Datenbank-Dump mittels z.B. phpmyAdmin mache oder ob ich auf eines der diversen Datenbank-Sicherungs-Plugins zurück greifen soll. Wenn ich mich mal entschieden habe, dann lass ich es euch wissen.
Bzw. wenn einer von euch einen guten Tipp für mich parat hat, dann immer raus damit.