Hallo Auge,

vielen Dank für Deine Antwort.

Im ersten Schritt habe ich zwei von den 18 im html-Validator beanstandeten Fehlern behoben.

Es handelte sich dabei um ein unvollständiges div-Tag.

Dieses habe ich aus der template.html entfernt und siehe da:

das Hintergrundbild wird wieder angezeigt!

Die weiteren Fehler knöpfe ich mir jetzt vor so daß ich nicht nur valides CSS sondern auch validen (x)html-Quelltext habe.

Internette Grüsse

Raul

» Hallo,

»

» mit meinem kleinen Forum, das jetzt schon mehrere Jahre nahezu problemlos funktioniert, habe ich inzwischen ein kleines Problem:

»

» Das Hintergrundbild (elkb.jpg), das ich im Stylesheet hinterlegt habe wird mir von den meisten Browsern (im Zuge der Updates) nicht mehr angezeigt.

»

» <a href="http://www.480er.de/forum/forum.php">www.480er.de/forum/forum.php</a>

Ich sehe das Hintergrundbild (der hellblaue Elch) unter Linux Ubuntu 10.04.3 mit Firefox 3.6.24 und im Opera 11.60 im Kopfbereich, im Firefox im Hauptbereich, nicht aber im Opera sowie in beiden Browsern nicht im Seitenfuß.

Genau so wie ich es im Firefox sehe, finde ich auch die CSS-Definitionen über FireBug. Allerdings findet sich diverse Fehler im HTML-Quelltext. Da wären invalide Elemente (z.B. <class>) oder auch in Zeile 29 des Quelltextes ein <div id, welches da weder hingehört noch vollständig ist, das bei unterschiedlichen Browsern unterschiedliche Fehlerbehandlungen und Darstellungen auslöst.

» Das zugehörige Stylesheet (style.css) ist in dem gleichen Ordner und dieses habe ich schon durch den W3C-Validator gejagt, keine Fehler.

Ohne den HTML-Quelltext ist der CSS-Quelltext quasi nichts.

» Wer hat eine Idee wie die farbigen Balken wieder verschwinden?

Prüfe und korrigiere den HTML-Quelltext. Falls dann noch Fehler in der Darstellung zu finden sind, sehen wir weiter.

Tschö, Auge

Hallo,

mit meinem kleinen Forum, das jetzt schon mehrere Jahre nahezu problemlos funktioniert, habe ich inzwischen ein kleines Problem:

Das Hintergrundbild (elkb.jpg), das ich im Stylesheet hinterlegt habe wird mir von den meisten Browsern (im Zuge der Updates) nicht mehr angezeigt.

<a href="http://www.480er.de/forum/forum.php">www.480er.de/forum/forum.php</a>

Das zugehörige Stylesheet (style.css) ist in dem gleichen Ordner und dieses habe ich schon durch den W3C-Validator gejagt, keine Fehler.

Browser unter MS Windows XP Prof. bei denen es angezeigt wird:

- Firefox 3.24

- Safari 5.01

- IE 8

Ubuntu/Linux:

Firefox 3.25 und Epiphany 2.30.2

Unter Opera ging es unter MS und Linux noch bis zur Version 11.5.

Wer hat eine Idee wie die farbigen Balken wieder verschwinden?

Internette Grüße

Raul

Hallo

» » Ging die Übertragung und teilweise auch Korrektur bei Einstellungen, Kategorien, Smilies und Bannlisten leicht von der Hand, war sie bei den vorhandenen Benutzerdaten und Postings recht umständlich. Der Import lief über phpMyAdmin, wo die zulässige Größe der Importdateien je nach Hoster sehr unterschiedlich sein kann. Deshalb mussten die DB-Dumps zigfach zerteilt werden. Bei einer vierstelligen Anzahl von Nutzern und Postings artet das in einer stundenlangen, langweiligen Fleißarbeit aus. Stunden später ist der Datenbestand auf dem Stand des alten Servers.

»

»

» Ich habe einen Bestand mit ca 650 Usern und ca 100.000 Postings problemlos

» mit mysqldumper transferieren können.

» Quelle und Ziel sind beides aktuelle mlf2.

» Da mysqldumper die Datenbank in gezippte Pakete eintütet und per ftp

» oder Mail verschickt ne recht elegante Lösung.

» Es müsste laut Konfig sogar eine Art Cronjob möglich sein, hab ich aber noch

» nicht in Betrieb bekommen.

Danke für den Tip. Die Idee, die Aufgabe wegen der Skriptlaufzeiten zu teilen, ist nicht neu, aber warum soll man das Rad neu erfinden, statt eine funktionierende Lösung zu benutzen.

Man beachte: MySQLDumper ist sogar relevant. ;-)

[edit]Kann mann in dem Skript auch die Entfernung bestimmter Zeichen (hier der Backslash) oder die Umwandlung zwischen verschiedenen Zeichenkodierungen (hier ISO-8859-1 zu UTF-8) konfigurieren?[/edit]

Tschö, Auge

Hallo

» » Wenn hier dennoch jemand mit einer Idee bezüglich IPv6 daherkommt, immer heraus damit.

»

» Vielleicht hilft dir das weiter:

» http://www.developers-guide.net/forums/5874,mysql-speichern-einer-ip-adresse#post53774

Danke für den Link. Eine Lösung mit dem Feldtyp BINARY habe ich auch schon gefunden, damals aber nicht in Gänze durchblickt. :-)

Ich werde mir das nächstens in Ruhe durchlesen und ein wenig testen. In Ermangelung in freier Wildbahn vorkommender IPv6-Adressen erstmal mit Beispielen in einem Testskript, bei Erfolg auch hier auf meinem Server.

Tschö, Auge

» Wenn hier dennoch jemand mit einer Idee bezüglich IPv6 daherkommt, immer heraus damit.

Vielleicht hilft dir das weiter:

http://www.developers-guide.net/forums/5874,mysql-speichern-einer-ip-adresse#post53774

Wima

» Ich habe einen Bestand mit ca 650 Usern und ca 100.000 Postings problemlos

» mit mysqldumper transferieren können.

Ich kann mysqldumper ebenfalls empfehlen. Verwende ich seit Jahren und habe damit schon einige Serverumzüge bewältigt (Forum mit 300 Benutzern und ca. 200.000 Beiträgen sowie ein Wiki mit 200MB Datenbank).

Wima

Hi,

» Ging die Übertragung und teilweise auch Korrektur bei Einstellungen, Kategorien, Smilies und Bannlisten leicht von der Hand, war sie bei den vorhandenen Benutzerdaten und Postings recht umständlich. Der Import lief über phpMyAdmin, wo die zulässige Größe der Importdateien je nach Hoster sehr unterschiedlich sein kann. Deshalb mussten die DB-Dumps zigfach zerteilt werden. Bei einer vierstelligen Anzahl von Nutzern und Postings artet das in einer stundenlangen, langweiligen Fleißarbeit aus. Stunden später ist der Datenbestand auf dem Stand des alten Servers.

Ich habe einen Bestand mit ca 650 Usern und ca 100.000 Postings problemlos

mit mysqldumper transferieren können.

Quelle und Ziel sind beides aktuelle mlf2.

Da mysqldumper die Datenbank in gezippte Pakete eintütet und per ftp

oder Mail verschickt ne recht elegante Lösung.

Es müsste laut Konfig sogar eine Art Cronjob möglich sein, hab ich aber noch

nicht in Betrieb bekommen.

Aktuell habe ich auf der Testplattform einen Mini-Editor integriert, mit dem man die Menuzeile einfacher anpassen kann als im Quellcode.

Gruß

Andi

Hallo

Zur Erklärung des alleinstehenden "Bla".

Die Speicherung der IP-Adressen bei der Registrierung und beim Posten hat mir immer wieder Kopfzerbrechen bereitet. Besonders die Möglichkeit, dass jemand mit einer IPv6 daherkommt, wird zukünftig immer größer, in mlf1 aber noch nicht berücksichtigt.

Bisher wird die IP(v4) in der Datenbank als Varchar hinterlegt. Eine IPv4 ist 15 Stellen lang, eine IPv6 hat meinen Rechnerchen nach maximal 39 Stellen.

Für die Speicherung von IPv4 gibt es eine bessere Möglichkeit als Varchar, die mit MySQL-Bordmitteln funktioniert[1]. Mit den MySQL-Funktionen INET_ATON und INET_NTOA lassen sich IPs zur Speicherung in Integerzahlen um- und zurückwandeln. Die PHP-Entsprechungen lauten ip2long() und long2ip(). Gespeichert wird die IP in einem UNSIGNED INT(10)-Feld, was zu einer besseren Durchsuchbarkeit und einem von 15 auf 4 Byte pro Adresse sinkenden Speicherbedarf führt.

Das Problem der IPv6-Adressen bleibt so allerdings bestehen. Soweit ich bisher ermitteln konnte, gibt es dafür einerseits keine nativen Funktionen, andererseits muss die IP in der Datenbank wegen des großen Wertebereichs (128 Bit) in zwei Feldern gespeichert werden, die zu einem gemeinsamen Index zusammengefasst werden.

Die Aufgabe, beide Systeme voneinander zu unterscheiden, aber gleichzeitig gemeinsam zu behandeln, ist für mich momentan noch ein Buch mit sieben Siegeln. Da das mMn aber nicht drängelt, weil IPv6 in der freien Wildbahn zu begegnen momentan unwahrscheinlich ist, konzentriere ich mich erstmal auf den Umbau bezüglich IPv4.

Wenn hier dennoch jemand mit einer Idee bezüglich IPv6 daherkommt, immer heraus damit.

[1] Blogeintrag 1, Blogeintrag 2, MySQL5.1-Doku

Tschö, Auge

Bla

Hallo Alfie

» Ja ist sicher besser (nach der letzten Spezifikation ohnehin verpflichtend).

Auch wenn das stimmt, bist du mit dem Linkziel falsch in den Channel-Abschnitt abgebogen, obwohl das Problem in den Items bestand. Im Channel-Abschnitt war <description> schon da. :-)

Tschö, Auge

Hallo Auge

» Für die aus den Postings stammenden lokalen Pfade lasse ich mir noch etwas einfallen. Bei Links und Bilderpfaden muss irgendwie geprüft werden, ob sie absolut oder relativ sind und im letzteren Fall muss eine absolute URL erzeugt werden.

Habe ich auch schon versucht – aber aus zeitknappheit verschoben. ;-)

» Zudem schlug htmlspecialchars im Feed doppelt zu. Einerseits wurde die Funktion explizit genutzt, andererseits implizit über die BB-Code-Parserklasse genutzt.

Aha!

Hallo

So, ich habe den Feed valide gemacht. Es bleibt eine Empfehlung übrig. Für die aus den Postings stammenden lokalen Pfade lasse ich mir noch etwas einfallen. Bei Links und Bilderpfaden muss irgendwie geprüft werden, ob sie absolut oder relativ sind und im letzteren Fall muss eine absolute URL erzeugt werden.

Zudem schlug htmlspecialchars im Feed doppelt zu. Einerseits wurde die Funktion explizit genutzt, andererseits implizit über die BB-Code-Parserklasse genutzt.

Die Änderungen sind, wie bei fertigen Sachen üblich, im Repository verfügbar.

» » Was <content:encoded> vs. <description> angeht, sagt die Doku, dass letzteres breiter unterstützt wird. ...

»

» Ja ist sicher besser (nach der letzten Spezifikation ohnehin verpflichtend). Gerade getestet: SM2.5, IE8 passt. Opera formatiert den Feed in hellgrauer Schrift und 2spaltigem Blocksatz (!). Hübsch. Nur werden alle internen Formate eliminiert und zu einer Textwüste. Google Chrome hat witzigerweise keinen Reader an Bord; mit dem Add-In werden bei Verwendung von <content:encoded> nur die Überschriften angezeigt, bei <description> ist alles vorhanden.

» And the winner is… :-D

Aber sowas von ...

Tschö, Auge

Hallo Auge!

» Hmm, wo ist da die Emailadresse? ;-)

»

» Ok, die Doku sagt zu <author> das Gleiche wie du. Was soll aber dort rein, wenn der Poster keine Emailadresse angibt?

Ja ebent! Hama nich', daher der $name, der schon vorher in <author> war – halt eben jetzt in <dc:creator>. Verwendet Alex in der 2er übrigens auch.

» Wieso Atom? Der Feed sollte gegen RSS 2.0 validieren, Atom ist eine Parallelentwicklung. Egal, ich setze mich dann auch mal mit dem RSS-Validator auseinander.

Passt schon. Kann's grad nicht erklären - die Küche ruft.

» Was <content:encoded> vs. <description> angeht, sagt die Doku, dass letzteres breiter unterstützt wird. Zudem sagt die Doku zu <content:encoded> "On items with no summary, the full content should be stored in description.", was mich überlegen lässt, ob ich einfach <description> statt <content:encoded> nutze. Zusammenfassungen für die Einträge gibt es ja nicht.

Ja ist sicher besser (nach der letzten Spezifikation ohnehin verpflichtend). Gerade getestet: SM2.5, IE8 passt. Opera formatiert den Feed in hellgrauer Schrift und 2spaltigem Blocksatz (!). Hübsch. Nur werden alle internen Formate eliminiert und zu einer Textwüste. Google Chrome hat witzigerweise keinen Reader an Bord; mit dem Add-In werden bei Verwendung von <content:encoded> nur die Überschriften angezeigt, bei <description> ist alles vorhanden.

And the winner is… :-D

Hallo Alfie!

» Man(n) lernt nie aus… <author> verlangt entsprechend der Spezifikation (neben optionalem Namen) eine wohlgeformte (musste dieses Wort auch einmal verwenden…) E-Mail Adresse. Die aktuelle Version ist daher nicht valid.

» Abhilfe:

» #43: Header um den Dublin Core Namespace erweitern, also:

» <rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">

» #91: <author>foo</author> => <dc:creator>foo</dc:creator>

Hmm, wo ist da die Emailadresse? ;-)

Ok, die Doku sagt zu <author> das Gleiche wie du. Was soll aber dort rein, wenn der Poster keine Emailadresse angibt?

» Siehe auch hier.

»

» Edit 1: Das da habe ich auch noch dazugebastelt. In allen items braucht's auch noch vor <content:encoded> eine <description> (kann gleichen Inhalt wir <title> haben; analog zum Anfang des Kanals). Bei mir bin ich jetzt bis auf das Kodierungs-Gemecker durch.

Wieso Atom? Der Feed sollte gegen RSS 2.0 validieren, Atom ist eine Parallelentwicklung. Egal, ich setze mich dann auch mal mit dem RSS-Validator auseinander.

» Edit 2: Großartig. Jetzt habe ich einen validen Feed, aber der Inhalt wird mir im SM2.5 nicht mehr ausgegeben. :-(

»

» Edit 3: Aha. Vergiss’ <description>. Soll eine Zusammenfassung von <content:encoded> enthalten. Den Titel zu duplizieren ist daher einerseits sinnfrei und andererseits scheint es eine alte Macke der Moz-Familie zu sein, bei Vorliegen beider Elemente nur die description anzuzeigen.

»

» Edit 4: Header gelöst: Am Ende statt header("Content-Type: text/xml; charset: UTF-8"); => header("Content-Type: application/xml; charset: UTF-8");

Boah, gleich so viel ...

Was <content:encoded> vs. <description> angeht, sagt die Doku, dass letzteres breiter unterstützt wird. Zudem sagt die Doku zu <content:encoded> "On items with no summary, the full content should be stored in description.", was mich überlegen lässt, ob ich einfach <description> statt <content:encoded> nutze. Zusammenfassungen für die Einträge gibt es ja nicht.

Tschö, Auge