Verbesserung der Bequemlichkeit bei der Einstellung des automatischen Rasters für weniger als 3 Bilder

Konfigurierbare Mindestanzahl von Bildern für automatische Bildergitter

Ich bin auf eine Einschränkung der Funktion für automatische Bildergitter gestoßen.

Derzeit scheint das Verhalten des automatischen Gitters durch die Website-Einstellung für automatische Bildergitter gesteuert zu werden, aber der tatsächliche Schwellenwert, ab dem der Composer [grid]...[/grid] einfügt, ist weiterhin im Frontend-Code fest codiert.

Die relevante Composer-Logik verwendet derzeit einen hartcodierten Wert:

const MIN_IMAGES_TO_AUTO_GRID = 3;

Soweit ich das beurteilen kann, haben Administratoren derzeit die Wahl zwischen:

Was Administratoren derzeit tun können Ergebnis
Automatische Bildergitter aktivieren Uploads von 3 oder mehr aufeinanderfolgenden Bildern werden automatisch in [grid]...[/grid] eingebettet
Automatische Bildergitter deaktivieren Keine automatische Gitter-Einbettung
Den Schwellenwert von 3 auf eine andere Zahl ändern Derzeit nicht als Website-Einstellung verfügbar

Das Problem ist, dass 3 nicht unbedingt der richtige Schwellenwert für jede Community ist.

Für einige Websites sind automatische Gitter nützlich, aber nur, wenn Benutzer eine größere Anzahl von Bildern hochladen. Ein Administrator möchte beispielsweise, dass das automatische Gitter erst ab 5, 6, 10 oder einem anderen Wert beginnt, anstatt bereits beim Hochladen von 3 Bildern zu reagieren.

Dies wäre besonders nützlich für Communities, in denen Benutzer oft eine kleine Anzahl von Bildern zusammen mit erläuterndem Text hochladen, größere Galerien jedoch weiterhin in einem Gitter kompakt dargestellt werden sollen.

Vorgeschlagene Richtung

Ich denke, dies könnte verbessert werden, indem eine konfigurierbare Website-Einstellung für die Mindestanzahl aufeinanderfolgender Bild-Uploads hinzugefügt wird, bevor der Composer automatisch ein Gitter einfügt.

Etwas in der Art von:

auto_grid_images_minimum_count
```\n
Zum Beispiel:

| Einstellung | Beispielwert |
| --- | --- |
| `enable_auto_grid_images` | `true` |
| `auto_grid_images_minimum_count` | `5` |

Dann wäre das automatische Gitter weiterhin verfügbar, würde aber erst ausgelöst, wenn der konfigurierte Schwellenwert erreicht ist.

Dies behält das bestehende Verhalten als Standard bei, wenn die neue Einstellung standardmäßig auf `3` gesetzt ist, und gibt den Administratoren mehr Kontrolle.

## Experimenteller Zweig / möglicher Vorsprung

Ich habe hier einen kleinen experimentellen Zweig erstellt, falls jemand mit mehr Erfahrung in der Discourse-Entwicklung Zeit hat, ihn zu forken, zu bereinigen oder die Idee weiterzuverfolgen:

[image-grid-num-setting branch](https://github.com/Ethsim12/discourse/tree/image-grid-num-setting)

Der Zweig ist nicht als polierter PR gedacht. Er ist eher ein Ausgangspunkt, der die beabsichtigte Richtung zeigt:

- eine neue Website-Einstellung für die Mindestanzahl von Bildern im automatischen Gitter hinzufügen
- diese Einstellung für den Client verfügbar machen
- den hartcodierten `MIN_IMAGES_TO_AUTO_GRID = 3`-Check im Composer-Upload-Code durch den konfigurierten Wert ersetzen
- den Text der Admin-Einstellung aktualisieren, sodass die bestehende Beschreibung für automatische Gitter nicht mehr impliziert, dass der Schwellenwert immer 3 ist
- Frontend-Specs aktualisieren/hinzufügen, falls erforderlich

Die Art der Frontend-Änderung, die ich im Sinn hatte, ist ungefähr:

```js
const minImagesToAutoGrid = Number(
  this.siteSettings.auto_grid_images_minimum_count ?? 3
);

if (
  this.siteSettings.enable_auto_grid_images &&
  this.#consecutiveImages?.length >= minImagesToAutoGrid &&
  this.textManipulation
) {
  this.textManipulation.autoGridImages([...this.#consecutiveImages]);
  this.#consecutiveImages.length = 0;
}

Es gibt auch ein aktuelles Beispiel für eine Discourse-typische Aufzählung (enum) als Website-Einstellung in PR #36014:

PR #36014 - FEATURE: adds calendar_upcoming_events_default_view setting

Dieser PR ist für das Kalender- und Events-Plugin und nicht direkt für Bildergitter gedacht, daher schlage ich nicht vor, dass er diese Funktion beeinflusst. Ich erwähne ihn, weil er ein nützliches Implementierungsmuster für diese Art von konfigurierbarer Website-Einstellung zu zeigen scheint: die Einstellung definieren, sie für den Client verfügbar machen und sie dann im Frontend über siteSettings auslesen.

Verwandte Links

Ursprüngliche Diskussion über das Deaktivieren von automatischen Bildergittern:

Turning off auto-grid-images?

Ankündigung zu automatischen Bildergittern:

Automatically apply grids to image uploads

Beispiel-PR, der die Architektur von Website-Einstellungen zeigt:

PR #36014 - FEATURE: adds calendar_upcoming_events_default_view setting

Mein experimenteller Zweig:

image-grid-num-setting branch

2 „Gefällt mir“

Könntest du etwas mehr über deine konkreten Erfahrungen berichten?

Welche Einstellung würdest du verwenden und warum?

Danke – ja.

Für meine Seite würde ich den Schwellenwert wahrscheinlich auf 5 Bilder setzen.

Der Grund ist, dass viele Beiträge natürlich 3 Bilder enthalten können, ohne wirklich eine „Galerie“ zu sein. Zum Beispiel könnte ein Benutzer hochladen:

  • einen Screenshot eines Problems
  • einen zweiten Screenshot, der die relevante Einstellung/den Fehler zeigt
  • ein drittes Bild, das das Ergebnis oder den Vergleich zeigt

In dieser Situation wendet sich das automatische Raster auf aufeinanderfolgende Bilder an und hilft, visuelles Chaos zu verhindern.

Ich bin auch der Ansicht, dass das Ermutigen vieler Bilduploads nicht ideal für Speicher- oder Backup-Größen ist, also versuche ich nicht, Benutzer zu bildlastigen Beiträgen zu drängen. Mein Punkt bezieht sich eher auf die Layoutkontrolle, wenn bereits mehrere Bilder hochgeladen werden.

Für mich wird das automatische Raster nützlicher, wenn ein Beitrag deutlich über einige erklärende Bilder hinausgeht und in eine größere Anzahl von Bildern übergeht. Etwa 5 Bilder fühlt sich auf meiner Seite wie ein besserer Schwellenwert dafür an.

Also möchte ich das automatische Raster nicht vollständig deaktivieren. Ich mag die Funktion in manchen Fällen. Das Problem ist nur, dass der aktuelle feste Schwellenwert von 3 etwas zu aggressiv ist für Communities, in denen kleine Gruppen von Bildern oft als Teil einer Erklärung verwendet werden.

Deshalb denke ich, dass eine Seiteneinstellung wie auto_grid_images_minimum_count nützlich wäre. Seiten, die das aktuelle Verhalten mögen, könnten es bei 3 belassen, während Seiten wie meine es auf 5, 2 oder einen anderen Wert erhöhen könnten.

2 „Gefällt mir“

In deinem speziellen Fall, was wäre, wenn stattdessen:

  • auto-grid standardmäßig das “Karussell”-Layout verwenden würde oder
  • es für Benutzer einfacher wäre, die gesamte Gruppe zu “entgittern”

Mir kommt gerade noch eine weitere Idee…

Vielleicht wäre es sinnvoll, das Konzept einer “Bildgruppe” vom “Layout” dieser Gruppe weiter zu trennen.

Zum Beispiel: Im Rich-Editor könnten Sie zwischen drei Optionen für eine Gruppe (Liste, Gitter, Karussell) umschalten, während alle Elemente in der Gruppe bleiben. Vielleicht würde es Benutzern oder Moderatoren so erleichtert, das bevorzugte Layout mit einem einzigen Klick auszuwählen, falls die Heuristik zur Auswahl des Standardlayouts nicht ihren Wünschen entspricht.

Ja, ich finde, dass diese Trennung sinnvoll ist.

In meinem Fall liegt das Hauptproblem eigentlich nicht daran, dass Grids existieren. Das Problem ist, dass die aktuelle Heuristik die Layout-Entcheidung recht früh trifft – nämlich bei drei aufeinanderfolgenden Bildern – und diese Entscheidung dann als [grid]...[/grid]-Markup im Beitrag festlegt.

Ich stimme zu, dass die Trennung von „dies ist eine Gruppe von Bildern“ und „diese Gruppe soll als Liste/Grid/Karussell dargestellt werden“ wahrscheinlich ein saubereres Langzeit-Modell wäre.

Etwas in dieser Richtung würde für mich Sinn ergeben:

  • Der Composer erkennt oder erstellt eine Bildgruppe, also Erkennung im Rich-Text-Editor oder Erstellung im Markdown-Editor.
  • Die Gruppe hat eine Layout-Option: Liste, Grid oder Karussell – ein Parameter des BBCode.
  • Nutzer oder Moderatoren können dieses Layout mit einer einzigen Aktion ändern, was über das zweite Feld im Markdown-Editor möglich ist.
  • Der Beitrag hängt nicht davon ab, dass Nutzer die [grid]-Tags verstehen oder sorgfältig beibehalten, was genau der Vorteil des einfeldrigen Rich-Text-Editors ist.

Das würde wahrscheinlich mehr Fälle lösen als nur das Hinzufügen einer Schwellenwert-Einstellung, aber es ist dennoch eine umfassendere Funktion.

Für meine spezifische Site würde ich wahrscheinlich immer noch Liste als Standard für kleine Bildgruppen wählen, da drei Screenshots oft Teil einer Erklärung sind und nicht einer Galerie. Bei größeren Stapeln sehe ich Grid oder Karussell als nützlich an.

Es gibt also vielleicht zwei Ebenen der Verbesserung:

  1. Eine kleinere Admin-Einstellung für das aktuelle Verhalten, wie auto_grid_images_minimum_count, wobei der bestehende Standardwert von 3 beibehalten wird.
  2. Ein umfangreicheres Modell für das Layout von Bildgruppen später, bei dem Liste/Grid/Karussell leichter geändert werden können, ohne das Markup manuell bearbeiten zu müssen. Dieses gehört jedoch meiner Meinung nach in ein anderes Feature-Anfrage-Thema.

Falls die zweite Richtung bevorzugt wird, ist mein ursprünglicher Vorschlag bezüglich dieser Schwellenwert-Einstellung vielleicht weniger wichtig, aber ich glaube, das zugrunde liegende Problem ist dasselbe: Admins und Nutzer brauchen etwas mehr Kontrolle darüber, wann mehrere Bilder als Galerie-Block statt als normale Inline-Erklärungsbilder behandelt werden.

1 „Gefällt mir“

Also, ja, ich denke, der Ansatz, den ich jetzt im Kopf habe, wäre folgender:

  • Wenn > 1 Bild hochgeladen wird, in [grid] einbetten
    • Wenn die Anzahl <= 3 ist, standardmäßig [grid mode=list] verwenden
    • Wenn die Anzahl > 3 und <= 10 ist, standardmäßig [grid mode=grid] verwenden
    • Wenn die Anzahl > 10 ist, standardmäßig [grid mode=carousel] verwenden
  • Im Rich-Modus und in der Vorschau dem Nutzer das Umschalten zwischen den Modi list, grid und carousel erleichtern

@chapoi und @renato, ich bin gespannt auf eure Gedanken dazu.

1 „Gefällt mir“

Bin nicht überzeugt. Auch im Fall des Screenshot-Beispiels des Threaderstellers würde ich diese gerne nebeneinander haben.

Ich bin eher für die ursprünglich vorgestellte Einstellung, falls überhaupt, als dafür, es „clever“ zu lösen. Aber wir sollten abwarten, bis dieser Feature-Request mehr Stimmen hat oder wir das Gleiche woanders gehört haben, bevor wir irgendeine Maßnahme ergreifen.

1 „Gefällt mir“