Beiträge von Ammaletu

    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:

    PHP
    <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:

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

    Was so aussehen sollte:

    PHP
    <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.

    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
    <?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.

    Also in Deinem Theme steht oben (header.php vermutlich) das hier drin:

    PHP
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

    Das müsste natürlich auch UTF-8 heißen. Da der Server die Dateien als UTF-8 rausschickt, stellt der Browser sie auch so dar. Ich sehe jetzt auf Anhieb auch keine kaputten Umlaute.

    Update: Der kaputte Umlaut, den der Validator bemängelt, steht im meta-keywords-Tag. Wo auch immer die Keywords herkommen, sie werden offenbar nicht korrekt gespeichert. Falls sie fest in der header.php stehen, musst Du die Datei mal bitte als UTF-8 (ohne BOM!) abspeichern. Jeder gute Text-Editor kann das.

    Update 2: Aktuell sehe ich die Sidebar immer korrekt neben dem Text anstatt darunter. Hast Du was geändert? Die Variation kann auch durch Fehler im Inhalt des Beitrags kommen. Der kann ja HTML enthalten, und wenn das nicht korrekt ist, zerhaut es dann die nachfolgende Sidebar.

    Update 3: Die Validierungsfehler bleiben. Es sieht fast so aus, als würdest Du ein normales HTML-Template als XHTML ausgeben, deswegen die vielen Fehler wegen z.B. nicht geschlossener Tags. Wenn sich dazwischen ein echter Fehler verbirgt, sieht man ihn natürlich nicht. Außerdem spielt Dein Server irgnedwie mit dem Validator nicht richtig zusammen, ich kriege jedenfalls eine Einzelseite nicht validiert, außer ich lade den Quelltext hoch. Sehr komisch...

    Installier Dir mal das "Memory Usage" Plugin und schau nach, ob das als Grenze 16 MB oder 64 MB anzeigt. 16 wären tatsächlich etwas wenig, 64 sollten mehr als dicke ausreichen. Eventuell wird das Memory Limit noch irgendwo anders gesetzt? Es könnte ein Plugin sein oder vielleicht per .htaccess oder php.ini?

    Tja, das hängt nun davon ab, wie der Flash-Slider umgesetzt ist und woher er seine Inhalte bezieht. Diesen Inputwert (stelle ich mir zumindest mal so vor, dass die anzuzeigenden Inhalte dem Flash reingereicht werden) müsstest Du dann anpassen in der header.php. Kann ich Dir jetzt aber nicht genauer sagen, ohne mir das Teil im Detail anzuschauen.

    Zitat

    das hört sich nach ner längeren geschichte an, an die ich aus zeitgründen leider erst nächste woche rangehen kann.

    Naja, wenn Du es während des Umzugs machst, geht das in unter fünf Minuten. DB-Dump in einem brauchbaren Text-Editor öffnen und beide Sachen in der ganzen Datei ersetzen. Die Domain steht manchmal mit, manchmal ohne abschließenden Slash drin, also nicht nur eine Form davon ersetzen. Den genauen Serverpfad musst Du vermutlich erstmal raussuchen, genauso den neuen. Das kann halt auch an vielen Stellen stehen, Bilderpfade, Optionen von Plugins etc.

    Wenn die neue Seite nun schon läuft, müsstest Du das vermutlich tatsächlich in der DB ersetzen, da wäre dann das erwähnte Plugin vermutlich die einfachste Variante. Backup der Datenbank vorher machen! Dann sollte das aber auch nicht zu aufwändig sein.

    csign: Danke! Ich schreibe ja im Moment hauptsächlich privates, muss die Seite aber mal dringend umorganisieren und auch Platz für mehr technische Sachen schaffen. Freizeit bräuchte man... ;-)

    Ich sehe jetzt erst, dass Deine Seite in einem iFrame läuft. Wenn Du sie ohne iFrame aufrufst, zeigt der Browser in der Adressleiste das Feed-Icon an. Das müsstest Du dann wohl mit den beiden festen Pfaden auch ins äußere Frameset bringen.

    Code
    Mir wär ganz recht, wenn meine Besucher auch wüssten, wie sie meine Blogs abonnieren können. Wenn da zB. ein kleiner Button ist, wo sich jeder mit Email eintragen kann.

    Den Feed-Link könntest Du z.B. in der Sidebar noch mal unterbringen. Könnte man z.B. einfach in ein Text-Widget schreiben und das Feed-Icon per Stylesheet an dem Link ergänzen.

    Abonnieren per E-Mail geht so ohne weiteres nicht, der Feed ist ja nur eine XML-Datei. Da brauchst Du dann vermutlich einen Service wie FeedBurner, die bieten das an.

    Dann erkläre doch vielleicht für alle, die Facebook nicht kennen, mal kurz, wie das aussehen soll. Prinzipiell könntest Du z.B. in Deinem Theme einen neuen Widget-Bereich definieren, ein Text-Widget reinpacken und das per Stylesheet an der gewünschten Stelle ausgeben. Dann könntest Du das einfach über das Text-Widget editieren.

    Zitat

    Ich möchte das sich user auf dem blog selbst registrieren können und dann selber posten können.

    Einfach in den Optionen anklicken, dass die Registrierung erlaubt ist. Und dann die Registrierungsseite im Frontend irgendwo verlinken. Pass auf, dass Du den Nutzern nicht mehr Rechte als unbedingt nötig einräumst (einstellen, welche Rolle neue Nutzer haben). Und es wäre möglich, dass Du eine Captcha-Lösung brauchst, damit sich nicht zu viele Bots registrieren.


    Zitat

    Und weiterhin fänd ich es ganz toll wenns direkt auf der startseite ein Eingabefeld gäbe für neue einträge, ähnlich den schnell-eingabe feldern in diversen foren.

    Das gibt es im Dashboard, vielleicht reicht das ja schon? Ansonsten müsstest Du mal nach einem Plugin suchen.

    Einfach die normalen Funktionen der Mediathek nutzen, würde ich sagen. Also Thumbnail in den Text einfügen und auf das Originalbild verlinken. Wenn es ein Link daneben sein soll, dann musst Du den halt manuell neben das Bild einfügen.

    Zitat

    Ich selber benutze Firefox 2.0 (ich weiß, ist veraltet, aber es wird ja auch wahrscheinlich nicht jeder Nutzer der Website den neuesten haben)

    Doch, da würde ich beim Firefox durchaus von aus gehen. Durch das automatische Update ist es den Nutzern ja sehr leicht gemacht zu aktualisieren. ;-)

    Ich habe eben auch noch mal im IE8 geschaut: Richtig ist es bei Beitrag 2, falsch bei Beitrag 1, 3 und 4. Weiter habe ich da jetzt nicht getestet. Irgendwas stimmt da auf jeden Fall nicht.

    Den Validator kennst Du aber, oder?
    http://validator.w3.org/check?verbose=…o-magazin.de%2F

    Für die Startseite zeigt er leider obendrein auch noch einen Encoding-Fehler an.

    Für den Firefox würde ich Dir ansonsten die Web Developer Toolbar und/oder Firebug empfehlen. Mit beiden Tools kommt man Problemen dieser Art schnell auf die Spur.