Beiträge von codestyling

Das Problem sind deine <dl></dl> innerhalb des <small> bzw <p>!
Hier der Verweis auf SELFHTML: Navigationshilfen / Suche
Laut Spezifikation das das nicht in o.g. Tags vorkommen. Da FF das übergeht, weil sie leer sind, wird der IE das anders behandeln und somit alles nach dem ersten <dl> aus dem <small> <p> rausnehmen, was dazu führt, das die Box bereits so zeitig für den IE endet und die Texte dahinter stehen.
Nimm einfach die <dl> raus, da sie ja sowieso leer sind.

Dann sollte für PHP4 (kann ich leider nicht testen) ein vorangestelltes @ reichen, um die Warnung zu unterdrücken, da es ja offensichtlich keine Bereinigung mehr für PHP4 geben wird :cry:

$description = wp_specialchars( strip_tags([COLOR=Red][B]@[/B][/COLOR]html_entity_decode($item['description'], ENT_QUOTES, get_option('blog_charset'))) );

... hab das mal im Bug-Trac Eintrag mit hinzugefügt als Randnotiz.

Hier die eingereichte Bug-Trac Nummer: #7563 (html_entity_decode at RSS Feed import doesn't respect charset of Blog) - WordPress Trac - Trac

Die fehlerhafte Darstellung der Feed Inhalte im DashBoard und auch in den Widgets geht auf jeweils einen Bug zurück, den die Entwickler übersehen haben. Im nicht deutsch-sprachigen Raum tritt dieser Fehler nicht auf und wird sicher in den Tests in "Übersee" auch nicht registriert worden sein (US hat keine Umlaute).
Es sind 2 Core Dateien betroffen, die man wie folgt reparieren kann (WP2.6.1):

wp-admin/includes/dashboard.php Zeile: 431

$description = wp_specialchars( strip_tags(html_entity_decode($item['description'], ENT_QUOTES[B][COLOR=Red], get_option('blog_charset')[/COLOR][/B])) );

wp-includes/widgets.php Zeilen: 1130 und 1132

if ( isset( $item['description'] ) && is_string( $item['description'] ) )
                $desc = $summary = str_replace(array("\n", "\r"), ' ', attribute_escape(strip_tags(html_entity_decode($item['description'], ENT_QUOTES[COLOR=Red][B], get_option('blog_charset')[/B][/COLOR]))));
            elseif ( isset( $item['summary'] ) && is_string( $item['summary'] ) )
                $desc = $summary = str_replace(array("\n", "\r"), ' ', attribute_escape(strip_tags(html_entity_decode($item['summary'], ENT_QUOTES[COLOR=Red][B], get_option('blog_charset')[/B][/COLOR]))));

Ich werde diesen Bug noch an WP-Trac weiterreichen, hier nur vorab die Bereinigung.

Hintergrund: Bei der Dekodierung der im Feed enthalten Sonderzeichen, wird der optionale Parameter der Funktion html_entity_decode charset nicht gesetzt, weshalb als Standardwert ISO-8859-1 angenommen wird. Allerdings muß sich die Konvertierung nach dem vom Blog vorgegebenen charset richten, was ich als [COLOR=Red]rot markierte[/COLOR] Ergänzungen in den o.g. Codeausschnitten hinzugefügt hab.

Da gibt es erstmal kein Einwände nur ein Hinweis für "vermehrte" Session ID's.
Wenn ein anderes Plugin, aus welchen Gründen auch immer zum Beispiel das hier aufruft:

apply_filter('page_link', $link);

würde deine Erweiterung erneut die Session ID an den Link anhängen! Ein Test, ob eine Session ID schon im Link drin ist, wäre nicht verkehrt und verhindert sich aufschaukelnde URL's durch Filter-Kaskaden, die gern mal z.B. durch multi-lingual Plugins ausgelöst werden.
Und für einen Search Engine Bot, sofern deine Seiten indiziert werden können und der Benutzer eine Google oder Alexa Toolbar aktiv im Browser hat, ist die Session ID mit in der gespiderten URL drin, die die Toolbar überträgt und daraufhin den Bot genauso vorbeischickt. Eine Erkennung dafür wäre ggf. auch nötig.
Wegen Suchmachinen Indizierung samt Session ID finde ich die Verwendungvon Sessions in der URI nicht besonders berauschend, aber das ist Ansichts- und Anwendungssache.

Laufen auch beide Blogs als UTF-8 oder ist eines aus "Altersgründen" im ISO Mode verblieben nach einem Update ?

Hmm, leider ist der entsprechende Anwendungsfall immer noch unklar.
Wenn du Benutzern von WP zwar Admin GUI nicht geben willst, aber sie sich dennoch anmelden müssen, um zu "arbeiten", braucht es Cookies.
Wenn jedoch jeder x-beliebige anonyme User bei dir was machen können soll, trackst du quasi die Bewegung in den Seiten mit. Läuft das Ganze auf ein Seitentracking mit Auswertung hinaus oder kann jeder irgendwas bei deinem Blog "abladen" ohne bekannt zu sein ?

Zitat von taiko1976

Zum weiteren Verständnis: Ich versuche mich gerade an Plugins und habe ein Plugin geschrieben, das nichts anderes macht, als ein Top-Level-Menu in der Administratoransicht von WP anzulegen. Unterhalb diesem Top-Level-Menu werden zwei Sub-Menus erzeugt. Das Problem ist nun, dass ich auf der Seite des Top-Level-Menu's eine Session-Variable setzen ([FONT=Courier New]$_SESSION['TestData'] = "HELLO WORLD";[/FONT]) und deren Wert dann auf den Seiten der Sub-Menus auslesen möchte ([FONT=Courier New]echo "SessionData:".$_SESSION['TestData'];[/FONT]). Eigentlich ja ganz einfach.

... und hier springt der Frosch ins Wasser: Nach dem Seitenwechsel von einem Menü in das nächste gehen mir die Session-Variablen verloren.

Nach deinem Code vom Plugin zu urteilen, willst du die Session per URL dranhängen (use_trans_sid). Was spricht dagegen, cookies/session cookies zu benutzen, wenn du sowieso cookies für das Admin Interface von WP brauchst ?

$duration = 365*24*60*60;
@setcookie('MyCookieName','MyManyCookieVars',time()+$duration,'/');

und dann im Code auswertest über $_COOKIE['MyCookieName'].
Rücksetzen solltest du es ggf. bei einem logoff Filter, falls es nicht stehen bleiben soll.
Ich verstehe aber die Absicht nicht ganz, wozu man überhaupt sessions/cookies benötigt, wenn man vom einem Hauptpunkt einen Unterpunkt aufruft. Kannst du das näher erläutern ?

Zitat von taiko1976

Das Problem liegt eher darin, dass die Session von WordPress bei jedem Aufruf gesäubert wird. Zumindest in der Version 2.6.0.

Das stimmt im Übrigen nicht. WP 2.5.0 und auch WP 2.3.3 (zumindest kenne ich den Code dieser beiden sehr genau) haben das ebenso gehandhabt. Auch in diesen Versionen wurden aus Sicherheitsgründen die angebenen Werte und globals gelöscht, denn die Einbrüche in Server mit register_globals = on sind nun mal ein ernstzunehmendes Problem.
Die Verwendung von session_start() beginnt eine neue Session oder nimmt eine existierende Session wieder auf, falls diese noch gültig ist. Somit werden alle deine "gemerkten" Session Variablen wieder verfügbar, wenn der session_start() nach der Initialisierung ("Säuberungscode") von WP ausgeführt wird.
Warum man das als 1. Zeile im header.php, direkt in der functions.php des Themes oder eben per Plugin unter Zuhilfenahme des init Hooks macht, hat MarX ja schon erklärt.
PS: Die Jungs von WordPress.org sind nicht mit dem Klammersack gepudert und bauen Sachen ein, die eine Sessionverwaltung unmöglich machen.

Nachtrag wegen Überschneidung der Post: Niemand will dich in die Schublade "kleiner dummer Anfänger" legen. Nur in deinen Eingangsposts bist du direkt auf Code-Ebene eingestiegen und mit Modifikationen am WP Kern. Deshalb hat sich meine Antwort auch daran orientiert und ein wenig Programmiererfahrung vorausgesetzt. Sorry, wenn meine Anwort unter falschen Voraussetzungen erfolgte, ich hab manchmal die Angewohnheit, auf dem Niveau zu antworten, was ich aus der Fragestellung meine, erkannt zu haben. Und ich maße mir auch nicht an, "allmächtige Weissheit" zu besitzen, wenn das falsch rübergekommen ist, tut es mir leid.

Ist völlig überflüssig, denn wie man mit Sessions umgeht kann man hier nachlesen: PHP: session_start - Manual

Ergänzung: ... und session_start() benutzt man im Theme (header.php) oder einem eigenen Plugin im init Hook, jedoch nie vor der Initialisierung von WP !

Zitat von Gersprenz

Ich würde mir übrigens wünschen du zeigst uns Schmalspurprojektlern einfach mal einen anderen, praxisorientierten Lösungsweg zur einleitenden Frage des Threads und dämpfst deine, ich nenne sie mit Verlaub, Freude an arrogantenTotschlagargumenten ("keine vertretbare Lösung" .. "ich weiss wovon ich rede" .. "hab beruflich weltweit Kunden betreut".).

Das hat überhaupt nichts mit Arroganz zu tun sondern mit Erfahrung. Kunden und Benutzer neigen dazu immer mehr und um immer umfangreichere Sachen zu wollen, wenn man anfängt etwas bereitzustellen. Langfristig rächen sich die Flickenlösungen dann, weil der Aufwand alles weitere einzubauen, exponentiell mit dem Flickwerk wächst.
Ich habe derzeit auch keine Patentlösung für WordPress, denn von vorn herein ist WP nicht wirklich darauf ausgerichtet, parallel Sprachen anzubieten. Alles was man dazu gern hätte, gibt es auf DB Ebene nicht von Haus aus. Deshalb sind auch die Ansätze, die es im Netz gibt ein Anfang aber nicht für Otto-Normal-Nutzer machbar.
Ich hab auch nur ausgedrückt, dass es ohne Kenntnisse von PHP und ein paar WP internas nicht ohne weiteres möglich ist, multi-lingual zu arbeiten. Aber es gibt unzählige Benutzer, die eine "zero-config / plug 'n play" Lösung brauchen oder möchtest du ein Hilf-mir Forum bei dir hosten und mit viel Zeitaufwand betreuen, in dem alle diejenigen aufschlagen, die nicht verstehen, wie es gehen soll ?

Zitat von Alphawolf

Also, gibt's da auch schon was von ratiopharm für WordPress Plugins?
Rein technisch sollte dies kein Problem darstellen, da .po-Dateien einfach aufgebaut sind.
Gruß, Oli

Also technisch ist das schon eine Herausforderung, denn das ganze Hin- und Her escapen von geslasheten Texten ist mehr als nur trivial. Soweit ich weiß, gibt es derzeit kein solches Plugin. Deshalb hab ich eines angefangen, was eigentlich letzten Sonntag als Beta released werden sollte. Da es aber noch Probleme mit den korrekten Escapements gibt, die ich diese Woche noch bereinige, wir der Release auf den 24.08.2008 verschoben.
Um einen Vorgeschmack zu bekommen, hier der einführende Artikel mit den aber zum Teil bereits veralteten Screenshots: Code Styling Project » WordPress Sprachdatei Plugin - Machbarkeitsstudie

Zitat von Gersprenz

Hmm, ich hab das Theme meines Links oben lange Zeit genutzt, und war überrascht, wie gut das funktioniert, was du Sülze nennst.

Deine Beispiele mit Österreich und GB-British sind richtig, ja. Aber das ist über einen entsprechenden Fundus von Theme Sprachdateien zu lösen. Wer multilingual anbieten möchte, muss sich mit den Sprachdateien in jedem Fall auseinander setzen.

Und man kann bei Firefox die eigenen Sprachvorlieben genauso gewichten, wie man es lesen möchte. Im Ergebnis erlebe ich dann: Wird die oberste gewünschte Sprache nicht gefunden, dann springe zur zweiten und so fort - bis eine entsprechende Sprachdatei gefunden wurde.

Ich habe dies konkret mit Deutsch, Englisch, Portugiesisch, Spanisch und Italienisch im Betrieb obigen Themes von Avi erlebt. Damit war für meinen Blog Europa mit vergleichsweise geringem Aufwand abgedeckt.

Mach du einfach mal selbst den Test und ändere die Spracheinstellungen deines Browsers (z.B. auf Portugiesisch) und besuch die Demoseiten von Avis Soleil Theme, obs funktioniert.

Glaub mir, ich weiss wovon ich rede. Das ganze Konzept hinter der Lösung geht nur darauf zurück, das man nur die Sprache angibt nicht jedoch das Land. Also muß man alle Sprachdateien, die man verwendet umbenennen in de.mo oder en.mo ... Dies würde ebenso für alle Plugins gelten also statt sitemap-de_DE.mo dann sitemap-de.mo.
Wenn man dann auch noch die Locale umschalten muß, weil man die Komma- oder Tausenderseparatoren sprachkorrekt einsetzen muß, steht man im Regen !
Deutsch hat für Dezimalzahlen "," statt "." und Schweizer haben als Tausender Trenner statt "." dann " ' ". Viele Serversysteme können nur mit den 2stelligen Sprachkode keine Locale umschalten, somit ist das einfach nur schlecht. Es mag für bestimmte Projekte ein Schmalspurlösung sein, es ist aber keine vertretbare und aus Wartungssicht viel zu aufwendige Herangehensweise (Updates von Plugins, Themes, WP Sprachdateien ...)
Deshalb auch meine Einstellung zu dieser Lösung, ich hab viel zu oft mit sprachspezifischen Problemen gekämpft und beruflich weltweit Kunden betreut.

Zitat von Gersprenz

Um überhaupt erstmal die Theme Navigation und allgemeinen Theme Texte in der Landessprache des Besuchers anzuzeigen dieser Tipp:

Code

define ('WPLANG', substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2));

Diese Zeile in die wp-config einbauen.
Mehr Infos dazu hier drüben: Soleil Theme for WordPress :: Avi Alkalay - Abschnitt: "Soleil Localization and Internationalization"

Das Prinzip: Jeder Besucher übermittelt ja die voreingestellte Sprache des eigenen Browsers, wenn er eine Site besucht. Diese wird mit obiger Zeile ausgelesen und die entsprechende Sprachdatei des Wordpress Theme eingespielt. Wenn diese vorhanden ist ...

Das ist Sülze, mit Verlaub!
Wenn ich

• de_DE für Deutschland
• de_AT für Österreich
• en_US für USA
• en_GB für britisch english

haben muß, nutzt ein de oder en gar nix. Außerdem sind die Sprachdateien wegen locale Funktionen ja auch mit Landesangabe. Und im Asiatischen Bereich ist das Land essentiell (Chinesisch != Chinesisch).
Außerdem kann der Browser ein Bevorzugungsmodell als Kennung schicken mit gewichteten Werten, der 1 Wert kann durchaus die am wenigsten gewünschte Sprache sein.
Dazu braucht man schon eine qualifizierte Erkennungsmethode und nicht dies 0815 Lösung, die nicht immer geht. (Denkt an die Suchmachinen Bots, die müssen gar nix schicken und ihr zermüllert euch die Serps.)

Zitat von pisti88

gut, erstmal geklärt, nun hab ich auch noch das problem, daß beim schreiben die Buttonsymbole nicht angezeigt werden. Sowie fett und kursiv und so, die buttoms erscheinen nur ohne Symbol,

Auf deiner 2. angebenenen Domain stimmt was mit deinem include Pfad nicht:

http://bleibejung.de/wp-includes/js/jquery/jquery.dimensions.js?ver=2.6.1

wird mit 404 NOT found in der Hauptseite ausgeliefert. Hast du den kompletten Pfad wp-includes auch neu aufgespielt ? Wenn also schon 1 Javascript nicht da ist, der Pfad nicht stimmt oder andere kaputt sind (Übertragungsfehler), dann kann es auch mit dem Editor nix werden.
Prüfe, ob der wp-includes Pfad und alles drunter dem offiziellen Installpaket 1:1 entspricht.

Der in WP2.6.1 bereitgestellte Fix bereinigt das Problem auf der Basis meines eingereichten Patches. Dies löst aber, soweit ich Rückmeldungen dazu bekommen hab, die Problematik bei all-inlk.com nicht.
Offensichtlich sind dort die Server/PHP in einer Weise konfiguriert, die diesen Fehler auch auf andere Art provoziert.
Dies ist nicht ein Problem von WordPress selbst sondern ein konfiguratives Problem des Hosters.

Zitat von _Paul_

Bei mir kommt dieser Fehler übrigens auch mit der englischen Wordpress-Version. Habe keinerlei Sprachdateien installiert.

Hat jemand eine Idee, woran das liegen könnte?

Wenn du keine Sprachdatei von WordPress benutzt, heißt das erstmal nur, dass es nicht mit der de_DE.mo von WP zusammenhängt. Solange aber in der wp-config.php noch eine Sprache unter WPLANG angegeben ist, werden ggf. Sprachdateien von Plugins geladen, die dieser Sprache entsprechen.
Anders kann man ohne Sprachdateien den Fehler nicht produzieren, denn wenn WP komplett auf englisch läuft (WPLANG ist "" oder "en_US") dann werden keinerlei Sprachdateien verwendet.

Ich hab aber auch schon Rückmeldungen von Usern bekommen, die Gengo einsetzen. Dieses Plugin scheint die "Macht" zu haben, diese Art der Fehler ebenfalls zu provozieren! Leider hatte ich noch keine Zeit, dieses zu testen.

Zitat von Tuxman

Es befinden sich noch Dateien im Ordner, ja; die kann ich aber ebenfalls nicht auf 777 setzen (derzeit 644):

Hm!

Ich geh davon aus, dass du bei bplaced.net hostest. Die haben dort ein Forum, das sich u.a. auch mit diesem Problem beschäftigt: .. bplaced.net - Thema anzeigen - Ordner wird nicht Gelöscht
Die Server sind so eingerichtet, das der FTP Benutzer keine Dateien löschen kann, die ein PHP Script angelegt hat. Nur ein PHP Script kann das wieder entfernen. (Ordner ebenfalls).

Das ist auch abhängig vom Provider. Wenn die Config feststellt, das sie keine Schreibrechte in dem Ordner hat, wird keine komprimierte Version erstellt sondern immer der unkomprimierte Editor ausgeliefert. Dann erzeugt WP in der Tat keine solche Datei.
Da du keinen Link angeben hast und auch den Provider nicht genannt hast, kann ich das derzeit nur annehmen, weil ich es von anderen Nutzern kenne.

Da versucht jemand ein russisches Rootshell PHP nachzuladen und das Plugin zu veranlassen, das Script auszuführen!

http://gujewear.com/bemarket/goods/qmono/Q-MoNoR6.txt

Dies ist laut Logfile das RootShell Script und immer noch downloadbar. Du solltest deinen Webspace sorgfältig ansehen (angefangen mit dem Plugin), ob dort Dateien liegen, die da nicht hingehören.

Und für diejenigen, die wissen wollen, wie schlimm das wirklich ist, hier ein Video: http://www.milw0rm.com/video/watch.php?id=29

Fragen:

1. Über wie viel Threads willst du diese Thema noch ziehen ?
2. Wieso widersprichst du dir dabei selbst ?

Einerseits schreibst du, du willst fremde Seiten einblenden und bewerten lassen, andererseits redest du von eigenen Seiten, die da hin sollen.
Ein Bewertungssystem macht nur Sinn, wenn du ein stattliche Anzahl eigener Domains bewerten lassen willst. Das Ablehnen von Verlinkungen der präsentierten "fremden" Inhalte und der Wunsch nach "nahtloser" Integration in deinen URL Namensraum klingt wie, ich schon sagte, zweifelhaft. Da du nichts zum Konzept dahinter sagst, kann man daraus auch nicht schlau werden. Wenn es sich aber um nicht von dir erstellte Domains handelt, dann wäre ein Integration mit Patchen der Linkziele eine nicht unterstützenswerte Aneignung von fremder Leistung.