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 erstellenWeil die Themes und normal auch das Backend nun mal nur korrekte locale Bezeichner erwarten.
Benenne einfach die Datei in de_DE.mo um und trag in der wp-config.php wie gehabt das ein:
define ('WPLANG', 'de_DE');Dann versteht auch dein Theme wieder korrekt deutsch und dein Backend sietzt dich :-)
Alles anzeigenVersion 1.5.1 ist installiert.
ABER:
"Pluginverwaltung Plugins vergrößern und erweitern den Funktionsumfang von WordPress. Sobald ein Plugin installiert ist, können Sie es auf dieser Seite aktivieren oder auch wieder deaktivieren."
Und mehr ist auf der Plugin-Seite nicht mehr zu sehen ...
Watt nuu!?
:-)
Das ist mir gänzlich neu und noch nirgends aufgetreten. Das kann ich aber so remote nicht nachstellen. Es würde bedeuten, das es bereits zum Crash kommt, wenn die Plugins enumeriert werden sollen, also bereits eine Core Funktion von WP nicht will.
Zeigt er die Pluginseite an, wenn du "codestyling-localization" deaktivierst (Ordner löschst) ?
Könntest du die Liste der aktiven Plugins mal aufschreiben (von mir aus auch PN) damit ich evtl. auftretende Inkompatibilitäten unter verschieden Plugins testen kann ?
Es gab mal einen Fehler, dass eine globale Variable nicht korrekt benutzt wurde. Der von dir geschilderte Fehler ist bei mir nur aufgetreten, wenn etwas mit der Syntax der *.php Datei selbst nicht stimmte.
Könntest du prüfen, ob das mit der aktuellen Version: WordPress › Codestyling Localization « WordPress Plugins
immer noch auftritt ?
Und falls du die Ursprungsversion schon benutzt hattest, der Ordner hat sich geändert: /plugins/csp-po-edit ist nicht länger gültig, seit dem Bereitstellen über wordpress.org ist der korrekt Pfad (hat codex team festgelegt): /plugins/codestyling-localization
Welche Version des Plugins verwendest du ?
Dies könnte u.U. bei PHP4 passieren und ist erst ab v1.3 möglich.
Oder bei WordPress Versionen < 2.5
Wie wäre es, jeder deiner Seiten ein Cookie zu verpassen. Wenn also der Download Link aus deiner Seite heraus angeklickt wird, bekommst du deinen Cookie auch wieder (sofern der User nicht seine Cookies aus hat).
Fremde Seiten, die direkt in ihrem HTML verlinken, können dir deinen Cookie nicht liefern.
Es ist allerdings ein Katz-und-Maus-Spiel, denn wer deinen Download haben will, schafft das auch irgendwie. Wenn du es wirklich 100% sicherstellen willst, dann bleibt nur die Captcha Variante (solange diese Dinger noch nicht alle geknackt sind).
Alles anzeigenwenn man javascript im browser deaktiviert, funktioniert es.
Das ist jdoch keine entgültige lösung für mich :cry:
Vielleicht ist folgende info auch noch interessant:
Auf dem Button, wo normalerweise nur 'Artikelvorschau' steht, erscheint: [size=12][COLOR=#264761]"tabindex="4">Artikelvorschau[/COLOR][/SIZE]
Wenn man solche Beschriftungen bekommt, hat mit Sicherheit ein Plugin seine Finger im Spiel. Der Quelltext der Edit Seite ist nicht mehr valide und ein Plugin hat vermutlich fehlerhaften Code, Script oder CSS eingefügt.
Dies führt dazu, das Reste des normalen HTML Codes plötzlich mit auf der Beschriftung auftauchen.
In diesem Fall empfehle ich die Deaktivierung aller Plugins und die schrittweise Aktivierung mit der Prüfung, ob nach Aktivierung des jeweiligen Plugins noch Speichern geht. Und diesem Vorgang solange wiederholen, bis du das Plugin gefunden hast, das dafür zuständig ist.
Sollte aber nach kompletter Deaktivierung aller Plugins ebenfalls kein Speichern möglich sein, dann ist was mit deinem WP upload schief gegangen und du solltest WP nochmal per FTP Programm im binär-mode hochladen.
Da es mir keine Ruhe gelassen hat, eine für PHP4 und PHP5 verträgliche Lösung zu haben, bin ich nochmal abgetaucht in die Tiefen der MagpieRSS Feed-Verwaltung. Herausgekommen ist ein Patch, der nun gleichermaßen für PHP4 und PHP5 sauber funktioniert: Code Styling Project » WordPress Dashboard Feeds mit fehlerhaften Umlauten
Die in vorherigen Posts genannte Lösung für PHP5 ist somit hinfällig, denn es wird bereits an der "Wurzel des Übels" operiert :-)
Deine Startseite bekommt schon 3 breite Werbeblöcke durch die Artikel rein.
2 weitere breite Blöcke werden schon nicht mehr geliefert (nächsten 2 Post!) und dann kommt erst die Sidebar.
Nimm mal Firefox, geht auf Ansicht -> Webseiten-Stil -> kein Stil dann siehst du die leeren Adsence Boxen.
Wenn du pro Post einen Adsence Block auf der Hauptseite anforderst, wird das Google bestimmt nicht zulassen (glaube 3 pro Seite ?)
Du bekommst für das Google Script (gekürzt wegen der Daten):
http://pagead2.googlesyndication.com/pagead/ads?client=......einen Antwort folgender Art
400 Bad Request HTTP/1.0 HTTP/1.1 WebDAV Die Anfrage-Nachricht war fehlerhaft aufgebaut.
Deshalb siehst du auch kein Adsence. Irgednwas stimmt an den Parametern nicht, die verschickt werden.
ich nehme an, ich muss den "show favicon befehl" auch noch an weiteren stellen anbringen?
Nein, nur absolute angeben, denn das hier:
<link rel="shortcut icon" href="fav23.ico" type="image/x-icon" />reicht nicht, denn auf Unterseiten sucht dann der Browser das icon relativ zur URL. Deshalb:
<link rel="shortcut icon" href="[B]http://www.onefourtyfive.de/[/B]fav23.ico" type="image/x-icon" />Das ist schon seit 2.5.1 als Bug bekannt und scheint wieder neu aufgetaucht zu sein: #7027 (Admin removed from authors list and logged in as author) - WordPress Trac - Trac
Die im Moment mögliche Umgehung ist:
Zumindest ist das die im Bug-Trac derzeit immer noch gültige Umgehung.
Der geschlossen geglaubte Bug wurde wieder geöffnet.
Das funktionert. :) Allerdings fragst du sicherlich nach der Seite edit.php ab, oder? Deine Admin-Seite ist unter edit.php?page=codestyling-localization/codestyling-localization.php erreichbar, und ich rufe das Thickbox-Zeug auf der edit.php-Seite auf, daher kommen sie sich ins Gehege, vermute ich, da beide auf der edit.php fußen.
Ist ein Unfall. Ich habe zwar für >= 2.6 alles korrekt gehabt, als ich aber auf 2.5 Kompatiblilität gegangen bin, hab ich wegen der dort fehlenden wp_enqueue_style Funktion, immer in den Admin head integriert. Da ich dort auch noch einen fehlerhaften Versionstest hatte, kommt das zustande.
Im Laufe des Tages wird ein eine 1.21 geben, die dann bereits Italienisch zusätzlich enthält. Gab schon Rückmeldungen mit Bereitstellungsangebot.
Was mir aufgefallen ist: Wenn dein Plugin aktiviert ist, zerhaut es ein wenig die Standard-Thickbox von WP. Ich lade mit wp_enqueue_script und *_style z.B. die Original-Thickbox-Dateien von WP in den Header.
Da deine CSS-Deklarationen nach denen der thickbox.css geschrieben werden, werden sie überschrieben mit z.B.
CSS#TB_ajaxContent { background-color: #EAF3FA !important; width: auto !important; overflow: hidden !important; } #TB_ajaxContent.TB_modal { padding: 0px; }von dir. Daher hat die Standardthickbox kein padding mehr und einen anderen Hintergrund (anstatt Weiß). :) Was dann leider so aussieht:
Normal sollte das CSS nur geladen werden, wenn man auf den 2 Seiten des Plugins ist. Das schau ich mir umgehend an, denn es ist natürlich nicht beabsichtigt, auf anderen Admin Seiten das CSS zu laden :oops:
Seit heute morgen steht die neue Version 1.2 über WordPress › WordPress Plugins zur Verfügung.
[COLOR=Red]Wichtig:[/COLOR] Für alle, die schon eine Vorgängerversion einsetzen (< 1.2), hat sich auf Grund der Bereitstellung über wordpress.org der Ordnername ändern müssen. Bitte die älteren Versionen deaktivieren, den Ordner csp-po-edit entfernen und die neue Version einspielen. Ab v1.2 kann man dann, wie von anderen Plugins gewohnt, die automatische Aktualisierung nutzen.
Runterladen, installieren, ist in einer halben Stunde erledigt.
Alle Passwörter und Login IDs wurden auf einen bei der Installation mitgelieferten Wert gesetzt, somit kann jedes Profil und jeder Bereich eingesehen werden, per Browser, auf der Original Foren Software.
Unterm Strich kann also jeder die Datenbank mit der Forensoftware bei sich installieren und einsehen. Übrigens meines Wissens das erstemal überhaupt, das ist eine so neue Qualität.
Schau doch einfach noch mal auf den Link in meinem ersten Beitrag dieses Threads.
Dort findest du Links zum Download und Nutzungshinweise, ganz hilfreich sind die Kommentare, die solltest du Zuerstlesen, vorm Installieren.
Dies hier ist der zweifelhafte Abschnitt mit der Aufforderung am Ende.
Und aus Heise:
Katharina König vom Jenaer Aktionsbündnis gegen Rechts räumte ein, dass die Antifaschisten die [COLOR=Red]Datenbanken zwar auf illegalem Weg erworben[/COLOR] hätten. Sie sei sich aber sicher, "dass auch die Polizei ihre Schlüsse daraus ziehen wird".
Verbreitung von illegal Erworbenen und Aufforderung zur Nutzung ist ebenfalls strafbar.
Ich hab mich bis jetzt zu diesem Thema zurückgehalten, aber nun denke ich ernsthaft darüber nach, diesen ganzen Thread sperren zu lassen. Ich werde mich jetzt mit der Rechtsabteilung unserer Firma beraten, ob das, was hier von u.a. Gersprenz zum Ausdruck gebracht wurde (speziell letzter Post), einem Aufruf zur Beteiligung an einer Straftat gleichkommt.
Hacken ist ein Stafttatbestand, der Zweck heiligt nicht die Mittel. Diese gehackten Daten nun auch noch wie Hehlerware anzubieten und aufzufordern, dies zu installieren, ist rechtlich mehr als nur fragwürdig.
Und es erweckt auch den Anschein, dass dieser Thread dazu missbraucht wird, Links auf Daten zu verbreiten, die über dieses Forum dann von Suchmaschinen bestens zu finden sind.
Ich weiss, das dieses Thema nicht mit "Vogel Strauss" Manier behandelt werden soll, aber dann bitte in einen rechtlich einwandfreien Umfeld. Das scheint mir nun nicht länger gegeben. Ich unterstütze keine Staftaten oder Aufforderungen dazu, deshalb werde ich jetzt prüfen (lassen), wie rechstkonform das hier ist.
Die von WP in der DB abgelegten rewrite_rules sind aufsteigend, das heißt vom ältesten zum jüngsten Artikel hin. Alle Einträge werden per Regular Expression getestet, ob es sich bei der Url (slug) um einen Treffer handelt.
Da dein neuer slug hinten liegt, aber im alten slug komplett vorkommt, bricht die Suche bereits dort ab und liefert die alte Seite statt der neuen.
Ein /bachata-com-2 würde er anstandslos finden. Man sollte bei den slugs drauf achten, das sie keine exakt gleichen Anfangsstücke haben, sonst provoziert man dieses Problem.
PS. Vielen Dank, dies hier [FONT=monospace]http://www.wordpress261.test funktioniert! Aber mod_rewrite geht immer noch nict.. Woran könnte das liegen? Danke![/FONT]
Im Verzeichnis xampp/apache/conf/ gibt es eine Datei httpd.conf in der du u.U. mod_rewrite einschalten musst. Suche das hier:
#LoadModule rewrite_module modules/mod_rewrite.soFalls die Raute davor ist, bitte rausnehmen (ist das Kommentarzeichen), speichern und den Apache neu starten. Dann sollte es funktionieren.
Hmm, da bin ich momentan ein wenig ratlos, denn die sollte es dort geben.
Allerdings setze ich kein Vista ein und kann das nicht mal eben schnell prüfen.
Ich werd mir mal einen Vista Rechner im Laufe des Tages anschauen und werde dann hoffentlich wissen, wo MS die nun wieder versteckt hat :)
Ergänzung: Google hilft: Vista Hosts Datei editieren - Windows Vista
Wie wäre es mit einem Link zum Problemkind ?
Man muss sich das schon mal im Browser anschauen können, um zu helfen.