Der tägliche Computer-Ärger hat ein Ende… oder doch nicht!?
Posts tagged WordPress
Kompatibilitäts-Liste für WordPress-Plugins
01461 Tagen
Es ist schon unglaublich, wieviel Energie und Zeit manche Menschen in diverse Web-Projekte stecken können.
Ein mehr als sinnvolles Projekt bzw. eher eine Übersicht stammt von der Firma BraveNewCode Inc., die im Bereich Webdesign und -entwicklung angesiedelt ist.
Das Unternehmen hat eine Übersicht erstellt, die über 5000 WordPress-Plugins enthält und sehr übersichtlich darstellt, unter welchen WordPress-Versionen jedes einzelne Plugin funktioniert und auch, welche sonstigen Vorraussetzungen gegeben sein müssen. So z.B. die PHP4-Kompatibilität oder ob eine Datenbank-Anbindung erforderlich ist.
Diese Übersicht wandert auf jeden Fall in meine Favoriten!
Danke auch an Heiko vom “Code Styling Project“, durch dessen Blog ich einmal auf die Seite aufmerksam geworden bin und für seinen Test dieser Seite. Scheinbar gibt es bei den Test-Verfahren von BraveNewCode noch einige kleine Fehler.
WordPress 2.8 Admin-Bereich nicht komplett auf Deutsch
41467 Tagen
by Manuel Bissinger
in Blogging
Nach einem Upgrade von WordPress auf die Version 2.8 ist mir aufgefallen, dass nicht mehr alle Einträge im Admin-Bereich, also im Backend, Deutsch sondern Englisch dargestellt werden.
Abhilfe ist schnell gegeben. Man lädt sich von WordPress-Deutschland einfach die zwei Sprachdateien de_DE.po und de_DE.mo herunter und lädt sie auf dem Server in den Ordner “/wp-content/languages”.
Danach sollte wieder alles im verständlichen Deutsch erscheinen.
Update: Beim Einfügen von Media-Daten ist der Button jetzt auf Englisch beschriftet. Gibt wohl doch noch kleine Fehler in der Sprachdatei.
Update auf WordPress 2.8 mit Problemen
51467 Tagen
by Manuel Bissinger
in Blogging
Die neuen Funktionen und vor allem der Geschwindigkeits-Gewinn bei der neuen Version 2.8 drängen einen förmlich dazu, ein Update durchzuführen. Nur dieses mal gestaltete sich dieses leider nicht ganz ohne Probleme.
Ein Automatisches Upgrade innerhalb des Backend war bei mir leider nicht machbar. Ständig traten diverse Fehlermeldungen auf. Also hab ich die neue Version bei WordPress-Deutschland runtergeladen und einfach per FTP hochgeladen. Hatte in der Vergangenheit auch immer gut funktioniert. Ein erster Blick auf das Blog ließ Gutes hoffen, da soweit alles gut aussah.
Beim einloggen im Admin-Bereich aber die erste Ernüchterung. Nach dem Klick auf Login war nur folgende Fehlermeldung zu lesen:
Fatal error: Call to undefined method: wp_scripts->do_head_items() in /www/htdocs/w008a39d/blog/wp-includes/script-loader.php on line 566
Im Forum von WordPress-Deutschland konnte man mir jedoch ziemlich schnell weiterhelfen. Hier der Tipp, einfach mal die Ordner wp-admin und wp-includes komplett vom Server zu löschen und aus dem Installations-Paket neu hochzuladen. Danach stellte sich auch wieder das Glücksgefühl ein, da auch der Backend-Bereich wieder lief.
Jetzt habe ich nur noch mit den automatischen Plugin-Updates zu kämpfen. Die aktuellen Zip-Dateien werden zwar heruntergeladen und sogar wieder gelöscht, nur bekomme ich auch hier wieder eine Fehlermeldung:
Warning: unlink(balblubb.zip) [function.unlink]: No such file or directory in /blablubb/wp-admin/includes/class-wp-upgrader.php on line 146
Inkompatibles Archiv PCLZIP_ERR_MISSING_FILE (-4) : Missing archive file ‘blablubb.zip‘
Hierzu hab ich jedoch noch keinen Lösungsansatz gefunden. Falls jemand einen Tipp hat, bitte ich um Hilfe!
Update:
Mittlerweile wurde mein Blog vom Provider auf einen IsolatedServer umgezogen. Das verhunzte WordPress 2.8 hat so viel Performance gefressen, dass andere Webseiten auf dem SharedServer darunter mächtig gelitten haben. Auch konnte ich gar nicht mehr auf das Blog zugreifen. Weder das Front- noch das Backend wollten funktionieren. Gab nur noch Timeout- und Überlastungs-Fehler.
Ich hab dann mal den Blog-Ordner, in dem WP drin lag, per FTP-Zugang umbenannt. Dann einen neuen Ordner mit dem alten, korrekten Namen angelegt und ganz normal das Original-WP 2.8 rein kopiert. Danach die wp-config.php aus dem umbenannten Ordner rüber kopiert.
Das Gebilde sah dann so aus, dass ich eine jungfräuliche WP-Version hatte, die über die alte wp-config auf die Original-Datenbank zugegriffen hat. Da die ganzen Themes- und Plugins-Ordner leer waren, konnte es auch keine Fehler mehr geben, die evtl. durch inkompatible Scripte entstanden sind. Beim Aufruf des Blogs wollte WP die Datenbank wieder anpassen und durfte das auch. Danach hatte ich wieder normalen Zugriff auf das Blog und den Admin-Bereich. Die ganzen Plugins hab ich dann einzeln wieder hochgeladen und aktiviert, um sehen zu können, welches davon vllt. Probleme bereitet. Bisher lief alles anstandslos.
Auf der Seite “Code Styling Project” habe ich zudem noch weiter interessante Punkte gefunden, wie man die neue Version besser zum laufen bekommt. Für viele hier ist sicherlich der Teil “Scriptkomprimierung unterbinden” besonders lesenswert. Es geht darum, dass WP wohl alle Scripte zusammenführt, komprimiert und dann erst am Ende der Website im footer ausführt. Bei CSS gibt es eine ähnliche Funktion. Damit scheinen allerdings einige Scripte so ihre Probleme zu haben und verweigern daher ihren Dienst oder es treten Fehler auf. Genannt wird hier z.B. TinyMCE. Ebenfalls soll es so wohl auch zu den PECL_ZIP-Fehlermeldungen kommen.
Von einigen anderen habe ich gehört, dass sie ihre Backups der Dateien und Datenbank-Einträge wieder zurück kopiert haben. Also ein Downgrade zur Version 2.7.1 durchgeführt haben. Ein Backup der alten Datenbank hatte ich allerdings nicht und beim Upgrade wurde diese ja an die neue Version angepasst. Die alte Version scheint damit wohl nicht mehr klar zu kommen. Deshalb der verzweifelte Kampf, WP 2.8 zum laufen zu bewegen.
Mein Provider gab mir noch den Tipp, ich solle Versuchen, WP-Super-Cache und evtl. WP-Widget-Cache einzusetzen. Dadurch würden erheblich weniger SQL-Abfragen gestartet und das Blog läuft schneller und stabiler. Noch sitze ich dran…
Ich hoffe mal, ich konnte damit jemandem etwas helfen.
WordPress-Update mit fluency-admin-Backend
01757 Tagen
Nach langer Abstinenz was das bloggen betrifft melde ich mich hier mal wieder zu Wort. Scheinbar geht es nicht nur mir so, was die nicht vorhandene Zeit zum Schreiben angeht. Auch bei BlogPimp geht es in letzter Zeit etwas ruhiger zu.
Mit erstaunen musste ich nun also nach einiger Zeit feststellen, dass doch mittlerweile WordPress schon in der Version 2.6.1 vorliegt. Nach dem Sichern aller Daten und Datenbanken wurde das Update installiert und siehe da, das Blog lebt noch. Nur das Backend hatte es leider nicht ganz überlebt. Hier nutze ich schon länger das fluency-admin-Theme, das komfortabel als Plugin auftritt. Nach dem Update hatte es dann leider die Darstellung zerschossen und die Navigation füllte 3/4 des Bildschirms aus. Ergo: keine Chance das Plugin zu deaktivieren.
Abhilfe schaffte das einfache Überschreiben des Ordners “fluency-admin-plugin” durch die aktuelle Version, die man sich hier herunterladen kann. Nach einem aktualisieren des Backends sollte wieder alles laufen.
Mehrere WordPress-Blogs auf unterschiedlichen Subdomains
21829 Tagen
Ich hab mich mal mit dem Thema auseinander gesetzt, mehrere Blogs auf einem WebSpace-Account zu betreiben. Dazu gibt es verschiedene Ansätze, die natürlich alle ihre Vor- und Nachteile haben.
Hier mein Lösungsansatz, kurz vorgestellt:
Man benötigt eine WordPress-Installation auf dem Server. Diese wird ganz normal installiert. ist schon ein Blog vorhanden, auch kein Problem. Funktioniert genauso. Die Datei wp_config.php muss einfach nur angepasst werden. In Zeile 7 oder 11 (je nach Version) findet sich der Eintrag $table_prefix = 'wp_';, evtl. mit einem Kommentar dahinter. Diese Zeile muss durch folgenden Code ersetzt werden:
$arrPrefix = explode( ".", $_SERVER["HTTP_HOST"] );
$table_prefix = $arrPrefix[0].'_';
switch($arrPrefix[0]) {
case 'blog1':
$table_prefix = 'wp_';
break;
default:
$table_prefix;
}
Der Code ist eine Mischung aus den Blogs von “Open Source Brain” und “CBSchmidt“. Als Beispiel dient hier jetzt mal die Subdomain “blog1.domain.tld” als Ursprungs-Standard-Blog. Bei dieser Subdomain wird auf die Datenbank-Tabellen mit dem Präfix “wp_” verwiesen, welche die Standard-Tabellen der aktuellen Datenbank darstellen sollten. Natürlich nur, wenn das Präfix bei der Installation nicht geändert wurde. Jede weitere Subdomain legt bei der Installation neue Tabellen an, die die entsprechende Subdomain als Präfix erhalten. Beispiel: “blog2.domain.tld” erhält Tabellen mit dem Präfix “blog2_”. Die Installation neuer Blogs funktoniert nach dem ändern der wp_config.php ziemlich einfach. Man registriert sich bei seinem Provider eine neue Subdomain und lässt diese auf den WordPress-Ordner verweisen. Dann gibt man bei der Subdomain “blog2.domain.tld” im Browser einfach blog2.domain.tld/wp-admin/install.php ein und schon erstellt man sich innerhalb weniger klicks ein neues Blog.
Das ganze Konstrukt hier funktioniert jetzt aber nur, wenn die Domain gleich bleibt und sich nur die Subdomain ändert.
Das Prinzip sieht wie folgt aus:
Es gibt eine Installation, also eine Instanz von WordPress. Für jedes Blog werden eigene Tabellen innerhalb einer Datenbank angelegt. Jedes Plugin oder Theme, das “installiert” wird, ist in jedem Blog verfügbar, da ja alles im selben Ordner liegt. Jedes Bild, das hochgeladen wird, ist somit ebenfalls in jedem Blog verfügbar. Die Zuweisung der Plugins, Themes und Dateien erfolgt bei WordPress ausschließlich über die Datenbank-Einträge. Meiner Meinung nach eignet sich eine solche Variante nur für eine Person, die mehrere Blogs speicherplatzsparend betreiben möchte. Bei mehreren Personen könnten Bilder, Dateien, Plugins und Themes schnell und zu einfach gelöscht werden. Klassisches Sicherheitsproblem eben.
Hier noch weitere Lösungen. Einmal ein Tutorial von mel.melaxis, dann natürlich ein Hinweis von WordPress auf die wp_config-Datei, hier noch eine englische Anleitung, ähnlich der von CBSchmidt und WordPress liefert im Codex-Bereich auch noch eine Anleitung. Etwas ausführlicher gibt’s eine Anleitung, nicht nur für Blogs, auch noch im SoftwareGuide.
WordPress-Bug beim Bilder positionieren
11829 Tagen
by Manuel Bissinger
in Blogging
Keine Ahnung ob es nur mir so geht, aber wenn ich in WordPress ein Bild in einen Artikel einbinden will, haut das nicht so wirklich mit der Positionierung hin. Per AJAX öffnet sich ja ein Layer, in dem man entweder ein neues Bild hochladen oder ein schon vorhandenes auswählen kann. Anschließend kann man diverse Eingaben tätigen, wie z.B. den Bild-Titel, eine Beschreibung oder eben, wo bzw. wie das Bild ausgerichtet oder positioniert werden soll.
Nur irgendwie scheint das entweder von anfang an oder erst nach einer weile nicht mehr wirklich zu funktionieren. Bei mir sieht es manchmal so aus, als ob das Bild richtig eingebunden und positioniert wurde. Nur im Artikel selber passt es dann leider nicht. Grund hierfür ist, dass die CSS-Klasse “align…” nicht gesetzt wird. Wieso, hab ich bisher noch nicht heraus gefunden.
Man kann sich jedoch damit behelfen, dass man das Bild erstmal ohne eine bestimmte Ausrichtung in den Text einfügt. Danach klickt man auf das Bild, so dass dieses markiert ist, und anschließend auf Baum-Symbol 
.
Hier wählt man sich jetzt einfach die gewünschte Ausrichtung aus und schon passt das ganze und wird auch richtig übernommen. Dies erkennt man auch daran, dass in dieser Anzeige unten bei “Klasse” entweder der Eintrag “alignnone” verschwindet, oder eben ein neuer Eintrag hinzugekommen ist.
Das hier ist jetzt erstmal nur ein Workaround, um das Problem zu umgehen. Woran das Problem liegt und wie man es generell wieder gerade biegt, findet man sicherlich in einem anderen Blog. Sollte ich selbst mal drüber stolpern, berichte ich natürlich hier darüber.
WP Sicherheits-Plugins
11892 Tagen
Zwei neue Plug-Ins haben es in mein WordPress geschafft.
Zum einen wäre da ein Plug-In namens “WordPress Database Backup” von Austin Matzko (Il Filosofo-Blog). Dieses Plug-In erstellt in regelmäßig einstellbaren Zeitabständen Backups der Datenbank. Fest vorausgewählt sind die Standard-Tabellen, die sich jedoch optional erweitern lassen. So kann man sich z.B. täglich, wöchentlich oder bei Bedarf die gesicherte SQL-Datenbank per Mail zuschicken lassen oder einfach als Datei herunterladen. Das ganze dient einzig der Faulheit des Admins. Man spart sich so quasi den Gang über phpMyAdmin oder ähnliche Tools.
Das zweite Plug-In nennt sich “WP Security Scan” und stammt von Michael Torbert. Hiermit lässt sich auf die schnelle die Sicherheitskonfiguration von WordPress überprüfen. Getestet werden die Zugriffsrechte auf Ordner, das vorhanden sein des Benutzers “Admin” und man kann sich den Sicherheitsgrad seines Kennworts anzeigen lassen. Insgesamt eine Runde Sache. Nur würde ich etwas mehr integrieren. So z.B. das automatische, sprich komfortable einrichten eines .htaccess-Schutz. Als Admin kann man dies natürlich auch händisch machen. Aber warum, wenn WP dafür schon so schöne Plug-Ins anbietet? Laut Programmierer sollen solche Features jedoch schon bald hinzu kommen. Ich bin gespannt.
WordPress Blog Header Generator
01892 Tagen
Und hier gleich noch ein Generator. Ich sagte ja schon, es gibt viele davon.
Für alle, die entweder schnell eine Header-Grafik brauchen oder einfach nur zu faul sind, selbst im Bildbearbeitungsprogramm rum zu basteln. Der Blog Header Generator erstellt für das Default-Theme von WordPress schicke bzw. erstmal passende Grafiken für den Header-Bereich. Man sucht sich ein Bild aus einer der angebotenen Quellen heraus und lädt es einfach hoch. Als Bild-Quellen kommen außer der Festplatte noch Flickr oder Photobucket in Frage. Auch der Bilder-Klau durch URL-Eingabe wird unterstützt. Danach gibt man die Bild-Positionierung (mitte, oben-links, unten-rechts) an und könnte jetzt noch zusätzliche Copyright- oder Quellen-Vermerke hinzufügen.
Eine Bildbearbeitung bringt der Generator leider nicht mit. Somit ist es nicht möglich, das Bild von der Größe her nachträglich anzupassen oder zu skalieren. Aber dafür gibt es ja genügend andere Online-Bildbearbeitungen, die ich schon in einem anderen Arikel erwähnt habe.
Entdeckt bei BlogPimp.
WordPress Themer Kit
01892 Tagen
Vor kurzem habe ich einen Artikel über das WordPress-Plugin “Theme Test Drive” geschrieben, mit dem man ungesehen von Besuchern, verschiedene Themes ausprobieren kann. Im selben Artikel habe ich unter anderem auch noch auf ein Tutorial verwiesen, welches sich der Theme-Erstellung widmet.
Da heutzutage allerdings für jegliches erdenkliche Projekt auch spezielle Generatoren finden lassen, die einem das Leben leichter machen sollen, gibt es jetzt auch einen für WordPress. Das ganze nennt sich WordPress Themer Kit und ist derzeitig nur auf Englisch verfügbar. Lothar Baier (BlogPimp-Blog) hat sich im Dr. Web-Weblog jedoch dazu bereit erklärt, das ganze auch ins Deutsche zu transformieren.
Der Themer basiert, genauso wie das CSS-Zen-Projekt, auf einer HTML- und einer CSS-Datei. Da WordPress allerdings aus mehreren PHP-Dateien besteht, die miteinander verschachtelt werden, wurden diese einfach in eine einzelne Datei integriert. Somit wird das ganze auch etwas übersichtlicher. Ziel soll es sein, allein durch das Verändern bzw. Anpassen der CSS-Datei, sein eigenes Layout zu entwerfen. Die Funktionsweise bekommt man in den beiliegenden Text-Files und in 3 kurzen Videos näher gebracht.
Interessant ist dieses Prinzip generell für all diejenigen, die sich mit CSS ernsthaft auseinander setzten wollen und ihre Layouts damit gestalten wollen.
Das WP Themer Kit ist zur Zeit noch in der Entstehungsphase, was man an der aktuellsten Version 0.2 schon erkennt. Jedoch birgt das Projekt sicherlich viel Potenzial, um schnell und vernünftig von den 08/15-Themes wegzukommen.
WordPress Theme-Test-Umgebung
01906 Tagen
Bei hunderten von Themes, die es mittlerweile für WordPress gibt, fällt es vielen Usern schwer, sich da für eines zu entscheiden. Auch fehlt vielen entweder das Know-How oder, wie mir, einfach die Zeit oder die Muse, sich ein eigenes Theme zu gestalten. Durch ein einfaches hinein-kopieren der Themes in den wp_content/Themes-Ordner auf dem Server lassen sich die Designs unter dem Reiter “Darstellung” bei Version 2.5 auswählen. Hierbei wird allerdings, so wie es auch gewollt ist, der komplette Theme für alle sichtbar geändert. Wer jedoch einfach nur mal testen will, wie sein Blog bei einem Theme aussieht, für den empfiehlt sich das PlugIn “Theme Test Drive” von Vladimir Prelovac. Hiermit lässt sich das Theme nur für den Administrator verändern. Alle anderen User, die sich vielleicht auch gerade im Blog befinden, bekommen vom Design-Wechsel nichts mit.
Ein klasse PlugIn für alle, die gerne und oft mal neue Themes ausprobieren wollen.