Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenDas kann man so nicht sagen.
Welches Thema nutzt du? Hast du in diesem Thema mal in die entsprechende Templatedatei geschaut, ob das Wort "Kategorie" überhaupt mit dem typischen Übersetzungsgedöns (__("Category"), _e("Category"), usw.) drin steht? Vllt wurde es auch von der PO-Datei nicht erkannt, und du musst den Eintrag noch mal manuell vornehmen.
Dann schreib die interne ID der Seite rein, nicht den Namen. Das funktioniert auch
if ( is_page( 4 ) )
oder welche ID auch immer dein Impressum hat. ;)
Hallo, meine Kritik ist nicht unrichtig, sondern es wurde keinerlei Hinweis zu diesem Problem gegeben - es wurde eben nur ein Sicherheitsupdate publiziert. Schon im Vorfeld hätte man Hinweise zur Sicherheit geben müssen und notwendige Maßnahmen beschreiben.
So was findest du in vielen Bereichen. Wird eine Lücke entdeckt, hält sich der Hersteller der Software in der Regel erst mal zurück, um das Problem zu beheben. Auch der Entdecker wird zwar melden, dass er eine Lücke entdeckt hat, wird aber Details zurückhalten, damit diese Lücke nicht im großen Stil ausgenutzt wird.
Aber mit WP 2.4 wird ja alles besser :-D
Ich fürchte nicht, denn 2.4 wird als offizielles Release wohl übersprungen. :mrgreen: Sagen wir: mit 2.5 wird alles besser.
Ist dir da vllt ein Versehen passiert? Die einzige Datei "index.php", die auch bei mir den Text enthält, liegt im Ordner "wp-content". Macht ja auch Sinn. Manche Webserver erlauben das Verzeichnislisting. Und wenn du dann so einen Ordner aufrufst, siehst du die Dateien usw. Eine leere Indexdatei verhindert das.
Wo hast du denn diese Version her? Ich kann mir nicht vorstellen, dass so ein "Scherz" (ist nicht wirklich lustig) in einer offiziellen Version drin ist.
Üblicherweise sieht der Code so aus
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressKurz und schmerzlos: Sicherheitslücke in Wordpress erlaubt Änderung von Beiträgen - Golem.de
Wenn es wirklich "nur" um eine Sicherheitslücke geht, dann dürfte das Update auch für Besitzer der deutschen Version interessant sein. Die Sprachdatei wird sich da nicht großartig ändern, denke ich.
Details der Lücke würden mich (am Rande) interessieren. Ich nutze zwar 2.4-SVN, aber man sollte vllt mal lokal testen, ob die Lücke hier auch gefixt wurde.
(befürchte aber, da wordpress bei mir im unterordner meine schorleblog.de/wp liegt, dass RewriteRule oder RewriteBase einer entsprechenden anpassung bedürfen. mit intuition bin ich bereits gescheitert, d.h. es funktionierte nicht, wenn ich ... RewriteRule . /wp/index.php ... geschrieben habe oder/und ... RewriteBase /wp/ ...
Das sollte keine Rolle spielen. Mein Blog ist auch über die Hauptdomain erreichbar, obwohl WordPress in einem eigenen Unterordner liegt (Einstellungsfrage in den Optionen von WP). Und meine ".htaccess" enthält auch bloß den Slash / als RewriteBase.
trotzdem bleibt mir dann aber nicht erspart sämtliche gesetzten links händisch nachzubearbeiten (sofern es auch hier ein plugin oder programm gibt traue ich mir zumindest nicht zu, das fehlerfrei anwenden zu können), was ich liebend gerne vermeiden wollte.
Ich gebe zu, bei 200 Links ist der Aufwand enorm.
(zumal ich ja nicht jeden, der auf meine artikel verlinkt hat, um entsprechende anpassungen bitten kann)
Wieso Anpassungen? Änderst du deine Permalinkstruktur denn so oft? Es geht doch nur darum, dass du dir bei internen Verlinkungen (du verlinkst von deinem Beitrag A auf deinen Beitrag B) die Arbeit erleichterst. Wenn du wirklich mal die Domain wechselst oder die Permalinkstruktur, dann hat derjenige, der auf dich verlinkt, sowieso ein Problem. Du selbst allerdings auch, weil deine 200 Links dann noch auf die alte Domain bzw. auf die alte Linkstruktur verweisen.
Zwar habe ich keine Idee zu deinem Problem, aber das
lösche ich die htaccess-datei, bin ich wieder gezwungen die default-einstellung zu benutzen. bei geschätzten 200 internen verlinkungen ist das momentan die hölle.
ist exakt der Grund, warum ich interne Verlinkungen mit einem Plugin mache. Da sind die Permalinks nämlich egal. Du musst nur die interne Beitrags-ID wissen und mit einem speziellen Tag angeben. Dieses Tag wird durch das Plugin geparst und durch einen Link ersetzt. Ob der dann aussieht wie "?p=100" oder "/2008/01/01/beitragsname", das hängt von deinen Einstellungen in WordPress ab. Es ist also völlig egal, ob du deine Permalinkstruktur änderst oder deinen Blog auf eine andere Domain legst, die Verlinkungen funktionieren immer.
Auf Anhieb: Zeilen 231, 338, 368, 389, 446, 538.
Sind nur Vertipper. ;)
Soll diese andere Seite in einem anderen Design als der Blog angezeigt werden? In dem Fall empfehle ich eine simple Umleitung/Weiterleitung per ".htaccess".
Eigentlich ganz simpel: du klickst den Link an und die Einträge in der ".htaccess" werden wirksam: alles, was nicht als Datei oder Ordner existiert, wird an die "index.php" gereicht. Die (bzw. die tatsächlich zuständige PHP-Datei/Funktion/Klasse) dürfte feststellen, dass es den Beitrag mit der Adresse nicht gibt und in der "wp_postmeta" gucken, ob ein passender Eintrag existiert. Den gibt es, also ruft sich die "index.php" mit der korrekten Adresse neu auf, oder es erfolgt intern eine Auswertung/Weiterleitung auf den Beitrag.
Ich vermute nur, aber die Vermutung macht Sinn, denn wenn du den Eintrag in der "wp_postmeta" löscht, dann produziert der Aufruf des alten Links folgerichtig einen 404-Fehler.
btw, ich persönlich nutze für bloginterne Verlinkungen ein Plugin, dem ich die ID des Beitrags übergebe. So spielen weder Domain (.de, .com, .org, ...), noch Permalinks oder Postslugs eine Rolle. Der Beitrag wird in jedem Fall gefunden.
Es sind Seiten? Dann versuch es mal mit "is_page(10)" (die 10 als Beispiel für die ID). Geht übrigens auch einfacher per "is_page(array(10,18,19,..))", wie ich gerade sehe. Das spart einige or-Anweisungen. ;)
Die Antwort steckt in deinem Beitragstitel. :mrgreen: Du musst einen Redirect 301 auslösen, dann klappt es auch mit aktiven Permalinks
RewriteRule ... [R=301,L]Ach so, die Ursache: in deinem Fall fehlt ohnehin das [L] für "letzte Anweisung", was soviel bedeutet wie: wenn ausgeführt, dann ignoriere alles, was noch kommt. Das bedeutet, die Regel für WordPress wird dann wirksam. Und die nimmt ja alles, was kein existierendes Verzeichnis bzw keine existierende Datei ist und versucht es, als Blogbeitrag zu laden -> Fehler 404.
In meinem Fall reichte das aber nicht. Ich hing am gleichen Problem. Ich sehe in der Log-Datei noch ab und zu Zugriffe auf uralte HTML-Seiten, die es nicht mehr gibt, die aber als Blogseite noch existieren. Die Weiterleitung nur mit [L] hat auch nur ohne Permalinks funktioniert, mit Permalinks hatte ich auch den 404-Fehler. Die Lösung war in meinem Fall dann das zusätzliche [R=301].
Ich habe vorhin ein Update gemacht und dann die Plugins und die Einstellungen gesucht ... und dann oben rechts gefunden. :mrgreen: Na ja, und wenn du einen Beitrag schreiben willst, dann nervt es, dass man runterscrollen muss, um die Kategorien usw auszuwählen. Aber das wird sich noch ändern.
Ich? Nö. Ich weiß ja, wozu ich MySQL brauche. :mrgreen:
Na ja, man kann die 2.4 ja auch als SVN bekommen. Ich setze sie sogar produktiv im echten Blog ein. ;) Auf der Front merkt man nichts davon (K2-Thema*), aber unter der Haube hat sich einiges verändert. Der Admin-Bereich ist freundlicher und übersichtlicher. Das Tags-Management muss noch verbessert werden, es ist aber immerhin schon benutzerfreundlicher als bei 2.3.
* btw, wer K2 (aktuell RC3) und WP 2.4 nutzt, der sollte die K2-eigene Sidebar abschalten, sonst gibt's im Tellerrand eine Fehlermeldung bzgl widgets.
also zwischen erstemHochkoma und dem Doppelpunkt war ein Abstand,
Das muss dir dann aber passiert sein, Monika. Bitte nicht böse sein und bitte nicht falsch verstehen, aber die "functions.php" wird vom Import/Export überhaupt nicht tangiert. Ich habe diverse WordPress-Versionen (beginnend bei 2.0.x) getestet (aktuell verwende ich WP 2.4 SVN), und ich habe das Smilies-Array mit ein paar zusätzlichen Bildchen erweitert. Und es war immer korrekt. Es gab keine Abstände zwischen Hochkomma und dem Code für eine Grafik.
Der einzige Unterschied zu früheren WordPress-Versionen besteht hier
- $wp_smiliessearch[] = '/(\s|^)' . preg_quote( $smiley, '/' ) . '(\s|$)/';
+ $wp_smiliessearch[] = '/(\s|^)' . preg_quote( $smiley, '/' ) . '/';Das ist ein Auszug aus meiner Patchdatei, mit der ich die "functions.php" automatisiert ändere. Die erste Zeile ist das Original und bedeutet, dass Smilies nur dann berücksichtigt werden, wenn ihnen ein Leerzeichen oder das Textende folgt. Dadurch waren meine Smilies nie zu sehen, wenn sie vor einem Komma oder Punkt o.ä. standen (ich lege halt Wert auf korrekte Interpunktion:mrgreen:).
Mein Patch schmeißt diese Zeile raus und ersetzt sie durch die zweite, so dass die Smilies dann wieder wie gewohnt zu sehen sind.