Beiträge von Ammaletu

    Die unterstützten Sprachen siehst Du nur, wenn Du das Plugin herunterlädst und nach den mo-Dateien schaust. Liegen oft in einem Unterordner "lang" oder "locale". Wenn da eine de_DE.mo dabei ist, dann gibt es eine Übersetzung, die aber nicht notwendigerweise aktuell, gut oder vollständig sein muss.

    Viele Plugins haben Übersetzungsdateien dabei, viele auch eine für Deutsch. Wenn Deine wp-config den LANG-Parameter auf Deutsch gestellt hat, sollten die automatisch verwendet werden.

    Andere Plugins sind dagegen nicht übersetzt. Wenn bloß eine deutsche Datei fehlt, kannst Du die selber anlegen bei Bedarf und dann dem Autor schicken (wenn es eine gute Übersetzung geworden ist, die auch andere brauchen können). Plugin-Autoren freuen sich über Mitarbeit. ;-)

    Zum Finden von Style-Angaben eignet sich Firebug (bzw. analoge Tools in anderen Browser, probier mal F12). Ansonsten einfach in Dein Stylesheet reinschreiben, das überschreibt ggf. Angaben des Plugin-CSS-Files.

    Wenn Du die ganze Welt auf unbestimmte Zeit aussperren willst, bietet sich das "Maintenance Mode"-Plugin an. Ich weiß aber nicht, wie lange Google das einfach hinnimmt, bis die Seite aus den Ergebnissen verschwindet.

    Änderungen an Themes und Plugins würde ich lokal austüfteln. Siehe FAQ: Wie kann ich WordPress auf meinem heimischen Rechner installieren?

    Ja, das Limit liegt bei dem in PHP (glaube ich) eingestellten Limit an POST-Variablen. WordPress schickt das beim Speichern ja alles an den Server zurück, und zwar mehrere Felder pro Menüpunkt. Bei sagen wir mal 4 Formularfeldern pro Menüpunkt kommt man relativ schnell an das Limit, das bei 150 oder so liegt (nagel mich nicht auf die genaue Zahl fest, ist eine Weile her, dass ich das gelesen habe).

    Bei so vielen Seiten macht es vielleicht Sinn, nicht das manuell zusammengebaute Menü zu verwenden, sondern das Menü automatisch aus den statischen Seiten aufzubauen, ggf. mit weiteren dazugefügten Seiten?! Entweder einfach über die WP-interne Funktion, oder direkt im Theme oder das Theme so ändern, dass dort ein Widget-Bereich angezeigt wird und dann ein eigenes Widget dafür kreieren.

    Deaktivieren reicht nicht, Du musst auch die gecachten Dateien löschen. Die werden sonst über den Apache immer noch ausgeliefert. Kann auch sein, dass in der .htaccess noch was drinsteht, was auf den Cache-Ordner verweist. So genau kenne ich mich da nicht aus.

    Alternativ könntest Du Dir natürlich mal die Doku des Plugins zu Gemüte führen und es korrekt einrichten. Caching ist ja an sich eine gute Sache. Es reicht aber leider nicht, es einfach nur zu aktivieren, und ich wundere mich immer wieder, wieso Leute das denken. ;-)

    Nein, kann ich nicht nachvollziehen. Habe es gerade gezogen und unter Ubuntu problemlos entpackt. Probier mal ein anderes zip-Programm aus oder schau nach, ob eventuell AntiViren-Software an der Datei gepfuscht hat. Hast Du zudem die Größe kontrolliert? Die Datei sollte 4.5 MB groß sein. Falls sie nur unvollständig heruntergeladen wurde, kann WinRAR sie natürlich auch nicht auspacken.

    Die loop.php gibt dasd aus, was Du auf Übersichtsseiten wie der Startseite oder einem Kategoriearchiv siehst. Die loop-single.php gibt die Einzelansicht eines Beitrags aus. Ich kann gerade nicht sagen, ob sich die Zeilen in den beiden Ansichten unterscheiden, vermutlich nicht.

    Also fang mal mit der loop.php an und nimm dort die gewünschten Zeilen raus. Ein bisschen PHP Lesen können wirst Du dafür aber müssen, sonst klappt das nicht. Ich habe das Theme gerade nicht zur Hand, sonst könnte ich es Dir genauer sagen. Und dann musst Du in Deinem Ziel-Theme natürlich die Stelle finden, wo es hin soll, vermutlich die index.php und ggf. weitere Dateien wie archive.php, category.php, tag.php, search.php etc. In vielen Themes ist das leider nicht so schön ausgelagert wie in Twenty Ten / Twenty Eleven.

    Das gleiche dann für sie loop-single.php, deren Code müsste in die single.php und ggf. in die page.php (für statische Seiten). Das entsprechende CSS müsstest Du dann natürlich auch übernehmen, sonst hast Du nicht viel gewonnen. ;-)

    Ok, ich rate mal: Du hast die Domain nicht wirklich auf den Webspace geschaltet, sonderhn leitest nur darauf weiter. Dann passiert folgendes:


    • Du rufst domain.de auf. Der Hoster dieser Domain sagt Deinem Browser, er soll doch bitte acount.billighoster.de aufrufen.
    • Dein Browser ruft acount.billighoster.de auf. WordPress schaut in den Einstellungen nach und sieht, dass die Seite über domain.de laufen soll. Es sagt Deinem Browser, dass er doch bitte domain.de aufrufen soll.
    • Dein Browser ruft domain.de auf.
    • Wiederholen bis irgendwann der Browser keine Lust mehr hat.


    Wenn Du die Domain so nutzen möchtest, dass sie oben in der Browser-Adresszeile stehen bleibt, dann solltest Du sie beim gleichen Provider registrieren, bei dem Du auch den Webspace hast, und direkt auf den Webspace schalten. Bei manchen Providern kann man das auch mit externen Domains machen, das kostet aber in der Regel einen kleinen Betrag und bringt IMHO wenig Vorteile.

    Es ist Deine Seite, Du solltest eigentlich wissen, welche Plugins dort laufen und was sie tun!? Konten zu sperren ist jedenfalls kein Bestandteil von WordPress, das muss aus einem Plugin oder dem Theme kommen. Bei einer WP-Installation ohne alles kannst Du Dich so oft falsch anmelden wie Du willst. Es macht aber durchaus Sinn, Brute-Force-Angriffe dieser Art zu unterbinden.

    Wenn Du weist, welches Plugin es ist, kannst Du den Ordner des Plugins per FTP umbenennen. Dadurch wird das Plugin deaktiviert und Du müsstest Dich wieder normal einloggen können. "Limit Login Attempts" sperrt übrigens meines Wissens nach nicht Konten sondern IP-Adressen. Falls es dieses Plugin ist, wäre es also einen Versuch wert, den Zugriff von einem anderen Internetanschluss aus zu probieren.

    Oben in der functions.php Deines Themes steht eine Leerzeile, zeilenumbruch oder so vor der öffnenden PHP-Tag. Das wird ausgegeben und dann kann WP keine Header mehr senden, was an allen Ecken zu Fehlern führt. Stel also sicher, dass die Datei direkt mit <?php beginnt und, falls sie UTF-8 ist, ohne einen BOM gespeichert ist.