Beiträge von codestyling

Das kommt auf den Provider an. Bei 1und1 zum Beispiel kann man das selbst per .htaccess umstellen, hatte ich schon in mehreren Threads hier gepostet.
Kaputt gehen kann nichts, nur evtl. zu alte Plugins, die nicht <?php sondern die abgeschaffte Kurzform <? benutzen, gehen dann nicht mehr. Sollte aber nicht auftreten.
Da du eine Sicherung hast, kann nichts wirklich schief gehen, denn die Daten in der Db sind davon nicht betroffen.

Dein Provider oder eine Angabe in einer der .htaccess Dateien verhindern, das eine URL zu Redirektion angeben werden kann.
das geht nicht:

http://www.isvc09.no/wp-login.php?redirect_to=http://www.isvc09.no/wp-admin/edit.php

aber dafür das hier:

http://www.isvc09.no/wp-login.php?redirect_to=www.isvc09.no/wp-admin/edit.php

Irgend etwas sorgt dafür, das nur 1 mal http:// in der URI vorkommen kann. Wenn das mehrmals erscheint, dann bekommst du die Seite des Providers. Kannst du die .htaccess im Grundpfad und im wp-admin Pfad checken, ob die so etwas verhindern ? Wenn nicht, hilft nur den Provider fragen.

Auch deine angegebene Seite erzeugt 404er, weil korrupter HTML Code erzeugt wird:

<a href="http://www.mein.meerblickzimmer.de/category/norwegen/feed" class="rss2">[B]<img src="http://www.mein.meerblickzimmer.de/wp-content/themes/meerblickzimmer_2.0/ima />[/B]Norwegen</a><br />

Hast du alle Dateien korrekt geupdated mit WP 2.6.x (also alles ausser deiner wp-config.php und dem Plugin/Theme Ordner) ?

Das Sinnvollste ist eine Umstellung auf PHP5 denn: heise Security - 04.01.08 - Support für PHP 4 eingestellt

Zitat

Die weitere Entwicklungsarbeit und der Support für PHP 4 wurde zum 31. Dezember 2007 eingestellt, Version 4.4.8 soll das letzte "normale" Release sein. Sofern es notwendig sei, wolle man allenfalls bis zum 8. August 2008 noch Security Releases herausgeben.

Also alle Termine bereits überschritten!

Zusatz: Es gibt jetzt eine letzte Release PHP 4.4.9 seit 07.08.2008, die definitiv die letzte Security/Bugfix Version ist: PHP: News Archive - 2008

Unter anderem ist darin auch der leidige all-inkl.com Bug mit den Sprachdateien durch globale Umschaltbarkeit der mb_str Funktionen behoben. Nur wann und ob die Provider das noch einspielen, who knows ...

Es gäbe auch noch eine andere Lösung, die in PHP4 funktioniert, aber bei "Gemischtwarenladen" (sprich deutsch/englisch gemischt und Sonderzeichen in englisch wie ´) dann passiert das:

WordPress 2.6.1 ist jetzt in der DE-Edition verfügbar. Bei der Version 2.6.1 handelt es sich um ein Servicerealease ohne Sicherheitsaspekt. So schreibt auch Ryan im WordPress Blog: If [B]youâre[/B] happy with 2.6, however, keep on using it. You need not upgrade to 2.6.1 if 2.6 is getting the job done. Was bedeutet, dass man nicht auf 2.6.1 upgraden [...]

Dann stimmen zwar die deutschen Umlaute aber die puren Zeichen im englischen Zusatz werden zerlegt.

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.