|
Autor |
Nachricht |
boris
Beiträge: 11195
|
Titel: zukünftige Features, v1.3.2
Verfasst am: Fr, 17 Feb 2006, 10:25 |
|
|
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
- "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 |
|
karstenkurt
|
Titel: (Kein Titel)
Verfasst am: Sa, 11 März 2006, 00:46 |
|
|
Ab und an stolpert man förmlich über neue Features
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 |
|
boris
Beiträge: 11195
|
Titel: (Kein Titel)
Verfasst am: Sa, 11 März 2006, 11:43 |
|
|
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:
- 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)
- 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
____________ beehave - home of humbug ... [we can't afford to be neutral]
|
|
Nach oben |
|
karstenkurt
|
Titel: (Kein Titel)
Verfasst am: Sa, 11 März 2006, 11:48 |
|
|
Würde aber auch einen DB gestützen vorziehen
|
|
Nach oben |
|
boris
Beiträge: 11195
|
Titel: (Kein Titel)
Verfasst am: Sa, 11 März 2006, 12:45 |
|
|
Würden wir das nicht alle ?
____________ beehave - home of humbug ... [we can't afford to be neutral]
|
|
Nach oben |
|
easygo
|
Titel: (Kein Titel)
Verfasst am: Mi, 05 Apr 2006, 17:02 |
|
|
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 |
|
boris
Beiträge: 11195
|
Titel: (Kein Titel)
Verfasst am: Do, 06 Apr 2006, 12:01 |
|
|
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 |
|
easygo
|
Titel: (Kein Titel)
Verfasst am: Do, 06 Apr 2006, 16:36 |
|
|
Wer nicht will... kein Problem.
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 |
|
boris
Beiträge: 11195
|
Titel: (Kein Titel)
Verfasst am: Do, 06 Apr 2006, 16:56 |
|
|
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
____________ beehave - home of humbug ... [we can't afford to be neutral]
|
|
Nach oben |
|
easygo
|
Titel: (Kein Titel)
Verfasst am: Do, 20 Apr 2006, 17:08 |
|
|
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 |
|
boris
Beiträge: 11195
|
Titel: (Kein Titel)
Verfasst am: Do, 20 Apr 2006, 17:56 |
|
|
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' |
... 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 |
|
Seimon
|
Titel: Re: zukünftige Features, v1.3.2
Verfasst am: Di, 01 Aug 2006, 09:57 |
|
|
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 |
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
|
|
Nach oben |
|
boris
Beiträge: 11195
|
Titel: Re: zukünftige Features, v1.3.2
Verfasst am: Di, 01 Aug 2006, 10:57 |
|
|
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 |
|
Seimon
|
Titel: (Kein Titel)
Verfasst am: Di, 01 Aug 2006, 11:08 |
|
|
Du meinst das Javascript "alle/keiner" Hakerl?
Das würde ja bei einer Pagination nicht mehr funktionieren
|
|
Nach oben |
|
boris
Beiträge: 11195
|
Titel: (Kein Titel)
Verfasst am: Di, 01 Aug 2006, 13:12 |
|
|
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 |
|
Seimon
|
Titel: (Kein Titel)
Verfasst am: Di, 01 Aug 2006, 13:42 |
|
|
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 |
|
boris
Beiträge: 11195
|
Titel: (Kein Titel)
Verfasst am: Di, 01 Aug 2006, 14:20 |
|
|
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 |
|
|
|
ähnliche Beiträge |
|
Thema
| Autor
| Forum
| Antworten
| Verfasst am
|
|
Neue Features 12/2008 |
boris |
werkstatt |
0 |
Sa, 06 Dez 2008, 18:00 |
|
zukünftige Features, v1.3.7 |
boris |
mod support |
0 |
Di, 06 März 2007, 19:55 |
|
zukünftige Features, v1.3.3 |
boris |
mod support |
0 |
Sa, 30 Sep 2006, 19:44 |
|
zukünftige Features, v1.1 |
boris |
mod support |
0 |
Fr, 26 Mai 2006, 16:41 |
|
zukünftige Features, v1.0.0 |
boris |
mod support |
7 |
Mo, 16 Jan 2006, 19:38 |
Schreiben: nein. Antworten: nein. Bearbeiten: nein. Löschen: nein. Umfragen: nein.
|