Beiträge von Ammaletu

    Hallo!

    Ich probier mal, einige Deiner Frage zu beantworten:

    Zitat

    Die "Category" der Texte steht bloß unter dem Titel, doch ich wollte einzelne Kästchen haben, die z.B. betitelt sind mit "Über mich", "Inspirierende Musik", "Textfragmente", "Träume" ... also schön getrennt, und nicht einfach nacheinander.

    Wenn Du nicht bei wordpress.com wärest, sondern eine eigene Installation hättest, könntest Du das nach Belieben im Theme ändern (gewisse CSS- und PHP-Kenntnisse vorausgesetzt). Bei wordpress.com hast Du meines Wissens nach nur die Möglichkeit, aus den vorhandenen Themes auszuwählen.


    Zitat

    Ich komm auch mit den Tags nicht klar. Wozu benutzt man die? Sind das alternative Links zu meinen Texten? Hat das was mit Suchmaschinen zu tun?

    Da verweise ich mal auf diesen älteren Beitrag:
    http://forum.wordpress-deutschland.org/allgemeines/29…g-category.html
    Sag Bescheid, falls es dann noch nicht klar ist.


    Zitat

    Wenn ich einen Artikel (kann ich auch eine Kategorie - und wie?) auf privat stelle, können die dann nur 35 Leute sehen? Oder was bedeutet der UserLimit?

    Das wird wohl eine wordpress.com-Funktion sein, keine Ahnung. Bei der selbstgehosteten Variante sind private Artikel nur für angemeldete Nutzer zu sehen, soweit ich weiß. Da kann ich mich aber irren, habe das noch nie benutzt.


    Zitat

    PS: Ich habe keinen eigenen Server, sondern mich ganz einfach auf dem WordPress-Server registriert. Vielleicht ist das ja wichtig...

    Ja, das heißt nämlich, dass Du hier im Prinzip falsch bist. Dieses Forum beschäftigt sich mit der selbstgehosteten Variante. wordpress.com hat ja seinen eigenen Support mit eigenen Foren. Aber viel machen kannst Du da meines Wissens nach sowieso nicht. Dafür dass es kostenlos ist und mit minimalem Aufwand eingerichtet werden kann, hat man eben auch sehr wenig Möglichkeiten.

    Das ist ein Styleproblem und muss demnach mit 99% Sicherheit im Stylesheet des Themes behoben werden. Was möchtest Du denn machen? Die Seite generell breiter machen und den zusätzlichen Platz der Sidebar geben? Oder den Contentbereich in der Mitte kleiner machen?

    Für ersteres: Du müsstest die Weitenangabe bei #wrap größer machen. Und dann müsstest Du das Bild img/bg.gif bearbeiten und an die neue Weite anpassen (mehr Platz in der Mitte einfügen). Und dann müsste im Stylesheet noch der Sidebar der neue Platz gegeben werden.

    Fehlende Sidebars: Hast Du denn nun mal probiert, die Originalquery in Ruhe zu lassen und für Deinen Zweck eine eigene Query zu erstellen? Ich bin so halbwegs sicher, dass das Sidebar-Problem damit gelöst wäre. Siehe meine vorherige Antwort.

    Wie schon gesagt wird diese Datei in WP 2.6 nicht mehr benötigt und sollte deswegen auch gar nicht da sein. Das Updaten des Profils läuft bei mir über die profile.php. Die Frage ist also eher, wieso Dein WP das noch einbinden möchte. Entweder ist das Update nicht korrekt gelaufen (hattest Du von einer älteren Version aktualisiert?) oder Du verwendest ein Plugin, das nicht mit 2.6 kompatibel ist. Da würde ich eher die Ursache des Problems lösen, als irgendwelche Dateien hochzuladen, die dann wer weiß was in Deiner Datenbank anstellen. ;-)

    Ich tippe auf das "canonical URL"-Feature, welches alle Aufrufe über alternative URLs auf die Haupt-URL, welche in den Optionen eingetragen ist, umleitet. Ich hatte eigentlich immer angenommen, dass das genauso fürs Backend gilt wie fürs eigentliche Blog. Und klar, wenn in den Optionen die http-Adresse steht und Du rufst die https-Adresse auf, leitet Dich WP um. Das sollte eigentlich seit WP 2.3 (oder war's 2.2?!) so funktionieren.

    Was Du machen kannst... Hast Du mal gegoogelt nach "wordpress SSL" oder so? Dieses Problem hat ja vielleicht schon jemand anders gelöst.

    Genau kann ich Dir das auch nicht sagen. Nur soviel, sei sehr vorsichtig, was Du da tust, dass Du mit sowas keine Sicherheitslücken aufreißt. Davon abgesehen wirst Du Dir das irgendwo abschauen müssen, denke ich. Entweder in WP selbst oder aber in einem Plugin, welches ebenfalls den Login modifiziert. Es müsste z.B. Plugins geben, die WP mit LDAP integrieren, denke ich, die müssten ja das gleiche tun.

    Ich bin relativ sicher, dass das ein Rechteproblem ist. Das Plugin darf einige Dateien offenbar nicht lesen und auch Verzeichnisrechte nicht ändern. Teste vor allem mal, ob wenigstens die .htaccess im Backup-Ordner erstellt wurde, sonst könnten Deine Backups aus dem Netz abrufbar sein!

    Davon abgesehen hatte ich das Full Backup vor längerer Zeit mal getestet und konnte diese Sicherung nicht wiederherstellen. Da kamen dann nur Fehlermeldungen. Das SQL-Backup klappt aber hervorragend, und den Uploads-Ordner ziehe ich einfach alle paar Monate per FTP runter und lege ihn mir gezippt auf die Platte. Alles andere (WordPress, Themes, Plugins) hat man ja nornmalerweise eh schon lokal gesichert.

    Müsste man Lösung zwei nicht mit Positionierung hinbekommen? Ich stell mir das in etwa so vor:

    Damit müsste der Footer immer am Ende von "main" stehen, wo durch die padding-Angabe auch Platz sein sollte. Ist jetzt nur eine spontane Idee, nicht getestet, aber könnte gehen, denke ich.

    Mit welcher WP-Version arbeitest Du? Ich finde eine entsprechende Datei unter wp-admin in meinem 2.3.3, aber nicht mehr in 2.6.1. Falls Du 2.3.3 nutzt, schau mal nach, ob sie noch da ist.

    So oder so stimmt da irgendwas nicht. Ggf. solltest Du die WP-Dateien noch mal mit einem anderen FTP-Programm neu hochladen. Bei den Dateiübertragungen kommt es öfter zu Fehlern als man meinen sollte.

    Es gibt eigentlich immer zwei 404-Seiten, zumindest in der Standard-Konfiguration: Links, die von WordPress behandelt werden, liefern die WP-404 aus. Andere Links die Standard-404 des Servers. Das scheint bei Dir auch so zu sein.

    Der Link hier zeigt die WP-404-Seite:
    http://wishu-blog.net/index.php/allgemein/gibtsnicht/

    Und der hier die vom Server:
    http://wishu-blog.net/gibtsnicht/

    Das ist soweit normal, würde ich sagen. Vermutlich könntest Du das per .htaccess so umbiegen, dass immer die WP-404 angezeigt wird, falls Dein Hoster das erlaubt.

    Je nachdem welches Plugin Du benutzt (Link?), kann es sein, dass es mit dem graphischen Editor (TinyMCE) nicht funktioniert. Wenn man den Editor ausschaltet, greift WP wohl weniger in den eingegebenen Quelltext ein. Dann sollten entsprechende Plugins eigentlich recht zuverlässig funktionieren. Mit Editor kann es sein, dass der Editor da schon per JavaScript Änderungen vornimmt, ehe die PHP-Funktion des Plugins den Code vor dem Umschreiben z.B. der divs zu ps retten kann.

    Der verlinkte Bug ist als invalid geschlossen, denke also nicht dass das relevant ist. Ich gebe mal eine andere Vermutung ab: Die Funktion is_front_page() nutzt intern die Query der Seite, um zu bestimmen, ob es die Frontpage ist oder nicht. Wenn Du die Query änderst, machst Du diese Abfrage ggf. unmöglich. Wenn Du z.B. eine statische Seite als Startseite verwendest und deren Query im Seitentemplate änderst, geht vermutlich der is_page-Aufruf innerhalb von is_front_page schief. Ob das bei der dynamischen Startseite auch so passieren kann, bin ich mir gerade nicht sicher. So oder so produziert man ggf. hässliche Nebeneffekte wenn man die Hauptquery der Seite zu was ganz anderem ändert (also z.B. Kategorien statt einer einzelnen Seite auslesen). Nutze einfach gleich WP_Query zum Erstellen einer neuen Query, wie Du es in Deinen Ausschnitten ja auch schon gepostet hast. Ok, soweit meine Vermutung. Keine Gewähr für Richtigkeit, es ist eigentlich schon viel zu spät für solche Probleme. ;-)

    Also mir fällt auf Anhieb nur das hier auf, was mit ziemlicher Sicherheit falsch ist:

    PHP
    {echo " class=\"autor_kommentar\"";} else {echo " class=\"" . $oddcomment . "\"";} ?>>

    Da die Variable ja schon class enthält, wäre also richtiger:

    PHP
    {echo " class=\"autor_kommentar\"";} else {echo " " . $oddcomment;} ?>>

    Durch die falsche Schachtelung der Anführungszeichen kommt der IE vermutlich aus dem Tritt. Probier das mal. Falls es das nicht ist, wäre ein Link zur Seite wirklich das beste, weil man doch so ohne den Quelltext zu sehen eigentlich nur raten kann. ;-)

    Also am Code des Themes an sich sollte WP in keinem Fall etwas ändern. Die Sachen, die man in den Beitragen und statischen Seiten eingibt, werden u.U. verändert. Eigentlich immer werden z.B. die Anführungszeichen ersetzt und diverse andere solche typographischen Sachen. Dabei werden auch Absätze und Umbrüche eingefügt.

    Dann gibt es noch die Option "falsch geschachteltes HTML korrigieren". Ich kenne die Details nicht, schalte das bei mir aber vorsichtshalber immer aus. Und wenn dann der Kunde den TinyMCE-Editpr nutzt (graphischer Editor, individuell abzuschalten im Nutzerprofil), dann bastelt der auch noch mal am Code rum. Das war aber IMHO immer schon so und sollte sich mit 2.6 nicht speziell geändert haben. Denke ich. Ich schalte TinyMCE bei mir weitestgehend ab, damit man auch ungestört Code posten und Videocodes eingeben kann.

    Falls nichts davon so klingt, als wäre es die Ursache Deiner Probleme, schildere uns doch bitte mal genauer, was ersetzt oder verändert wird. Dann ist das sicher leichter zu sagen, woran es liegt.

    Davon abgesehen: Dein Kunde sollte sich bewusst sein, dass er durch die Eingabe falschen HTML-Codes die Seite zerschießen kann. Wenn er mit HTML nicht klar kommt, brauchst Du wohl den graphischen Editor und solltest dem Kunden nahelegen, nichts in der Quellansicht zu ändern. Und dann müssen Deine Styles auch mit dem klarkommen, was der TinyMCE ausspuckt. Wenn es an was bestimmten hakt, kannst Du TinyMCE aber z.B. auch gegen den FCKEditor austauschen (per Plugin).

    Ok, da war ich für einen Moment weggetreten. Du versuchst ja gar nicht, Deine eigenen Widgets zu schreiben. Ok, mal schauen. wenn Du before_widget nicht überschreibst, vergibt WP auf jeden Fall die IDs, die das Widget für sich registriert hat. Und ja, die sieht man dann später im Quelltext der Seite, dafür sind sie ja da.

    Wenn man nach "before_widget" sucht, ist das in der widgets.php eigentlich auch ganz simpel zu finden. Dein Beispiel müsste dann vermutlich so aussehen:

    Zumindest vermute ich, dass das genauso gehen müsste. Ausprobieren müsstest Du es aber selber. :-)

    WP fügt dann wie gesagt die ID ein, die das Widget dafür vorsieht. Bei einem Text-Widgets auf einer meiner Seiten ist das z.B. "text-157208801", bei meinen eigenen Widgets ist es die eingestellte ID. Gerade bei den mehrfach einfügbaren Widgets wie den Textwidgets wird Dir diese automatisch generierte ID für Stylingzwecke aber nichts nützen. Ggf. ist die dynamische Widgetklasse da sinnvoller. Also ergänzen wir die auch noch mal:

    Ich erhöhe mal Deine Chance auf eine sinnvolle Antwort, indem ich rate NIS =
    Network Information Service – Wikipedia
    Stimmt das oder ist was anderes gemeint?

    Wenn Du mit googlen nach "NIS wordpress" keine Lösung gefunden hast, würde ich nicht darauf wetten, dass das schon mal jemand integriert hat. Aber es müsste Integrationen mit Sachen wie Open ID geben. Ich habe leider nicht wirklich viel Ahnung davon, aber ich denke, das ist vielleicht Deine beste Chance, NIS über eine Art Bridge über so ein Protokoll anzubinden. Auch LDAP könnte es geben. Und schau mal, das hier habe ich gerade noch gefunden, vielleicht hilft das ja auch weiter?!
    WordPress and LDAP authentication « Tech Explorer

    Also ich sehe im IE7, dass einige Abstände größer sind als im Firefox, aber die grundsätzliche Anordnung scheint zu stimmen. Um den IE6 würde ich mich an Deiner Stelle ehrlich gesagt nicht mehr kümmern, es sei denn es ist eine kommerzielle Webseite.

    Prinzipiell werden Deine Probleme an den verschiedenen Boxmodels liegen, denke ich. Wie war das... Im Firefox gilt padding + border width + width = tatsächliche Weite der Box, während im IE der width-Wert immer die tatsächliche Weite der Box ist. Als Lösung kann man dem IE ggf. andere Weiten sagen. Dazu einfach eine style_ie.css erstellen und per Conditional Comments einbinden (Forensuche opder googlen). Das ist relativ sauber und funtkioniert gut. Im IE-Stylesheet kann man dann für den IE andere Angaben notieren und wenn es mal sein muss auch Hacks. Validatoren und andere Browser ignorieren das File ja. Klar, es muss dann nach dem normalen Stylesheet eingebunden werden, damit es dessen Angaben überschreiben kann.