Ok, mal als Gegenargument: Ich habe Deinen verlinkten Artikel in ein lokales Testblog kopiert und konnte ihn da problemlos veröffentlichen. Ich denke, Du solltest also versuchen, herauszufinden wer genau das blockiert: WordPress, ein WP-Plugin (laufen da welche?, Apache (mod_security?) oder PHP-Module wie Suhosin. Dazu könntest Du die Seite z.B. mal lokal mit XAMPP klonen und schauen, ob es da geht. Dann wäre schon mal raus, ob es an WP oder einem Plugin liegt.
Beiträge von Ammaletu
-
-
Zitat
(mit UL/LIs wars leider nicht lösbar)
Das wage ich zu bezweifeln. Dem CSS ist es doch egal, ob es auf ein ul oder ein div angewendet wird.
Davon abgesehen: Wieso willst Du die eingebaute Funktion umschreiben? Was genau stört Dich daran? Wäre die Aufgabe nicht eher, das CSS für das Menü anzupassen?
-
Ich nutze z.B. "Xavin's Review Ratings". Damit kann man Sterne verteilen und der Wert der Sterne wird in einem Custom Feld gespeichert. Danach kann man natürlich auch eine Query sortieren oder einschränken. Mit etwas Programmierarbeit im Theme wäre das also kein Problem, denke ich.
-
Hat sich das geklärt? Ich sehe die Bilder nämlich (FF 3.6).
-
Also ich finde da z.B. dieses Plugin:
http://wordpress.org/extend/plugins/cimy-user-extra-fields/Das hat ziemlich viele Features, ich bin aber nicht sicher, ob es auch bei der Registrierung schon neue Felder einblenden kann. Im Nutzerprofil geht es auf jeden Fall.
-
Sicher, dass das an WP liegt und da nicht im Hintergrund z.B. Suhosin läuft?
-
Freut mich, dass es nun geht. Der Effekt, den Du da beschreibst, ist die Kaskade, die für das "C" in "CSS" sorgt.
Die einzelnen Elemente erben viele Eigenschaften eben von ihren Elternelementen. Über relative Angaben hängen Kindelemente zudem ebenfalls von ihren Elternelementen ab. Ich weiß nicht, was es in Deinem Fall genau war, aber wenn ich beim Elternelement die Weite und die Schriftgröße ändere, dann ändert sich natürlich das Kindelement, wenn dessen Weite in % und die Schriftgröße in % oder em definiert ist. Das kann teilweise zu wenig durchschaubaren Effekten führen, deswegen sind ja auch Tools wie Firebug so unverzichtbar bei der Fehlersuche. -
Zitat
warum sagst du das mit bedenken?
wo ist bei deiner lösung das problem?Weil ich das zwischendurch mal schnell zusammengehackt habe. Keine Ahnung wie gesagt ob das die beste Lösung ist. Da es funktioniert ist es aber schon mal besser als der jetzige Zustand des Plugins.

-
Zitat
Wenn ich die line-height: 1.25em auf 1em setze, verringert sich der Abstand noch mehr - richtig?
Richtig.
ZitatZum Verständnis: wofür steht em?
-
Du hast nicht zufällig eine entsprechende Seite, die man sich online anschauen kann? Auf dem Screenshot kann man ja schlecht in den Quelltext schauen.

Zuerst müsstest Du klären, ob der Text nur nicht angezeigt wird (im Quelltext aber da ist, also vielleicht CSS-Problem oder falsch geschachteltes HTML) oder ob er tatsächlich nicht da ist. Im Editor bleibt er ja erhalten, nehme ich an. In letzterem Fall wird das vermutlich ein Filter sein, der Sachen im Text vor der Anzeige ersetzt und dabei etwas falsch macht. Also TwentyTen-Theme einschalten und alle Plugins ausschalten und wenn es damit geht dann solange alles wieder anschalten bis der Schuldige gefunden ist.
-
Wenn es Dir egal ist, dass ggf. serialisierte Texte in Plugin-Einstellungen oder so kaputt gehen, kannst Du doch einfach einen DB-Dump vom Server ziehen, die URL und Server-Adresse darin global ersetzen (Text-Editor) und das dann lokal einspielen. Klappt wunderbar. Außerdem die .htaccess nicht mitkopieren sondern neu schreiben lassen durch Speichern der Permalinks lokal.
-
Falls es das nicht schon als Plugin gibt, kann man das mit wenigen Zeilen in der search.php selber machen, denke ich. Einfach ganz oben mit dem Suchwort ein get_posts ausführen (Query-Variable slug gibt es hoffentlich) und wenn da etwas zurückkommt, auf den Permalink des ersten Ergebnisses weiterleiten.
-
Geht es Dir um Nutzer/Autoren oder um Kommentatoren?
-
Jetzt mal abgesehen von dem Klammerfehler: Was ist genau Deine Frage dazu?
Wenn Du das ganze außerdem auf der Startseite ausführst, kann der else-Zweig doch weg, oder? Und im if müsste ein return ergänzt werden, damit der Server nicht beide Seiten schickt an den Nutzer. -
Hat das Theme keinerlei Doku dazu? Eine kurze Google-Suche förderte es nicht zu Tage, also müsstest Du schon allermindestens einen Link dazu angeben.
-
Kann es sein, dass das Theme die Textdomain für das Admin-Interface gar nicht lädt? Dabei müsste doch angegeben werden, von wo die Dateien geladen werden sollen.
Die pot- und po-Dateien sollten auf das Ergebnis in WP jedenfalls keinen Einfluss haben. Die sind ja nur für den Übersetzer da, WP liest nur die mo-Dateien, soweit ich weiß. Sind die neuen Dateien richtig benannt?
-
Das Limit liegt daran, dass WordPress pro Menüpunkt mehrere Felder an den Server zurückschickt. In PHP ist üblicherweise ein Limit für die Anzahl der Request-Felder eingestellt. Das kann man hochsetzen (wenn der Provider es erlaubt, mal über php.ini probieren), aber man stößt so oder so relativ schnell dran. Für richtig krass große und umfangreiche Menüs ist das WP-Menü eher nicht die richtige Lösung, denke ich.
-
Mach Dich mal mit einem Tool wie Firebug vertraut. Damit löst sich das in ca. 5 Sekunden. Also, Du hast ein div #main, das ist 940 Pixel breit. Darin hast Du ein div #container und ein ein div #primary. #container ist 940 Pixel + 80 Pixel Abstand nach links breit. Das passt schon mal nicht. #primary ist 220 Pixel breit -- wie soll das also daneben passen?
Entweder die Breiten stimmen nicht oder es ist etwas falsch geschachtelt. Letzteres sagt Dir auch der W3C-Validator.
-
-
Ausprobieren an einer lokalen Testinstanz, würde ich sagen (XAMPP, siehe FAQ). Oder online, falls die Seite noch nicht live ist. Permalinks sollten in aller Regel aus Performancegründen eine ID enthalten, z.B. domain.de/123/mein-beitrag. Mit dem Plugin müsste domain.de/123/de/mein-beitrag oder domain.de/de/123/mein-beitrag daraus werden (kenne es nicht aus erster Hand, aber URLs dieser Art sieht man ja ab und an).