Beiträge von Ammaletu

    Mit entsprechenden HTML- und CSS-Kenntnissen kannst Du das sicher problemlos in Dein Theme einbauen. Ohne wird es schwieriger. Zumindest denke ich nicht, dass ich Dir das hier mal eben so beschreiben kann. :-/

    Zuallererst solltest Du vielleicht überlegen was in die neue Spalte rein soll: Widgets, feste Bilder, Werbung oder pro Beitrag unterschiedliche Inhalte? Und welches Theme verwendest Du eigentlich?

    Also ich habe für alle meine Blogs jeweils eine Testversion auf meinem lokalen Rechner (per XAMPP, siehe FAQ). Neue oder aktualisierte Plugins, Theme-Änderungen etc. teste ich fast immer zuerst daran ehe ich sie auf den Server lade. Ganz am Anfang hatte ich glaube ich auch die Test-DB mal auf den Server exportiert, heute läuft es eher anders herum: Ab und an ersetze ich die lokale Test-DB, die nicht mehr aktuell und dafür mit Test-Beiträgen gefüllt ist, durch die Version vom Server, um auf dem gleichen Stand zu sein und an den gleichen Inhalten testen zu können. Das klappt soweit wirklich gut.

    Wenn das Blog wichtig ist, solltest Du in jedem Fall eine lokale Testinstallation aufsetzen (XAMPP), anhand derer Du das Upgrade dann testen kannst. Backups verstehen sich dabei natürlich von selbst.

    Ansonsten warte doch einfach mal ein, zwei Wochen ab, ob mit 2.8 größere Probleme auftauchen. Solange ansonsten von keinen Sicherheitslücken berichtet wird, kannst Du natürlich auch bei der 2.7 bleiben, wenn das Blog eh nicht für die Ewigkeit ist.

    Leg das Verzeichnis einfach mal an, und zwar genauso benannt wie es in den WP-Optionen eingetragen ist. Und dann stelle dafür die entsprechenden Zugriffsrechte ein. Das solte eigentlich jedes FTP-Programm hinkriegen. Erst dann kann WP Uploads wie z.B. in den exportierten Blogeinträgen enthaltene Bilder auf Deinem Webspace ablegen.

    Kurz gesagt: Generell wirst Du damit leben müssen, dass WP gewisse Dinge am Code ändert, und ich finde das auch sehr komfortable, wenn man sich erstmal dran gewöhnt hat. Zum Beispiel fügt WP ebven selber p-Tags ein, man lässt dafür einfach eine Leerzeile im Editor. Das gleiche für Zeilenumbrüche, einfach Enter im Editor drücken. Und das Ersetzen der Anführungszeichen und Gedankenstriche ist auch nicht schlecht.

    Wenn man weniger Einmischung will, gibt es zum einen eine Option "Inkorrektes HTML korrigieren" oder so ähnlich, die kann man schon mal abwählen in den WP-Einstellungen. Und dann kannst Du den TinyMCE in Deinem Nutzerprofil abschalten. Solange er aktiviert ist, wird WP einiges am Quelltext ändern, auch wenn Du Dich im HTML-Modus befindest. Und ansonsten einfach dran denken, nicht Leerzeilen zu lassen, wo in der Ausgabe keine hinsollen, also z.B. nicht zwischen zwei Listenpunkte einer ul-Liste.

    1. Wenn Du jedes Foto als einzelnen Beitrag einstellst, kannst Du die eingebaute Tag-Funktion von WordPress nutzen. Das sollte sich dann hoffentlich auch auf die Suche auswirken (obwohl ich es gerade nicht beschwören kann), und in jedem Fall kriegst Du dann eine Tag-Cloud.

    2. Ich glaube schon, dass es auch dafür Lösungen gibt, kann Dir aber gerade nichts konkretes empfehlen. Aber ich glaube, ich habe mal entsprechende Plugins gesehen. Da musst Du Dich aber zumindest etwas mit WP und PHP auskennen, denke ich, das wird nicht ohne Modifikationen gehen.

    3. Google z.B. mal nach "wordpress photo blog".

    4. Kannst Du auch gleich machen, so gravierend werden die Unterschiede zwischen 2.7.1 und 2.8 nicht sein. Schlimmstenfalls sind halt Anpassungen nötig, aber das kommt nicht so oft vor.

    Da brauchst Du dann natürlich auch einen lokalen Mailserver. Bei XAMPP ist soweit ich weiß MercuryMail dabei. Belies Dich dazu mal in der XAMPP-Doku, das müsste da alles erklärt sein. Installiere den Mailserver ggf. so, dass er nur läuft, wenn Du ihn auch brauchst, nicht dass den später ein Virus zum Mails verschicken nutzt. ;-)

    Da ich Facebook nicht kenne, kann ich es Dir nicht genau sagen, aber prinzipiell denke ich müsste das in Facebook erledigt werden. Da gibt es doch auch Plugins, Apps oder wie sie auch heißen. Da bräuchtest Du ein Facebook-Plugin, welches einen RSS-Feed auswerten bzw. darstellen kann und trägst dann einfach den RSS-Feed Deines WP-Blogs ein.

    Ich sag es immer wieder gerne: Fehler 500 = Interner Server-Fehler = Sollte eine Fehlermeldung mit dem eigentlichen Fehler in einem Logfile hinterlassen. => Wo musst Du selber wissen oder alternativ beim technischen Support Deines Hosters erfragen.

    Das wird schwierig, denke ich, da das Admin-Interface ja immer unterhalb des Blogs liegt. Falls Du keine Permalinks benutzt (also alle Blogseiten eine Adresse á la .../index.php?page_id=123 haben, schau ggf. mal im Backend in den Einstellungen unter "Permalinks" nach), könntest Du den Schutz nur auf die index.php anwenden, denke ich. Ob das mit dem Strato-Tool geht, weiß ich aber nicht, in der darunterliegenden .htaccess geht es aber sicher (was anderes macht das Tool ja auch nicht, nehme ich an).

    Na ist ja logisch, Du überschreibst ja auch die ursprünglich ausgeführte Query. Mein Ansatz von weiter oben bewahrt dagegen den ursprünglichen Query-String. Wenn posts_per_page nicht geht, nimm halt showposts. Bin mir gerade nicht sicher, was der Unterschied ist. Bei mir klappt das jedenfalls so. ;-)

    P.S.: Wenn Du das in die search.php einfügst, wie kann sich das auf ein Monatsarchiv auswirken? Sicher, dass Du die richtige Datei erwischt hast?

    Ja, das ist merkwürdig, muss ich zugeben. Ich sehe im Quelltext des Feeds allerdings, dass Du WP-SuperCache benutzt. Könnte es daran liegen, dass da irgendwas nicht richtig konfiguriert ist? Eventuell müsstest Du im Netz mal speziell nach Feedproblemen mit dem Plugin suchen oder das mal komplett abschalten + gecachte Dateien löschen.

    Die beiden Parameter kannst Du so verwenden:

    PHP
    wp_list_pages('meta_key=standardlinks&meta_value=yes');


    Damit müsstest Du nur die Seiten bekommen, die das Custom Field "standardlinks" mit dem Wert "yes" dran hängen haben. Ich weiß nun aber nicht, ob das auch andersherum geht, also die Ausgabe aller Seiten, die dieses Feld nicht haben.