Weiterleitung nach "als gelesen markieren"...

Wäre es nciht sinnvoll, das board-script dahingehend zu ändern, daß man, nachdem man einen Bereich als gelesen markiert hat, auf die oberste Ebene des boards weitergeleitet wird? Den Bereich muß man ja nicht nochmal sehen, man war ja schon da. Spart Zeit, Klicks und Nerven...

Hallo,

ich denke, das sind Sachen, die bei vBulletin einfach "so sind". Da hat man nicht viel Handhabe, es sein denn, man hat Lust sich den ganzen Code zu verunstalten (wer hat denn schon die Zeit, so etwas ausgiebig zu testen???). Es wäre sicher mit einem zu großen Aufwand verbunden so etwas reinzucoden, da so etwas wahrscheinlich nicht mit den vBulletin-Templates machbar ist.

Tipp: Den Vorschlag direkt an den Hersteller (vbulletin.com) senden!

Grüße, rikman

Hmmtja, ich hab' immer ezboard benutzt. Das war in perl realisiert und daher bin ich recht flott durchgestiegen, was die einzelnen code-Bestandteile anging.
In PHP bin ich nicht ganz so firm, da würde die Suche wohl etwas länger dauern...
Wie dem auch sei, ist mir nur so aufgefallen.

PHP ist da eigentlich nicht so doll anders (ich habe beides sehr gern ). Das Problem ist nicht, den Code mal eben anzupassen, sondern eher, dass bei einem der doch recht regelmäßigen Updates der Software alle Hacks wieder weg wären. Deshalb gibt es ja die Templates, so dass alle Einstellungen durch die verschiedenen Versionen der Software "durchgeschleift" werden. Nur leider kann man auch nicht alles mit den Templates machen...

Vielleicht kann sich Tom ja mal dazu äußern.

Grüße, rikman

Die Loesung heisst CVS und Patches (fuer Aenderungen, die dann wieder weg sind) ... oft kann man, wenn man so eine kleine Aenderung macht, bei einer neuen Version der Software einfach einen Patch einspielen, das funktioniert wunderbar einfach, wenn man auf CVS Basis arbeitet.

Bei obiger Frage waere es so, dass das Template fuer action=mark_read wohl einen <meta refresh> auf (symbolisch ausgedrueckt) http://$site/$program?$parameter macht, wenn man das entsprechend aendert (in dem Sinne das die Forum-ID nicht wieder mitgegeben wird). Ich wuerde fast garantieren, dass ein aus CVS-Management erzeugter Patch von einer solchen Aenderung sich bei einer neuen Version problemlos einspielen laesst.

Kann echt jedem, der eigenen Code schreibt oder bestehenden aendert empfehlen, sich in CVS einzuarbeiten. Das nervt am Anfang ein bisschen, aber macht das Leben mittelfristig echt leichter ("welche Aenderungen habe ich am Code gemacht seit er nicht mehr laeuft?" )

Ausserdem kann man solche lustigen Patches dann auch den Softwareentwicklern schicken, die haben es dann schoen einfach beim Einbauen. Ordentlicher, kommentierter Code ist natuerlich Voraussetzung

Wie war das gleich? "Es gibt zwei Sachen, bei denen man sich mit mir nicht streiten darf: Computer und Freeride" SCNR

Weiß nicht, ob vBulletin mit CVS arbeitet, tendeziell würde ich sagen nein. CVS wird ja eher bei Open Source eingsetzt (ja ja, ich weiß, PHP ist naturgemäß schon "Open Source"), hier handelt es sich ja aber um ein kommerzielles Produkt.

Lasst uns eine eigene Software tippern, die unseren Ansprüchen gerecht wird

Grüße, Marcus

Naja, da waere man nicht vom Hersteller abhaengig .. schickt man ihnen die Patches halt nicht, wenn's kommerziell ist

Aber man kann einfach die ganzen PHP- und HTML-Files vom Hersteller selbst in ein eigenes CVS einchecken, und dann aus den Unterschieden von "alte Version mit Tom's Aenderungen" und "alte Version Vanilla vom Hersteller" fuer "neue Version Vanilla vom Hersteller" Patches generieren, mit denen dann "neue Version mit Tom's Aenderungen" erzeugt werden kann.

Im Detail erklaer ich das aber auch lieber bei nem

Selber schreiben .. tja, da koennte man schon schoene Dinge machen ... mod_perl mit DBI und XML-Templates ... Ideen hab ich da schon (und viele), aber zum coden fehlt mir die Zeit

Hauptproblem ist, dass noch keiner einen fertigen Application Server mit mod_perl mit den notwendigsten Features geschrieben hat (ordentliches Connection Pooling, Session Management, und das ganze Vernuenftig integriert), und das ist echt VIEL Aufwand.

Der Vollstaendigkeit halber: Um Patches zu erzeugen und/oder einzuspielen braucht man kein CVS, sondern nur "diff" und "patch" (was anderes macht CVS auch nicht), aber CVS ist noch ein bisschen netter.

Gregor, ich denke ich muss mal wieder nach HH kommen
Diffs gibt es von vb - cvs ab der nächsten Version...