Beiträge von Ammaletu

Wenn Du die Zugriffsdaten für die Datenbank nicht kennst, bin ich leider nicht sicher, dass Du eine eigene WP-Installation verwalten solltest. Das ist so mit das Grundlegendste, was Du über Dein WordPress wissen solltest. ;-)

Wenn sich das nicht an jemand technisch bewanderteren delegieren lässt: Die DB-Zugriffdaten stehen in der wp-config.php im Hauptverzeichnis von WP. Die Datei kannst Du Dir per FTP ziehen und reinschauen. Den Link zur phpMyAdmin-Installation kann Dir der Support Deines Providers geben. Notfalls auch die FTP-Zugangsdaten. Um Passwörter nicht zu vergessen empfehle ich übrigens die tolle Software KeePass: http://keepass.info/ Damit musst Du Dir nur noch ein Passwort merken und alles andere ist sicher aufgeschrieben.

Und dann als genereller Hinweis: Mach Dir sobald wie möglich Gedanken über ein Backup deines Blogs, falls Du das noch nicht hast. Es gibt Plugins, die Dir z.B. regelmäßig die DB als E-Mail schicken.

Update: Beim Gegenlesen meines Eintrags kam mir dann doch die Idee, wonach ich googlen sollte, deswegen ist dieser Thread eigentlich auch schon wieder erledigt. Nun hab ich's aber schon mal aufgeschrieben, und vielleicht interessiert es ja auch andere. Siehe unten.

Mal eine Frage für Fortgeschrittene mit etwas Zeit zum Tüfteln: Ich richte gerade eine lokale WP-Installation ein und habe dazu mal spaßeshalber WP_DEBUG auf true stehen. Bisher gingen fast alle Plugins erfreulicherweise ohne Deprecated-Meldungen durch, aber nun habe ich eine Meldung, aus der ich nicht schlau werde. Das hier wird ausgegeben:

Zitat

Notice: has_cap wurde mit einem Parameter oder Argument aufgerufen, der seit Version 2.0 veraltet ist! Die Benutzung von user_level in Plugins und Themes ist veraltet. Nutze stattdessen das Abfragen von roles oder capabilities. in D:\webapps\wp_test\wp-includes\functions.php on line 3321

Die Zeilennummer kann man ignorieren, das ist die Zeile, wo die Meldung generiert wurde. Dieser Aufruf kommt offenbar aus der has_cap-Funktion, aber wie finde ich jetzt raus, wo genau has_cap mit dem falschen Parameter aufgerufen wird?!

Empirisch würde ich es auf das "Lightbox 2"-Plugin schieben (http://stimuli.ca/2010/02/07/lig…-for-wordpress/). Wird es aktiviert, taucht die Meldung auf, deaktiviere ich es, ist sie wieder weg. Nirgends im Plugin-File wird die has_cap-Funktion allerdings aufgerufen. Und wenn ich mal durch die gesamte Quelle von WP suche, finde ich auch nur sehr wenige Core-Dateien, welche die Funktion überhaupt benutzen, und noch weniger davon, welche die Funktion so nutzen, dass es theoretisch eine Zahl als Parameter sein könnte.

Im Livesystem für die Kunden kommt WP_DEBUG dann natürlich aus, aber mich interessiert das jetzt doch, woran es liegt und wie man heraus kriegt, woher der Aufruf kommt. Kann man sich da irgendwie einen Stacktrace anzeigen lassen, ohne gleich einen Debugger anwerfen zu müssen (damit habe ich mich bisher immer noch nicht wirklich angefreundet...)?

Antwort: Klar, googlen nach "PHP stacktrace". Damit kommt man zur schönen Funktion "debug_print_backtrace()". Diese gibt genau den Stacktrace aus, aus dem man sehen kann, über welchen Aufruf man zu dieser Funktion kam.

Wenn es schnell und dirty sein soll, kann man einfach wp-includes/functions.php öffnen und das in die deprecated-Funktionen einfügen (Zeilen 3230 bis 3326). Für eine dauerhaftere Lösung kann man sich in der functions.php oder an anderer geeigneter Stelle eine Methode für die Hooks "deprecated_function_run", "deprecated_file_included" und "deprecated_argument_run" definieren und darin den Stacktrace generieren lassen.

In diesem Fall wurde add_options_page mit dem Argument "10" statt "manage_options" aufgerufen. Habe dem Plugin-Autoren Bescheid gesagt, aber da der gerade in Indien ist...

Wobei meine erste Frage wäre, wie es sein kann, dass Dein Blog 64 MB Arbeitsspeicher verbraucht. Laufen da so viele Plugins? Hast Du so viele gleichzeitige Zugriffe? Normal sollte das eigentlich nicht sein, denke ich. Auch mit zwei Dutzend Plugins kommt man doch eher nicht über 32 MB?!

Ich würde ansonsten denken, dass das hier auch Abhilfe schafft:

<?php if (is_home()) { query_posts($query_string . "&cat=-x"); } ?>

In Deinem Code überschreibst Du nämlich den ganzen Query-String, also auch die schon gesetzten Werte für die Seiten. So müsste das erhalten bleiben. So wie es auf der verlinkten Seite steht, geht es aber sicher auch.

Die Mediathek fügt an dem Bild nur CSS-Klassen ein. Das nützt allerdings nichts, wenn das Theme diese Klassen nicht definiert. Du müsstest mal probeweise folgendes ergänzen am Ende der style.css, vielleicht reicht das ja schon:

.alignleft, .left {
  float: left;
  margin-right: 15px;
}
.alignright, .right {
  float: right;
  margin-left: 15px;
}
.aligncenter, .center {
  display: block;
  margin: 0 auto 20px auto;
}

Du setzt für die Anzeige der Überschriften in einer bestimmten Schriftart das JavaScript "Cufon" ein, und zwar zusammen mit einer Schriftart, welche die Umlaute nicht enthält. Das kann nicht klappen. ;-)

Belies Dich in der Doku des Themes bzw. im Internet mal, was Cufon ist, und überleg dann, ob Du das wirklich brauchst. Falls ja, müsstest Du schauen, dass Du die verwendete Schriftart auf der Cufon-Seite neu generierst, und zwar mit den nötigen Sonderzeichen. Das nur als genereller Hinweis; ich hatte mich dazu für einen anderen Thread vor einem Jahr oder so mal belesen, aber ganz sicher bin ich mir bei den Details nicht mehr. Glaube aber mich zu erinnern, dass man das auf der Cufon-Seite neu generieren lassen konnte.

Denk mal logisch: Wenn das komplett kaputt wäre, meinst Du nicht, dass das schon jemandem aufgefallen wäre mittlerweile? Ich würde deshalb davon ausgehen, dass Deine Probleme entweder auf Missverständnisse zurückzuführen sind oder vielleicht an einem sehr eigenwilligen Theme hängen. ;-)

Zitat

Ändert man eine Bildgrösse in einem Artikel, so wird zwar die graue Box, in dem das Bild steht verkleinert - aber das Bild selbst bleibt unverändert. Auch die prozentuale Grösse ändern ergibt überhaupt keine Änderung.

Zum einen könntest Du mal schauen, ob Du mit dem Default-Theme bzw. Twenty Ten die gleichen Probleme hast. Einfach mal kurz umschalten und schauen. Und zum anderen könntest Du vielleicht genauer beschreiben oder mit Screenshots veranschaulichen, was Du wo änderst? Ich selber arbeite normalerweise immer in der HTML-Ansicht, da kann ich selbstverständlich selbst bestimmen, was für eine Größe ich für die Bilder angebe.

Das ist absolut möglich. Erste Frage: Nutzt Du Widgets für die Sidebar?

Schau mal, ob Dir das weiterhilft:
http://faq.wordpress-deutschland.org/wordpress-trot…chnis-aufrufen/

Der Eintrag erläutert das ganze andersherum, also genau lesen, die Arbeitsschritte sind aber fast gleich. Backup machen vorher!

Schneide das Bild doch einfach lokal aufs richtige Maß zu. Wenn Du ein PNG mit Transparenz etc. nutzt, kriegt das eine Grafiksoftware in jedem Falle besser hin als WP. Danach musst Du natürlich die Schriftfarben des Headers anpassen, die sind offenbar auf einen helleren Hintergrund ausgelegt.

Die Kategorieseiten werden von der category.php angezeigt, und wenn die nicht existiert dann von der archive.php oder index.php. Dort müsstest Du the_content() durch the_excerpt() ersetzen, so we es in der index.php vermutlich auch schon ist.

Ich denke nicht, dass Du Deine Mail-Adressen hier posten möchtest, wo Bots sie bis in alle Ewigkeit abgreifen und zuspammen können. ;-)

Wenn Du noch Zugriff auf die Datenbank hast, kannst Du die Mail-Adresse dort in der User-Tabelle direkt ändern und Dir dann ein neues PW zuschicken lassen.

In den Optionen im Backend kannst Du für die Startseite eine statische Seite einstellen, was Du im Moment ja wohl benutzt. Darunter kannst Du auf eine andere statische Seite die normale chronologische Blogansicht legen. Die Seite muss existieren, kann ansonsten aber leer sein.

Ein RSS-Feed ist eine standardisiert aufgebaute XML-Datei, die Links und ggf. Inhalte enthält. Ein Forum könnte einen solchen Feed z.B. mit den Links zu den aktuellsten Themen anbieten, so hier z.B.: http://forum.wordpress-deutschland.org/external.php?type=RSS2

WP kann eine solche Datei nun schon automatisch auslesen und die Links darstellen. Mit etwas Glück kannst Du am Widget sogar einstellen, ob auch Teaser angezeigt werden sollen oder nur die Links.

Du kannst das ganze natürlich auch selber bauen. Ist vermutlich nur eine Frage der richtigen SQL-Query und etwas PHP. Der Feed hätte den Vorteil, dass sich WP selber ums Cachen kümmern würde, denn die Abfrage willst Du ja vermutlich nicht bei jedem einzelnen Seitenaufruf ausführen.

Nein, das heißt, dass im Code ein Fehler ist oder die Direktiven auf Deinem Server nicht erlaubt sind. Aber fürs erste würde ich drauf tippen, dass es an dem fehlenden schließenden Anführungszeichen in der letzten Zeile liegt. Sorry, hab ich beim Zusammenkopieren aus Google scheinbar vergessen mitzunehmen. ;-)

Wenn es wirklich nur ein Bonus sein soll und man blättern können soll in den Monaten, würde ich das definitiv mit JavaScript lösen. Wie wäre es damit?
http://docs.jquery.com/UI/Datepicker

Na ganz einfach: Jeder Bot und jeder Mensch kann die immer an einer festen Stelle abgelegte robots.txt aufrufen und schauen, was drinsteht. Wenn das also eine Art Zugriffsschutz sein soll, wäre es quasi relativ witzlos die Links zu diesen Seiten an einer bekannten Stelle wie der robots.txt für die ganze Welt schön gesammelt aufzuschreiben. ;-)

Hm, ja stimmt eigentlich, das ist natürlich einfacher. Ich denke manchmal einfach zu kompliziert. ;-) Natürlich hast Du die Links dann außerhalb der Seiten stehen. Bots sollen sich zwar an die robots.txt halten, sie müssen es aber nicht.

In diesem Zusammenhang: Das Verstecken der Seiten soll aber nicht eine effektive Form der Zugangskontrolle ersetzen, oder? Das wäre nämlich keine sehr schöne Lösung. Du weißt schon, "security by obscurity". ;-)

Das sollte im Prinzip problemlos möglich sein. wie immerempfielt es sich natürlich, Backups anzufertigen vorher, falls doch was schiefgeht. Und es ist wichtig, dass Du für die neue Installation in der wp-config.php einen anderen DB-Präfix vergibst. Dann stören sich die Tabellen in der DB nicht gegenseitig.

Das ganze per .htaccess zu lösen wäre IMHO die sinnvollste Variante. Schreib das über den Block, der von WP generiert wird, sonst klappt es nicht.

Probier es mal so:

# Zugriff von IPs sperren
order deny, allow
deny from 127.0.0.1
allow from all

IP natürlich ersetzen. Dann kriegt der Nutzer einen 403-Fehler zurück und den Inhalt Deiner 403-Fehlerseite, so eine konfiguriert ist. Das kann man ggf. on-the-fly zu einer leeren Seite anpassen:

# quick custom error "document"..
        ErrorDocument 404  "<html><head><title></title></head><body></body></html>"

Dass es ein 403-Fehler ist, sieht der Nutzer aber trotzdem, wenn er sich den Response genauer anschaut. Wenn Du das wirklich komplett verstecken willst, müsste man das noch anders machen, da fehlt mir aber gerade die Zeit zum googlen.