Beiträge von Ammaletu

Sorry, ich glaube, da musst Du noch mal genauer erklären, was Du machen möchtest. Geht es Dir um eine zweite (neue) Sidebar auf der linken Seite?

Sorry dass ich oben iFrame geschrieben habe, es ist ein normales Frameset. Für eine kurze Erklärung, was ein Frameset ist und tut: http://de.selfhtml.org/html/frames/definieren.htm

Frames sind an sich veraltet und sollten nicht mehr verwendet werden wenn möglich. Zudem hast Du hier ein Frameset mit nur einem Frame, dessen einziger Sinn es ist, die eigentliche Adresse Deines Blogs zu verstecken. Das ist aus Nutzersicht nicht sinnvoll, weil man dann egal auf welcher Seite man ist immer nur die Domain sieht (und eben keinen RSS-Feed). Und Suchmaschinen kommen damit ggf. auch nicht so gut klar.

Schreib uns bitte zuerst mal, welche Adressen Du im Backend von WP unter Einstellungen > Allgemein > WordPress-Adresse/ Blog-Adresse stehen hast. Und dann überleg Dir, ob der Blog in Zukunft unter http://zentrumsblog.de/ oder http://zentrumsblog.de/Blog/ erreichbar sein soll. Dann können wir Dir genauer sagen, was zu tun ist.

Schon mal als Tip vorab: Egal was Du an der DB änderst (und nicht einfach so die Adressen ändern!), mache ein Backup der DB. Falls Du bisher keines hast, wäre jetzt der beste Zeitpunkt, ein regelmäßiges Backup einzurichten. Es gibt Plugins, welche Dir z.B. einmal pro Woche die DB gezippt per E-Mail schicken.

Gib der Query mal die Kategorie-ID und nicht den Namen mit. Bin nicht sicher, ob die mit dem Namen was anfangen kann. So kriegst Du vielleicht immer einfach die 5 aktuellsten Einträge ausgegeben.

Du brauchst übrigens Simple Tags nicht wirklich, außer eventuell für den Input. Ansonsten bietet WP so auch schon viel Unterstützung für Tags, also probier ggf. erst mal aus, ob Du ohne Plugin auskommst, wenn die alten Tags konvertiert sind.

Ach so, geht es Dir nur darum, nicht manuell ein Array mit den Kategorie-IDs anlegen zu müssen? Eine kurze Google-Suche spuckt diese Funktion aus:
http://codex.wordpress.org/Function_Refer…ll_category_ids

Testde doch mal, ob das global alle Kategorien zurückgibt. Dann müsstest Du das ja als Input für den Codeschnipsel nehmen können, den ich hier gepostet hatte.

Das hier kennzeichnet PHP-Blöcke:

<?php


?>

In den WP-Dateien darf da nichts davor und nichts dahinter stehen. Also nicht so:

<-- Leerzeile
<?php


?>

Oder so:

<?php


?>   <-- Leerzeichen

Oder so:

<?php


?>   <-- Zeilenumbruch
<?php
 
?>

Das fängt nur Brute-Force-Angriffe auf dem Loginformular ab, was ja aber auch schon mal gut ist, vor allem wenn man viele Nutzer hat, die man nicht alle zu starken Passwörtern zwingen kann. .htaccess-Schutz macht die Sache natürlich relativ wasserdicht, aber wenn sich da viele verschiedene Leute registrieren können sollen, ist das nicht sehr praktisch. Es sei denn, man kriegt es hin, Registrierung, Login und ggf. Edit-Arbeiten ins Frontend zu verlagern.

Ich nehme an, das wird dieser Code-Abschnitt sein:

<script><!-- //LinkWithinCodeStart
var linkwithin_div_class="linkwithin_hook";
var linkwithin_site_id = 238512;
</script>

Da wird ein Kommentar geöffnet, aber nicht wieder geschlossen. Wenn andere Browser den Rest der Seite anzeigen, ist das reine Nettigkeit.

Es sind wohl falsch verschachtelte Tags dabei. Das kann halt theoretisch die Ursache sein für unterschiedliche Darstellung in verschiedenen Browsern. Ansonsten ist es einfach so, dass man in so einer Menge an Fehlern dann die tatsächlichen Probleme nicht mehr sieht. Deswegen finde ich sollte man das so gut es geht Richtung 0 drücken.

Super-Cache ist nicht dämlich, nur sehr mächtig. Man muss damit halt wissen, was man tut. Dämlich ist es, dass manche Hoster das wohl gutmeinend zusammen mit WP installieren. Dann gehen auch Nutzer hin und aktivieren sich das, die den Super-Cache weder brauchen noch konfiguriert haben. Schreib Deinem Hoster ggf. mal, dass das keine gute Idee ist. Das Plugin ist wirklich für fortgeschrittene Nutzer und größere Webseiten gedacht.

Ja, müsste, tut es aber nicht, wenn die Dateien mit verschiedenen Codierungen abgespeichert sind. Wenn Deine Seite z.B. als UTF-8 ausgeliefert wird, müssen auch die Themedateien alle als UTF-8 (ohne BOM) abgespeichert sein. Wenn Du die mit einem schlechten oder falsch eingestellten Editor bearbeitest und aus Versehen als ISO-8859-1 / Latin-1 speicherst, passiert das eben mit Texten, die direkt in den PHP-Dateien drinstehen. Finde also erstmal heraus, welche Codierung gebraucht wird und speichere die Dateien dann neu ab. Man kann die Codierung in guten Editoren im "Speichern unter"-Dialog einstellen. Eventuell musst Du die nun kaputten Umlaute aber vorher konvertieren oder danach neu eintippen (Suchen & Ersetzen).

Du müsstest hier erst mal unterscheiden zwischen Texten, die aus dem Theme kommen, und Texten, die aus der DB kommen. Wenn Themetexte kaputt sind, kommen diese entweder direkt aus einer Themedatei (Datei als ISo statt UTF-8 gespeichert oder andersherum?) oder aus der Sprachdatei (Datei kaputt?). Wenn es Inhalte aus der DB sind, wäre zu schauen wie diese ausgegeben werden. UTF-8-Umlaute können durch falsche PHP-Methoden schnell kaputt gehen. Eventuell filtert ein Plugin oder die functions.php des Themes die Menüausgaben?

Um einzelne Widgets auf einzelne Seiten einzuschränken kannst Du das Plugin "Widget Logic" nutzen. Aber nicht zu exzessiv nutzen, geladen werden die Widgets trotzdem auf jeder Seite. Für die Startseite müsste is_front_page" gehen.

Je nach Version ist der IE teils sehr Bug-behaftet. Testen würde ich ehrlich gesagt nur noch IE ab Version 7, es sei denn Du machst Webseiten für große Konzerne oder die britische Regierung (woah, tun mir deren Programmierer Leid *g*).

Stell zuerst mal sicher, dass Deine Seite valide ist, damit sie im IE nicht im Quirksmode läuft: http://validator.w3.org

Danach kann man dann schauen, was im IE genau nicht stimmt. Dafür wäre ein Link zur Seite gut, dann kann man das am lebenden Objekt testen.

Wenn das definitiv im Default-Theme nicht funktioniert, wird es vielleicht von einem Plugin verursacht?! Eventuell mal mögliche Kandidaten deaktivieren und schauen. Falls es im Default-Theme geht, ist das Formular vielleicht in Deinem Theme nur falsch eingebunden.

Noch mal um das kurz zu checken: Wenn Du schreibst "Simple Tagging", meinst Du dann dieses Plugin:
http://wordpress.org/extend/plugins/simple-tags/

Oder wirklich das uralte "Simple Tagging"-Plugin?!
http://wordpress.org/extend/plugins/simple-tagging-plugin/

Letzteres ist nur bis WP 2.2 kompatibel, sollte also seit Jahren nicht mehr benutzt werden. Wenn Du die Tags damit erstellt hast, sind sie in ihrer eigenen Tabelle und WP kennt sie natürlich nicht. Die müsstest Du dann importieren. Entweder damit: http://wordpress.org/extend/plugins/simple-tagging-import/ Oder mit einem in "Simple Tags" vermutlich verbauten Import. Was auch immer: Backup vor jeder Datenbank-Änderung machen!

Was natürlich sein kann: Hattest Du das Default-Theme angepasst und wurde das eventuell beim Update überschrieben? In dem Fall müsstest Du die Änderungen aus dem Backup wieder zurückspielen per FTP.

Die Notices kannst Du ignorieren, die Warning sieht so aus als hätte jemand ein Leerzeichen oder Zeilenumbruch wo eingebaut wo es nicht hingehört. Normalerweise ist da die wp-config.php oder die functions.php des Themes der erste Verdächtige. Wenn da nichts zu sehen ist (es darf kein Leerzeichen / Leerzeile außerhalb der PHP-Blöcke stehen), könntest Du mal alle Plugins deaktivieren indem Du den Plugin-Ordner per FTP kurz umbenennst.

role-Attribut: Müsstest Du ignorieren. Das bastelt WP selber an die Suche dran, ist aber erst in HTML 5 vorgesehen, glaube ich.

Zur Umstellung auf die Posts pro Kategorie hatte ich weiter oben ja schon Code gepostet. Sorry, ich hab nicht die Zeit, das copy&paste-fertig zu machen.

Wenn sich da andere Nutzer registrieren können, würde ich das Verzeichnis eher nicht mit .htaccess schützen. Das kann man machen, wenn man alleiniger Nutzer ist. Das Plugin "Limit Login Attempts" hilft dann vielleicht etwas weiter bei der Absicherung.