Benutzername    Passwort    Autologin    
  Passwort vergessen       Registrieren  
beeForum Foren-übersicht » hal9000 » mod support
Neues Thema eröffnen   Neue Antwort erstellen Hervorhebung entfernen


zukünftige Features, v1.3.2
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
boris



Beiträge: 10136

Titel: zukünftige Features, v1.3.2
Verfasst am: Fr, 17 Feb 2006, 10:25
Beitrag
Antworten mit Zitat

Egal, wieviele neue Features eingebaut werden, es bleibt immer noch was zu tun:

  • "paginate" für Userliste: (erledigt)
    ich möchte bei einem extrem großen Forum (also, sagen wir mal, über 10.000 User) nicht wirklich die "permissions"-Liste für die Benutzer aufmachen müssen big grin

  • "paginate" für "UploadPic latest": (erledigt)
    um durch alle Bilder blättern zu können, der Wert "uploadpic_numlatest" könnte dann als Anzahl der Bilder pro Seite verwendet werden

  • "Posted Image Resize" (erledigt)
    basierend auf dem AddOn von Makc666 kann hierbei das gepostete Bild in der Größe geändert (= verkleinert) werden, damit das kleine UploadPic-Fenster nicht gesprengt wird (ein automatischer Resize des Fensters hatte sich ja als nicht wirklich praktikabel erwiesen)

  • Datenbankanbindung für UploadPic:
    bisher gibts noch keine konkrete Planung dafür - die Version wäre dann 2.0, da einmal konvertierte Daten nicht mehr abwärtskompatibel sein werden. Erfordert allerdings einen kompletten Umbau (s.u.).
    Auch muß erst noch überprüft werden, wie die Checks, ob ein Bild benutzt wird, mit der Datenbank in Verbindung gebracht wird, um das Durchlaufen des gesamten Verzeichnisses kommt man nämlich wahrscheinlich trotzdem nicht rum.

  • doppelte Bilder verhindern:
    Sobald realisiert, kann in der Datenbank ein Hash-Wert der Bilder gespeichert werden, so daß beim Upload eines Bildes, das schon existiert, dieses eingefügt wird, so daß keine doppelten Bilder vorkommen können.

  • Upload-Limit pro User:
    Ergibt erst wirklich Sinn, wenn die Datenbankanbindung realisiert ist und könnte ein Limit (Anzahl Files / Anzahl Bytes) pro User festlegen. Nach Erreichung des Limits kann der entsprechende User keine Bilder mehr hochladen.

  • Anbindung von UploadPic an das Lexicon-MOD: (erledigt)
    Prüfung, ob hochgeladene Bilder im Lexicon verwendet werden.

  • Skalierung ausschalten: (erledigt)
    Offenbar unterstützen einige Versionen der GD-Library das Skalieren der Bilder nicht für alle möglichen Varianten von Bilddateien, daher könnte eine Option im ACP die Skalierung von Bildern komplett ausschalten, dann wäre nur der Upload von Bildern möglich, die von der Größe her innerhalb der erlaubten Abmessungen liegen.

  • EXIF-Daten auslesen:
    Die EXIF-Daten eines Bildes (die z.B. den Typ der verwendeten Kamera, etc.) enthalten, könnten von UploadPic ausgelesen und (in der Datenbank, nach Umsetzung der DB-Anbindung) gespeichert werden.
    Für das Anzeigen dieser Daten im APC reicht das, für die Anzeige in einer Nachricht fehlt bisher noch eine zündende Idee, die auch in vertretbarer Zeit umsetzbar wäre.

  • Thumbnails:
    Bild als "Thumbnail" einfügen, bei Klick darauf Öffnen des Bildes in Originalgröße. (Nachteil: Bild muß dazu in zwei Formaten gespeichert werden.)
    Eingefügt würden die Bilder dann mit folgendem Code:

    Code:
    [url=grossesbild][img]kleinesbild[/img][/url]

  • Upload für Gäste: (erledigt)
    Per ACP könnte auch Gästen erlaubt werden, Bilder hochzuladen.

  • "automatisches Wasserzeichen":
    es gab mal eine Anfrage, ein Wasserzeichen in die hochgeladenen Bilder einzublenden, wenn der Benutzer diese Option auswählt, so daß automatisch der Username und der Forumname in das Bild eingefügt werden
    Dazu gibt es noch keine weiteren Ausführungen - wenn das Bild nämlich sehr klein ist, der User aber "Hans-Joachim Schnepfensteg von Hohenhagen" und das Forum ähnlich dämlich heißt, müßte die Schrift entweder proportional verkleinert (und in diesem Fall unleserlich) werden oder es müßte zusätzlich geprüft werden, wie lang das Wasserzeichen wird, so daß es nur bei entsprechend großen Bildern eingefügt würde.

  • Bilder auf Remote-Server:
    Dieses Feature wird vorerst GANZ ganz weit zurückgestellt - wahrscheinlich sogar überhaupt nicht realisiert.
    Der Grund: jede einzelne Funktion, die auf hochgeladene Dateien zugreift, muß in zweifacher Ausführung programmiert werden - einmal für lokale Dateien und einmal als "FTP-Version" für Remote-Dateien und das ist ein extremer Aufwand, zu dem ich zeitlich einfach erstmal nicht komme.
    Ein weiterer Stolperstein, der die Sache (vor allem für mich) total unmöglich macht: bei kaum einer PHP-Installation (meiner hier eingeschlossen) sind die FTP-Funktionen mit einkompiliert, d.h. von den Funktionen würde nur ein Bruchteil der Foren überhaupt profitieren können (ich auch nicht).


____________
beehave - home of humbug ... [we can't afford to be neutral]


Zuletzt bearbeitet von boris am Sa, 30 Sep 2006, 19:41, insgesamt 19-mal bearbeitet. (0 Prozent)

Nach oben
Private Nachricht senden Website dieses Benutzers besuchen Rang:godmode methusalem 3. platz professioneller Sportangler Profi-Winzer (7x Hamm) Arcade-Meister, Rang 16 rainbow-cup
karstenkurt





Titel: (Kein Titel)
Verfasst am: Sa, 11 März 2006, 00:46
Beitrag
Antworten mit Zitat

Ab und an stolpert man förmlich über neue Features Very Happy

Das Verhindern von doppelten Bilder-Uploads wäre auch noch nett. Beipielmod für das Smartor Album gibt es hier

Kannst ja mal drüber nachdenken?

Nach oben
Rang:
boris



Beiträge: 10136

Titel: (Kein Titel)
Verfasst am: Sa, 11 März 2006, 11:43
Beitrag
Antworten mit Zitat

karstenkurt @ Fr, 10 März 2006, 23:46 gab folgendes von sich:
Kannst ja mal drüber nachdenken?

Merke ich mich vor, wenn ich auch nicht glaube, daß doppelte Bilder ein massives Problem darstellen.

Folgende Voraussetzungen sind (leider) gegeben, so daß der Umbau nicht gerade eine Sache von Minuten ist:
  1. entweder müssen die Hash-Werte in der Datenbank gespeichert werden - in dem Fall würde ich UploadPic komplett auf Datenbank-Basis umbauen, damit das Gerödel im userpix-Verzeichnis aufhört (bei mehreren Tausend Bilder kann das schonmal nerven)
  2. die Hash-Werte stehen in einer Extra-Datei, die ausgelesen wird ... einfacher zu erledigen, die Datei muß "nur" nach jedem Upload aktualisiert und vor jedem neuen Upload eingelesen werden ...
Ein Datenbank-gestütztes UploadPic ist auf jeden Fall schneller und eleganter, leider auch deutlich mehr Arbeit Confused


____________
beehave - home of humbug ... [we can't afford to be neutral]

Nach oben
Private Nachricht senden Website dieses Benutzers besuchen Rang:godmode methusalem 3. platz professioneller Sportangler Profi-Winzer (7x Hamm) Arcade-Meister, Rang 16 rainbow-cup
karstenkurt





Titel: (Kein Titel)
Verfasst am: Sa, 11 März 2006, 11:48
Beitrag
Antworten mit Zitat

Würde aber auch einen DB gestützen vorziehen Very Happy
Nach oben
Rang:
boris



Beiträge: 10136

Titel: (Kein Titel)
Verfasst am: Sa, 11 März 2006, 12:45
Beitrag
Antworten mit Zitat

Würden wir das nicht alle ? big grin

____________
beehave - home of humbug ... [we can't afford to be neutral]

Nach oben
Private Nachricht senden Website dieses Benutzers besuchen Rang:godmode methusalem 3. platz professioneller Sportangler Profi-Winzer (7x Hamm) Arcade-Meister, Rang 16 rainbow-cup
easygo





Titel: (Kein Titel)
Verfasst am: Mi, 05 Apr 2006, 17:02
Beitrag
Antworten mit Zitat

Hi! Ich denk mal, bei der Masse würd das Auslagern der config values in
ne eigene Table schon Sinn machen. Was meinst du?

Hab das mal provisorisch umgeschrieben. Scheint zu gehn. easy

Nach oben
Rang:
boris



Beiträge: 10136

Titel: (Kein Titel)
Verfasst am: Do, 06 Apr 2006, 12:01
Beitrag
Antworten mit Zitat

easygo @ Mi, 05 Apr 2006, 17:02 gab folgendes von sich:
Hi! Ich denk mal, bei der Masse würd das Auslagern der config values in ne eigene Table schon Sinn machen.

Welchen Sinn siehst du darin ? Der erschließt sich mir nämlich überhaupt nicht ...

1. die Werte müssen permanent im Speicher sein, es ist rein vom Speicherverbrauch (der eh zu vernachlässigen ist) also egal, woher die Daten kommen.

2. alle Werte aus der Config müssen am Anfang einer Seite in den Speicher geladen werden - mit der vorhandenen Routine ist das schon erledigt, würde eine eigene Tabelle vorliegen, müßte man diese Routine erweitern oder eine eigene einfügen (unnötig)

3. da die Werte bei den Leuten, die UploadPic schon installiert haben, nunmal schon in der phpbb_config liegen, müßte jeder die Daten bei der nächsten Version erst umrödeln - meiner Ansicht nach ein absolut unnötiger Aufwand, der ein zusätzlich noch ein Extra-Skript erfordern würde

4. alle Werte können im ACP geändert werden, welchen Vorteil bringt es dann, die Werte in einer eigenen Tabelle zu haben statt an der Stelle, wo auch alle anderen Config-Werte liegen ??


____________
beehave - home of humbug ... [we can't afford to be neutral]

Nach oben
Private Nachricht senden Website dieses Benutzers besuchen Rang:godmode methusalem 3. platz professioneller Sportangler Profi-Winzer (7x Hamm) Arcade-Meister, Rang 16 rainbow-cup
easygo





Titel: (Kein Titel)
Verfasst am: Do, 06 Apr 2006, 16:36
Beitrag
Antworten mit Zitat

Wer nicht will... kein Problem. Cool

Werde bestimmt niemandem was aufdrängen! Für mich sind deine 24(?) Einträge
in die boardeigene Config nur fürs Posten relevant, ACP mal ausgenommen.

Da drängt sich halt die Frage auf, wozu andere Teile des Boards mit der XXL-Config
für eine einzige MOD belastet werden müssen, die in aller Regel nicht alleine ist.

Rechne deine 24 Einträge ruhig mal hoch auf 7-12 ähnlich umfangreiche Mods
und du wirst vielleicht erkennen, dass es den Zugriffszeiten nicht besonders dienlich ist,
wenn jeder seinen Kram in der Board-Config unterbringt, meine Erfahrung.

Btw: was den Aufwand fürs Umschreiben und Updaten angeht --> eher geringfügig

aber wie schon eingangs erwähnt ^^ So easy

Nach oben
Rang:
boris



Beiträge: 10136

Titel: (Kein Titel)
Verfasst am: Do, 06 Apr 2006, 16:56
Beitrag
Antworten mit Zitat

easygo @ Do, 06 Apr 2006, 16:36 gab folgendes von sich:
Für mich sind deine 24(?) Einträge in die boardeigene Config nur fürs Posten relevant

Mit einigen (nicht seltenen) Modifikationen wird das Posten schnell erweitert: Avatar hochladen, easyCMS, Knowledge Base, Lexicon MOD, Quick Reply, etc. etc. ... dafür müßte dann überall zusätzlich aufgepaßt werden, daß die Daten da auch vorhanden sind.

easygo gab folgendes von sich:
Da drängt sich halt die Frage auf, wozu andere Teile des Boards mit der Config für eine einzige MOD belastet werden müssen

"Belasten" wäre für mich, wenn ich mal eben ein paar MB dauerhaft im Speicher des Servers halten würde - rechne die Anzahl der Bytes der Einträge mal hoch, soviel kann jeder Server tausendfach aushalten, zumal der Speicher nach Beendigen der Seite wieder freigegeben wird (noch ein Punkt, den man manuell beachten müßte).

easygo gab folgendes von sich:
Btw: was den Aufwand fürs Umschreiben und Updaten angeht --> eher geringfügig

Sehe ich nicht unbedingt so - vor allem der Aufwand für Leute, die keine Ahnung haben ... trotz umfassendster FAQ und Support bis zum Abwinken gibt es immer noch Leute, die den Satz "Bitte Install-Skript ausführen" nicht nur nicht verstehen sondern auch schlichtweg ignorieren ... wenn jetzt die diversen 1000 Leute, die UploadPic installiert haben, nur zu einem Bruchteil hier antanzen, weil sie das Update nicht hinkriegen und dann noch für den "Nutzen" ... neee, lass mal.


Trotzdem danke für den Hinweis, aber ich bin halt nicht überzeugt big grin


____________
beehave - home of humbug ... [we can't afford to be neutral]

Nach oben
Private Nachricht senden Website dieses Benutzers besuchen Rang:godmode methusalem 3. platz professioneller Sportangler Profi-Winzer (7x Hamm) Arcade-Meister, Rang 16 rainbow-cup
easygo





Titel: (Kein Titel)
Verfasst am: Do, 20 Apr 2006, 17:08
Beitrag
Antworten mit Zitat

Mal noch ein Hinweis: Die Antwort auf file_exists war nach Einbau generell 'false'

Hab deshalb

Code:
      'L_UPLOADPIC' => (file_exists($images['uploadpic_button'])) ? '<img src="'.$images['uploadpic_button'].'" name="upbutton" alt="'.$lang['UploadPic'].'" title="'.$lang['UploadPic'].'" border="0">' : $lang['UploadPic'],


ersetzt durch

Code:
      'L_UPLOADPIC' => (isset($images['uploadpic_button'])) ? '<img src="'.$images['uploadpic_button'].'" name="upbutton" alt="'.$lang['UploadPic'].'" title="'.$lang['UploadPic'].'" border="0" />' : $lang['UploadPic'],

Nach oben
Rang:
boris



Beiträge: 10136

Titel: (Kein Titel)
Verfasst am: Do, 20 Apr 2006, 17:56
Beitrag
Antworten mit Zitat

easygo @ Do, 20 Apr 2006, 17:08 gab folgendes von sich:
Mal noch ein Hinweis: Die Antwort auf file_exists war nach Einbau generell 'false'

confused4 ... bei mir nicht, wie du an der Anzeige des UploadPic-Buttons über dem Textfeld sehen kannst ...

Wenn ich "isset" abfrage, kann ich zwar feststellen, ob die Änderung in der Config-Datei des Templates korrekt vorgenommen wurde, aber nicht, ob auch die Grafik an Ort und Stelle ist, was ich nur mit "file_exists" rauskriege.
"isset" resultiert dann dann u.U. in einer fehlenden Grafik und genau das wollte ich ja vermeiden ...


____________
beehave - home of humbug ... [we can't afford to be neutral]

Nach oben
Private Nachricht senden Website dieses Benutzers besuchen Rang:godmode methusalem 3. platz professioneller Sportangler Profi-Winzer (7x Hamm) Arcade-Meister, Rang 16 rainbow-cup
Seimon





Titel: Re: zukünftige Features, v1.3.2
Verfasst am: Di, 01 Aug 2006, 09:57
Beitrag
Antworten mit Zitat

boris @ Fr, 17 Feb 2006, 10:25 gab folgendes von sich:
[list][*]"paginate" für Userliste:
ich möchte bei einem extrem großen Forum (also, sagen wir mal, über 10.000 User) nicht wirklich die "permissions"-Liste für die Benutzer aufmachen müssen big grin


Wär toll wenns das bald geben würde...

Da sollte man dann aber auch einen Button für "Alle dürfen" und "Alle dürfen nicht" machen.

Bei mir sinds 50000 User und da wär die pagination nur eine Schutzfunktion wenn man versehentlich auf die Liste klickt, verwalten kann man damit nichts mehr Very Happy

Nach oben
Rang:
boris



Beiträge: 10136

Titel: Re: zukünftige Features, v1.3.2
Verfasst am: Di, 01 Aug 2006, 10:57
Beitrag
Antworten mit Zitat

Seimon @ Di, 01 Aug 2006, 09:57 gab folgendes von sich:
Da sollte man dann aber auch einen Button für "Alle dürfen" und "Alle dürfen nicht" machen.

Den gibts doch schon !?


____________
beehave - home of humbug ... [we can't afford to be neutral]

Nach oben
Private Nachricht senden Website dieses Benutzers besuchen Rang:godmode methusalem 3. platz professioneller Sportangler Profi-Winzer (7x Hamm) Arcade-Meister, Rang 16 rainbow-cup
Seimon





Titel: (Kein Titel)
Verfasst am: Di, 01 Aug 2006, 11:08
Beitrag
Antworten mit Zitat

Du meinst das Javascript "alle/keiner" Hakerl?

Das würde ja bei einer Pagination nicht mehr funktionieren

Nach oben
Rang:
boris



Beiträge: 10136

Titel: (Kein Titel)
Verfasst am: Di, 01 Aug 2006, 13:12
Beitrag
Antworten mit Zitat

Seimon @ Di, 01 Aug 2006, 11:08 gab folgendes von sich:
Du meinst das Javascript "alle/keiner" Hakerl? Das würde ja bei einer Pagination nicht mehr funktionieren

Genau das - das würde bei der Pagination dann halt nur noch für die jeweilige Seite funktionieren.

Aber mal im Ernst: wenn du bei 50.000 Usern alle/keiner setzen willst, dann änderst du besser den Default-Wert in der Datenbank und klickst nur die einzeln weg/dazu, die du willst bzw. machst eben schnell ein UPDATE auf die phpbb_users-Tabelle, um "alle/keiner" zu erreichen.


____________
beehave - home of humbug ... [we can't afford to be neutral]

Nach oben
Private Nachricht senden Website dieses Benutzers besuchen Rang:godmode methusalem 3. platz professioneller Sportangler Profi-Winzer (7x Hamm) Arcade-Meister, Rang 16 rainbow-cup
Seimon





Titel: (Kein Titel)
Verfasst am: Di, 01 Aug 2006, 13:42
Beitrag
Antworten mit Zitat

Ich mach das eh in der db...

Hab mir nur gedacht, wenn man schon die pagination macht gehört das auch der Vollständigkeit halber hin

Nach oben
Rang:
boris



Beiträge: 10136

Titel: (Kein Titel)
Verfasst am: Di, 01 Aug 2006, 14:20
Beitrag
Antworten mit Zitat

Seimon @ Di, 01 Aug 2006, 13:42 gab folgendes von sich:
Hab mir nur gedacht, wenn man schon die pagination macht gehört das auch der Vollständigkeit halber hin

Das müßten dann aber eh Extra-Links sein, bei denen explizit darauf hingewiesen wird, das ALLE Datensätze betroffen sind.
Ich glaube nicht, daß irgendwer drauf käme, daß beim Setzen eines Häkchens auch Datensätze geändert werden, die überhaupt nicht aufgelistet sind !


____________
beehave - home of humbug ... [we can't afford to be neutral]

Nach oben
Private Nachricht senden Website dieses Benutzers besuchen Rang:godmode methusalem 3. platz professioneller Sportangler Profi-Winzer (7x Hamm) Arcade-Meister, Rang 16 rainbow-cup
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    beeForum Foren-übersicht » hal9000 » mod support Seite 1 von 1
Gehe zu:  



ähnliche Beiträge
Thema Autor Forum Antworten Verfasst am
Keine neuen Beiträge Neue Features 12/2008 boris werkstatt 0 Sa, 06 Dez 2008, 18:00 Letzten Beitrag anzeigen
Keine neuen Beiträge zukünftige Features, v1.3.7 boris mod support 0 Di, 06 März 2007, 19:55 Letzten Beitrag anzeigen
Keine neuen Beiträge zukünftige Features, v1.3.3 boris mod support 0 Sa, 30 Sep 2006, 19:44 Letzten Beitrag anzeigen
Keine neuen Beiträge zukünftige Features, v1.1 boris mod support 0 Fr, 26 Mai 2006, 16:41 Letzten Beitrag anzeigen
Keine neuen Beiträge zukünftige Features, v1.0.0 boris mod support 7 Mo, 16 Jan 2006, 19:38 Letzten Beitrag anzeigen


Schreiben: nein. Antworten: nein. Bearbeiten: nein. Löschen: nein. Umfragen: nein.
phpBB © phpBB Group | impressum