Beiträge von Ammaletu

Wenn Du auf einer anderen Seite bist, bist Du ja eben nicht mehr auf der Blog-Seite. Das ist also schon richtig so. Ändern kannst Du das vermutlich mit einem Filter, der das Ergebnis von wp_list_pages filtert und die Klasse wieder einfügt (abhängig von einer Bedingung wie (!is_page() is_page(ID der Blog-Seite)).

Ich glaube, ich verstehe Deine Frage nicht ganz. Jedes Theme, dessen Dateien Du hast, kann bearbeitet werden. Ob das über die WP-Oberfläche klappt, hängt möglicherweise von Deiner Serverkonfiguration und den vergebenen Rechten ab. Aber niemand hindert Dich daran, die Dateien auf Deinen Rechner zu ziehen und mit einem Text-Editor zu bearbeiten.

Ich weiß es nicht genau, aber ich nehme an, dass da ein gewisser Timeout-Wert gesetzt ist. Der XML-Feed wird auf jeden Fall auf dem Server gecacht, damit der Feed nicht bei jedem Seitenaufruf gezogen werden muss. Wenn es ein Full-Content-Feed ist, kann der ja durchaus auch sehr groß sein, und das würde dann den Seitenaufbau nachhaltig verzögern, wenn WP den bei jedem Laden der Seite ziehen würde. Ich kann Dir ohne in den Quelltext zu schauen aber nicht sagen, wie oft WP den Feed neu abfragen würde.

Tja, in den Beitrag kann ich ja nicht direkt reinschauen, in die DB auch nicht. Aber im HTML-Output steht eben hinter "[COLOR=#000000][COLOR=#007700][/COLOR][COLOR=#0000BB]Download[/COLOR][COLOR=#007700][/COLOR][COLOR=#0000BB][/COLOR][COLOR=#007700] ([/COLOR][COLOR=#0000BB]12[/COLOR][COLOR=#007700],[/COLOR][COLOR=#0000BB]2 MB[/COLOR][COLOR=#007700][/COLOR][/COLOR])" ein schließendes div, was da nicht hingehört. Das ist die Ursche für die Sidebar-Verschiebung, und es wäre halt die Frage, wo es herkommt. WP wird von sich aus eher nicht ein öffendes p mit einem schließenden div einfügen, will ich doch mal hoffen zumindest. Steht der Download-Link denn so im Quelltext des Beitrags oder wird der irgendwie anders eingefügt? Über ein Plugin generiert oder so?

Hm, viel fällt mir da nicht ein, fürchte ich. Mein Blog verbraucht jedenfalls ca. 17 MB mit über einem Dutzend Plugins. 25 MB ganz ohne Plugins kommt mir relativ viel vor. Du könntest auf jeden Fall mal schauen, dass WP mit PHP 5 läuft und wie viele Queries ein normaler Seitenaufruf verursacht.

Das ändert jetzt aber nicht wirklich was an Deinem ursprünglichen Problem. Wenn Du einen Beitrag per Client postest, sollte das ja z.B. mit den Queries des Themes nichts zu tun haben, denke ich. Kennt sich da vielleicht sonst noch jemand aus oder kann einen guten Client dafür empfehlen?

Die Sprache legst Du in der wp-config.php fest.

Erstens, wieso 2.7? Irre ich mich oder gab es da auch schon eine aktiv ausgenutzte Sicherheitslücke? Und zweitens: Was genau ist denn Dein Problem damit? Soweit ich weiß sollte NGG schon mit allen aktuellen WP-Versionen funktionieren, aber vielleicht nicht mit jeder Serverkonfiguration. Wenn es an einem PHP-Modul fehlt, hilft Dir aber ggf. auch ein anderes Plugin nichts.

Zitat

Jetzt wollte ich gerne neue Kategorien in der Sidebar anlegen, aber alle Versuche sind bis jetzt gescheitert.

Leere Kategorien werden in der Sidebar in der Regel nicht angezeigt. Lege mal einen Beitrag in die Kategorie, dann sollte sie dort auftauchen.

Zitat

Zudem suche ich den Menüpunkt "Verwalten". Dieser fehlt in meiner Menüleiste völlig. Liegt das an 10.4.7 oder was ist verkehrt?

Das hat nichts mit Deinem Betriebssystem zu tun. "Verwalten" gab es früher mal als Menüpunkt, in einer der letzten Versionen (2.7, 2.8?) wurde das aber umorganisiert. Du findest die Blog-Beiträge jetzt unter dem Punkt "Artikel" (Tags und Kategorien auch) und die Seiten unter "Seiten". Klapp doch einfach mal alle Untermenüpunkte in der Backend-Navigation auf, dann solltest Du alles finden.

Zitat

nur leider wenn ich auf den google-sitemap-generator gehe, ist alles leer

Das müsstest Du bitte mal näher erklären. Welche Seite im Backend rufst Du genau auf? Und was heißt "alles leer" -- die berüchtigte weiße Seite? Falls ja, dann bitte ins Error-Log schauen und die genaue Fehlermeldung nennen. Das ist in der Regel ein Zeichen für einen PHP-Fehler.

Also irgendwas muss ja passiert sein, von selbst kommt sowas nicht. Offenbar versucht das Backend, die Datei "bannerspalte.html" einzubinden, die es aber nicht findet. Soll das so? Wird das vielleicht in der functions.php des Themes mit eingebunden oder so? Die wird nämlich auch im Backend geladen. Dann wüsste ich aber auch nicht, wieso die Datei nicht gefunden wird.

Und dann wird noch bemängelt, dass die Funktion have_posts nicht gefunden werden kann. Die steht in wp-includes/query.php und sollte immer da sein. Da bin ich gerade nicht sicher, ob das ein Folgefehler des ersten Problems sein kann. Schau aber trotzdem mal nach (per FTP), dass die query.php korrekt vorhanden ist.

Vermutung: Jemand hat aus Versehen die index.php des Themes ins Verzeichnis wp-admin kopiert. Ist jetzt aber echt bloß geraten (passt aber dazu, dass ich beim Aufruf der wp-login.php Deine Startseite sehe, nur ohne Stylesheets). Falls ja ersetze die Datei einfach wieder per FTP.

Zitat

Wenn ich mir so ein Widget installiere, ist es denn dann auch möglich, ganz normal in die PHP-Dateien einen Ruf/Befehl(?) (wie nennt man das eigentlich?)

Funktionsaufruf.

Zitat

hinein zu schreiben, um die Zeit angezeigt zu bekommen?

Kommt drauf an. Was ein Widget im WP-Sinn ist, weißt Du? Das fügst Du einfach im Backend der Sidebar hinzu und kannst dann vermutlich für das Widget einstellen, welche Zeit es anzeigen soll. Da brauchst Du dann gar kein PHP. Wenn Du das gleiche noch an anderer Stelle im Theme brauchst, kann man ggf. sicher auch manuell die Funktionen des Widgets aufrufen, aber gedacht ist es dafür nicht.

Zitat

Das soll das

PHP-Code:
[LEFT] [COLOR=#000000] [COLOR=#0000BB][COLOR=#007700]<[/COLOR][COLOR=#0000BB]div [/COLOR][COLOR=#007700]class=[/COLOR][COLOR=#DD0000]"entry"[/COLOR][COLOR=#007700]>
[/COLOR][COLOR=#0000BB] [/COLOR] [/COLOR][/COLOR] [/LEFT]

schließen.

Alles anzeigen

Das div wird schon in der Themedatei geschlossen, da wo es auch aufgemacht wird. Das hat nichts im Eintrag verloren. Ich könnte mir vorstellen, dass deswegen auch das schließende p fehlt, weil WP dann durch das /div durcheinander kommt. Firebug stellt das immer als Baum dar, das heißt aber nicht, dass es so im Quelltext auch drinsteht.

Also grob über den Daumen gepeilt, was ich hier im Forum so mitbekommen habe, sollte jede WP-Version mit sagen wir mal 25 MB auskommen. 36 auf jeden Fall. Das jemand 64 ausreizt habe ich noch nie gehört. Ist aber auch egal, offenbar gelten für Dein WP ja nicht 64 sondern 16 MB, und das ist eben so in etwa die Grenze. Mein Blog liegt z.B. bei 17 MB, mit vielleicht etwas unter 20 Plugins.

Als Notbehelf fürs erste könntest Du die Sprachdatei ausschalten. Die frisst wohl einiges an Speicher weg, jedenfalls auf manchen Servern. Aber auf längere Sicht musst Du dahin kommen, dass WP mehr als 16 MB zur Verfügung hat. Dafür müsste Dein Hoster Dir erstmal glaubhaft machen können, dass er den Wert wirklich auf 64 MB erhöht hat.

Tja, so ganz verstehe ich im Moment auch nicht, wie das passiert. Wie gesagt, die spitzen Klammern sollte WP selber korrekt maskieren. Das p fügt WP ein, es müsste aber eigentlich auch das schließende p dafür einfügen. Wo kommt denn das schließende div in dem Eintrag her? Steht das so im Quelltext des Beitrages drin?

Zitat

Kann man beim Überfliegen erkennen, ob da irgendwas verantwortlich für den Sidebar Fehler ist?

Höchstens per Zufall, das ist doch gerade mein Argument dafür, die Seite möglichst fehlerfrei zu kriegen.

Zitat

Allerdings gibt er jede Menge Errors aus, die ich nicht wirklich verstehe - sorry *zerknirscht guck*

Der Validator gibt unter jeder Fehlermeldung eigentlich eine halbwegs brauchbare Erklärung des Fehlers aus. Aber gut, schauen wir mal:
- "required attribute" sollte klar sein, fehlt halt
- "ID already defined" sollte auch klar sein -- IDs müssen eindeutig sein, dürfen also nicht doppelt vorkommen --> Mit Klassen statt ID arbeiten falls möglich.
- "document type does not allow element "div" here" --> Nicht jedes Element draf überall stehen. In diesem Fall steht ein div innerhalb eines a-Elementes. Das ist ein Inline-Element und darf kein Block-Element enthalten. Mach ein span aus dem div.
- "end tag omitted" --> XHTML, also Tags immer schließen. Für hr, br, img, meta etc. als <hr /> schreiben.
- " character "&amp;" is the first character of a delimiter but occurred as data" --> Die spitzen Klammern, das Anführungszeichen und das Ampersand (&) muss immer maskiert werden, wenn es im Text auftaucht. Das Kaufmannsund als "&amp;".

So, alle 300+ Fehler gehe ich nun auch nicht durch. Wie man sieht ist dadurch der Validator als Hilfsmittel zur Fehlersuche effektiv ausgeschaltet. :-/

Ich schaue vielleicht später noch mal, woher die falsche Verschachtelung kommt, falls ich Zeit habe.

Update:
Wie ich dachte, es ist im Beitrag falsches HTML enthalten. Das hier ist z.B. ein Eintrag:

<div class="entry">
    <p>Die Chucker der vergangenen Saison 2009 national und international, Polo People, Nachwuchstalente, Stickmaker George Wood, die Berenberg Trilogie (Hamburg, München, Düsseldorf), Polo auf Sylt, Polo in Berlin, die Deutschen Meisterschaften High Goal – die neue Ausgabe von Polo+10 verspricht spannende und aktuelle Themen. Bis die druckfrischen Hefte ausgeliefert werden, dauert es nicht mehr lange. Wer bis dahin nicht warten kann: Das aktuelle Heft bereits jetzt als Download<br />
 <a href="http://www.netpurse.com/download/12" onclick="return NPclick(this)" class="link" >>> Download</a> (12,2 MB)</div>
 </div>

Die beiden nicht maskierten ">" kann der Browser vielleicht noch ignorieren, aber dann wird ein div statt einem p geschlossen, und damit hast Du dann das entry-div zu früh zugemacht und alles nachfolgende rutscht auf die falsche Ebene. "#topbutton" und "#zurueck" sind plötzlich nicht mehr Teil von "#contentU" und "#infospalte_wordpress" ist nicht mehr Teil von "#main" sondern kommt erst danach.

Das div musst Du manuell korrigieren, falls das so in den Beitrag eingefügt wurde (Schaue gerade in die single.php -- Ja, sieht nicht so aus, als käme das aus der Themedatei). Bei den nicht maskierten ">" bin ich mir aber nicht sicher, wie das passieren konnte: Das sollte WP eigentlich in jedem Fall beim Speichern korrekt ersetzen.

Diesen Fehler sieht man mit Firebug übrigens in wenigen Minuten, wenn man eine korrekte Seite mit einer defekten vergleicht (oder die beabsichtigte Seitenstruktur kennt).

Ich will Dich wirklich nicht entmutigen, aber ich bin nicht sicher, ob sich ein stimmiges Umdesign des Themes machen lässt ohne CSS-Vorkenntnisse. Das ist leider nichts, was man mal eben nebenbei mit kurz Draufschauen auf das Theme macht. Dazu ist Dein Wunsch einfach zu unspezifisch (im Gegensatz zu etwas konkretem wie "Wie ändere ich die Linkfarbe" oder so). Also nicht wundern falls keine Antwort kommt. Vielleicht irre ich mich aber auch und hier hat jemand viel Zeit oder das Theme zufällig auch im Einsatz.

Im übrigen, wenn Du Code postest (und da zählt auch CSS dazu), kennzeichne ihn bitte entsprechend (mit einem der drei Buttons rechts oben). Das macht Deinen Beitrag wesentlich lesbarer.

Und nun sehe ich gerade, dass Du im Forum des Theme-Autors schon Hilfe gefunden hast. Sehr schön, da passt das IMHO auch besser hin.
http://www.arrastheme.com/forums/topic.php?id=1216

Der Umlaut-Fehler in den meta-Keywords ist noch drin. Die Angabe im content-type-Element muss "UTF-8" lauten, nicht "utf-8" (Groß- und Kleinschreibung ist da meines Wissens nach wichtig).

Aus welchen Dateien Dein Theme aufgebaut ist, ändert nichts daran, dass es als XHTML ausgeliefert wird (laut Angabe im doctype), sich aber nicht an die XHTML-Konventionen hält. Damit meine ich z.B. das hier:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

Was so aussehen sollte:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Das meckert der Validator bei Deiner Seite recht massiv an, und falls tatsächlich noch echte Fehler bestehen, kann man diese dazwischen halt nicht wirklich sehen.

Dann solltest Du vielleicht noch mal bei Deinem Hoster nachfragen, ob sie sich das erklären können. Vielleicht ist da beim Setzen des Wertes ja was schiefgelaufen.

Keine Ahnung, vom Arras-Theme hatte ich bisher noch nie gehört. Du kannst natürlich den Theme-Autor mal fragen, ob er quasi verschiedene Skins für das Theme anbietet. Wüsste ich jetzt aber auf Anhieb nicht, das es das überhaupt in einem WP-Theme gibt.

Mit "Permalinks" ist das Umschreiben von URLs wie "blog/index.php?id=123" zu z.B. "blog/2009/11/eintrags-titel" gemeint. Wenn das aktiviert ist hast Du normalerweise eine .htaccess-Datei im Root-Verzeichnis des Blogs, sonst eher nicht.

Es wäre jetzt halt rauszukriegen, wo der Speicher auf 16 MB gesetzt wird. Jedenfalls wenn wir mal davon ausgehen, dass Dein Provider sich beim Setzen auf 64 MB nicht vertan hat. Leg Dir doch mal im obersten Ordner Deiner Domain eine PHP-Datei an (z.B. speicher.php) mit diesem Inhalt:

<?php
  print ini_get('memory_limit');
?>

Ruf die mal auf und schaue nach, was dabei herauskommt. Dann packe sie mal in einen WordPress-Unterordner, z.B. wp-admin, und rufe sie nochmal auf. Und schau nach, ob im obersten Ordner eine php.ini-Datei vorhanden ist. Dann könnte man schon mal sehen, ob der Wert global richtig gesetzt ist und nur in WP auf 16 MB zurückgesetzt wird oder ob er vielleicht nie bei 64 MB war.