Das ist genau der Grund, warum dieses Thema dorthin gehört, wo wir hingewiesen werden. Der Originalbeitrag enthält eine Liste, die anscheinend recht häufig aktualisiert wird. Wenn Sie sich den Bearbeitungsverlauf ansehen, können Sie erkennen, welche Plugins wann hinzugefügt wurden.
3 „Gefällt mir“
Wir sind vorerst fertig! Der letzte verbleibende ist der Geburtstag und er wird in ein paar Monaten erledigt sein.
6 „Gefällt mir“
Ich bin vor kurzem gestolpert und über dieses gestolpert. Ich habe angefangen, mich mit der Entwicklung von Discourse zu beschäftigen, daher wollte ich meinen Aktualisierungs-Workflow üben:
# git pull
# bundle install
# pnpm install
# ./bin/rails db:migrate
Aber ich vermute, dass das Discourse AI-Plugin das Pgvector-Plugin für PostgreSQL benötigt (von dem ich vorher nicht wusste, dass es existiert):
== 20230710171141 EnablePgVectorExtension: migrating ==========================
-- enable_extension(:vector)
bin/rails aborted!
StandardError: Ein Fehler ist aufgetreten, diese und alle späteren Migrationen wurden abgebrochen: (StandardError)
ERROR: current transaction is aborted, commands ignored until end of transaction block
/home/john/development/discourse/lib/mini_sql_multisite_connection.rb:109:in 'MiniSqlMultisiteConnection#run'
/home/john/development/discourse/plugins/discourse-ai/db/migrate/20230710171141_enable_pg_vector_extension.rb:8:in 'EnablePgVectorExtension#change'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'block in FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/migration/safe_migrate.rb:28:in 'Migration::SafeMigrate::SafeMigration#migrate'
/home/john/development/discourse/lib/migration/safe_migrate.rb:53:in 'Migration::SafeMigrate::NiceErrors#migrate'
/home/john/development/discourse/lib/tasks/db.rake:267:in 'block (2 levels) in <main>'
/home/john/development/discourse/lib/distributed_mutex.rb:53:in 'block in DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'Thread::Mutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:34:in 'DistributedMutex.synchronize'
/home/john/development/discourse/lib/tasks/db.rake:242:in 'block in <main>'
Caused by:
PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block (PG::InFailedSqlTransaction)
/home/john/development/discourse/lib/mini_sql_multisite_connection.rb:109:in 'MiniSqlMultisiteConnection#run'
/home/john/development/discourse/plugins/discourse-ai/db/migrate/20230710171141_enable_pg_vector_extension.rb:8:in 'EnablePgVectorExtension#change'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'block in FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/migration/safe_migrate.rb:28:in 'Migration::SafeMigrate::SafeMigration#migrate'
/home/john/development/discourse/lib/migration/safe_migrate.rb:53:in 'Migration::SafeMigrate::NiceErrors#migrate'
/home/john/development/discourse/lib/tasks/db.rake:267:in 'block (2 levels) in <main>'
/home/john/development/discourse/lib/distributed_mutex.rb:53:in 'block in DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'Thread::Mutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:34:in 'DistributedMutex.synchronize'
/home/john/development/discourse/lib/tasks/db.rake:242:in 'block in <main>'
Caused by:
ActiveRecord::StatementInvalid: PG::FeatureNotSupported: ERROR: extension "vector" is not available (ActiveRecord::StatementInvalid)
DETAIL: Could not open extension control file "/usr/share/postgresql/extension/vector.control": No such file or directory.
HINT: The extension must first be installed on the system where PostgreSQL is running.
/home/john/development/discourse/plugins/discourse-ai/db/migrate/20230710171141_enable_pg_vector_extension.rb:6:in 'EnablePgVectorExtension#change'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'block in FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/migration/safe_migrate.rb:28:in 'Migration::SafeMigrate::SafeMigration#migrate'
/home/john/development/discourse/lib/migration/safe_migrate.rb:53:in 'Migration::SafeMigrate::NiceErrors#migrate'
/home/john/development/discourse/lib/tasks/db.rake:267:in 'block (2 levels) in <main>'
/home/john/development/discourse/lib/distributed_mutex.rb:53:in 'block in DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'Thread::Mutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:34:in 'DistributedMutex.synchronize'
/home/john/development/discourse/lib/tasks/db.rake:242:in 'block in <main>'
Caused by:
PG::FeatureNotSupported: ERROR: extension "vector" is not available (PG::FeatureNotSupported)
DETAIL: Could not open extension control file "/usr/share/postgresql/extension/vector.control": No such file or directory.
HINT: The extension must first be installed on the system where PostgreSQL is running.
/home/john/development/discourse/plugins/discourse-ai/db/migrate/20230710171141_enable_pg_vector_extension.rb:6:in 'EnablePgVectorExtension#change'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'block in FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/migration/safe_migrate.rb:28:in 'Migration::SafeMigrate::SafeMigration#migrate'
/home/john/development/discourse/lib/migration/safe_migrate.rb:53:in 'Migration::SafeMigrate::NiceErrors#migrate'
/home/john/development/discourse/lib/tasks/db.rake:267:in 'block (2 levels) in <main>'
/home/john/development/discourse/lib/distributed_mutex.rb:53:in 'block in DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'Thread::Mutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:34:in 'DistributedMutex.synchronize'
/home/john/development/discourse/lib/tasks/db.rake:242:in 'block in <main>'
Tasks: TOP => db:migrate
Ich kann das installieren, aber ich frage mich, ob es eine Möglichkeit gibt, Plugins auf dieser Ebene zu deaktivieren, damit ihre Migrationen einfach übersprungen werden. (Ich möchte keine zusätzliche Software installieren, insbesondere für ein “Plugin”, das ich nicht erkunden möchte.)
4 „Gefällt mir“
Ich bin heute auch auf dieses Problem gestoßen. Ich habe das Paket über sudo installiert, nachdem ich etwas Hilfe von ChatGPT erhalten hatte. Ich frage mich auch: Ich frage mich - vielleicht hilft es, den Plugin-Ordner aus dem /plugins-Verzeichnis zu löschen 
… aber git pull könnte ihn später wieder installieren.
2 „Gefällt mir“
Ich lehne diese Änderung ab. Normalerweise bedeutet ein schlanker Kern in der Softwareentwicklung, dass die Hauptdistribution kleiner, schneller und mit weniger Angriffsflächen sein kann. Mein letzter Ausflug in Plugins hat mir gezeigt, dass es technisch möglich ist, dass Plugin-Code auch dann ausgeführt wird, wenn er „deaktiviert“ ist, da dies anscheinend vom Plugin-Autor abhängt. Daher scheint dies das Risiko und den Umfang erheblich zu erhöhen.
Das unmittelbarste Problem ist, dass anscheinend keine Anleitungen im Installationsleitfaden aktualisiert wurden (vielleicht habe ich sie nur übersehen?). Es ist unklar, was wir installieren müssen, damit die Dinge wieder funktionieren. Ich habe einige Fehler behoben, indem ich das Ubuntu-Paket postgresql-16-pgvector installiert habe, hatte aber immer noch einige Vektorfehler beim Ausführen von db:migrate. Ich konnte sie umgehen, indem ich das KI-Plugin lokal gelöscht habe.
Dies ist ohnehin eine Menge zusätzlicher Code, viele dieser Plugins sind für die Anwendungsfälle der meisten Discourse-Communities völlig irrelevant. (Das soll nicht heißen, dass dies schlechte Plugins sind! Ich bin sicher, dass sie für die Communities, die sie benötigen, sehr nützlich sind. Aber ich kann mir nur schwer vorstellen, dass jede Community-Forum mit Zendesk-Integration usw. ausgeliefert werden muss). Insbesondere das KI-Plugin, das aufgrund seiner zusätzlichen Anforderungen Dinge kaputt macht, sollte meiner Meinung nach definitiv aussortiert werden.
Auf persönlicher Ebene, wenn ich mich in meinem Admin-Panel anmelde und plötzlich eine Reihe von Ad-Plugins sehe, auch wenn der Code inaktiv sein sollte, macht mir das extreme Sorgen. Ich möchte mit aller Deutlichkeit zum Ausdruck bringen, dass ich standardmäßig KEINE Ad-Plugins von großen Technologieunternehmen auf meinen Installationen haben möchte, auch nicht deaktiviert. Dies ist eine Branche, die in der Vergangenheit unglaublich missbräuchlich gegenüber der Privatsphäre der Nutzer war, und Discourse hilft sich nicht, indem es solche Integrationen standardmäßig ausliefert. Die Leute, die Werbung wollen, hätten keine Probleme, das entsprechende Plugin zu finden, es ist nicht notwendig, es in allen Installationen einzuschließen.
TLDR: Bitte überdenken Sie diese Änderung. 
5 „Gefällt mir“
Discourse integriert Plugins in den Kern, die in ihren offiziellen Hostings immer angeboten werden
2 „Gefällt mir“
Ich stimme zu, dass dies zusätzlichen Ballast in die Admin-Oberfläche bringt, mit vielen Markennamen, die als Werbung für mein Gehirn gelten. Das ist nicht cool. Als Verfechter freier Software, der sich bemüht, große Marken zu meiden, bin ich der Meinung, dass dies einen Schritt darstellt, den Ubuntu vor einigen Jahren unternommen hat, bevor es vollständig von Armazon, Gaggle und Konsorten kolonisiert wurde. Wenn Sie diese in Ihre Augen lassen, werden sie sie verschlingen.
Das Bündeln der Plugins in den Kern bietet auch Entwicklern die Möglichkeit, eine Plugin-Funktionalität im Laufe der Zeit versehentlich zu einer Anforderung zu machen, während sie als Plugins erhalten bleiben, um sicherzustellen, dass dieser Fehler nicht gemacht werden kann.
Kann das @team die Begründung für diese Änderung erläutern?
Wenn es darum geht, Installationen auf der Discourse-Infrastruktur zu beschleunigen, könnte vielleicht ein discourse-hosting-bundle-Paket, das automatisch in CI erstellt wird, das gleiche Ergebnis erzielen?
4 „Gefällt mir“
@david, können Sie bitte die alphabetische Reihenfolge in der Liste der betroffenen Plugins beibehalten?
Die Motivation hier ist, Erstbenutzern von Discourse eine reibungslosere Erfahrung zu bieten, damit sie von Anfang an eine „voll ausgestattete“ Discourse-Erfahrung erhalten.
Eine weitere Motivation ist die Entwicklererfahrung für unser Team und für Community-Beitragende. Da all diese Plugins mit dem Kern gebündelt sind, muss die Kompatibilität mit verschiedenen Kernversionen nicht mehr berücksichtigt werden. Das ist besonders nützlich für Plugins wie discourse-ai, die derzeit parallel zu verwandten Kernänderungen sehr stark entwickelt werden.
Die gebrandeten Auth-Plugins werden am ehesten in den Kern aufgenommen, genau wie unsere bestehenden Kern-Auth-Methoden wie Google/Facebook/usw. Es besteht also eine gute Chance, dass sie in nicht allzu ferner Zukunft aus der Liste entfernt werden.
Diese Änderung hat keinen Bezug zur Leistung auf unserem Hosting. Wir hatten bereits eine vorgefertigte Distribution mit all diesen Plugins und mehr, wie Sie beschreiben. 
Ich habe die Reihenfolge korrigiert 
7 „Gefällt mir“
[quote=„hellekin, Beitrag:37, Thema:373574″]
Kann das @team die Begründung für diese Änderung erläutern?
[/quote]
Es wurde bereits in der OP beantwortet:
[quote=„david, Beitrag:1, Thema:373574″]
Es wird für uns einfacher sein, sie alle getestet und auf dem neuesten Stand zu halten.
[/quote]
Einige Beispiele dafür:
- Wir müssen uns keine Gedanken über die Versionierung machen, wenn wir etwas im Kern für ein Plugin hinzufügen, wir wissen, dass beide die gleiche Version haben
- Einfacher zu testen ein Plugin, das von einem anderen Plugin abhängt, wenn der Code für beide vorhanden ist
12 „Gefällt mir“
Ich würde es sehr begrüßen, wenn diese aus meiner Benutzeroberfläche verschwinden würden, aber sie nehmen nur Platz ein, weil sie nicht optional oder versteckt sind: Sie sind Teil des Kerns. Genau deshalb machen wir uns Sorgen.
Was die Benutzererfahrung beim ersten Mal betrifft, könnte eine Änderung der Container-Vorlage, um das offizielle Bundle einzuschließen und zu dokumentieren, funktionieren:
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
# Das docker_manager Plugin ist zwingend erforderlich für automatisierte webbasierte Updates
- git clone https://github.com/discourse/docker_manager.git
# Die folgenden Plugins werden auf allen Discourse-gehosteten Instanzen installiert.
# Entfernen Sie das Kommentarzeichen `#` vor der Zeile `- git clone`, um sie zu aktivieren.
# Siehe https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/
# Discourse Advertising Plugin (Anzeigen): https://meta.discourse.org/t/discourse-advertising-plugin-ads/33734
#- git clone https://github.com/discourse/discourse-adplugin
# Discourse Affiliate
#- git clone https://github.com/discourse/discourse-affiliate
# ...
# ...
# Bitte fügen Sie weitere Plugins unten hinzu. Eine Liste der offiziellen Plugins finden Sie unter:
# https://meta.discourse.org/tag/official
# Alle verfügbaren Plugins finden Sie unter:
# https://meta.discourse.org/c/plugin/22
Was die Entwicklererfahrung betrifft, können Sie sicherlich die Übergabe von Plugin-Versionen auf eine andere, weniger aufdringliche Weise automatisieren. Zum Beispiel durch die Verwendung einer pups-Regel, um die Plugins gemäß der obigen Dokumentationsstrategie auszukommentieren.
Sie könnten sogar eine Container-Vorlage haben, die das für Sie erledigt:
templates:
- "templates/discourse.hosting.yml"
- "templates/discourse.core-bundle.yml"
Beachten Sie, dass mein erster Eindruck gut war: Ich konnte ein paar interessante Plugins entdecken, die mir noch nicht bekannt waren. Aber ja, da ich in den letzten zehn Jahren gesehen habe, wie Sie optimieren und nach dem kleinsten gemeinsamen Nenner suchen, überrascht es mich, dass dies die Art und Weise ist, wie Sie einen solchen Vorschlag behandeln.
4 „Gefällt mir“
Ich glaube, Sie können rm -rf discourse-ai hinzufügen, wo normalerweise die git clone-Befehle stehen. Ich habe es selbst noch nicht gemacht.
4 „Gefällt mir“
Ja, technisch gesehen können Sie alle Ordner im Plugin-Verzeichnis entfernen und der Kern-Discourse funktioniert weiterhin.
5 „Gefällt mir“
Es ist eine gute Annahme, dass diese vom Discourse-Team entwickelten Plugins die Regeln befolgen und nur minimalen Overhead hinzufügen. Wenn sie alle aktiviert sind, ist es einfacher zu erkennen, dass sie alle zusammenarbeiten und die gleichen Anforderungen haben.
Verwenden Sie eine externe PostgreSQL-Datenbank anstelle der integrierten? Verwenden Sie ein Zwei-Container-Setup, das seit langem nicht mehr aktualisiert wurde?
Sie können sie entfernen, aber sie können nichts tun, es sei denn, Sie erstellen ein Konto bei den bösen Unternehmen und erhalten Schlüssel, um das Tracking zu ermöglichen.
5 „Gefällt mir“
Vielen Dank für Ihre Antwort,
Hoffentlich ja, aber es ist eine zusätzliche Angriffsfläche für Fehler und Angriffe, im Austausch für keinen Nutzen für Communities, die diese Plugins nicht verwenden (was die meisten Communities sein werden).
Ich glaube, dass Discourse hier ein echtes Problem identifiziert hat, aber die falsche Lösung gefunden hat.
Ich stimme absolut zu, dass es ein echtes Grundproblem mit der Fragilität des Entwicklungs-/Plugin-Ökosystems für Discourse gibt. Es ist definitiv schwierig, gegen ein sich bewegendes Ziel zu entwickeln, und die API-Änderungen im Kern machen das sicherlich schwierig. Bis zu einem gewissen Grad gehört das einfach zur Entwicklung gegen die absolute Spitze, aber genau deshalb sollte das nicht das Standardverhalten sein. Wenn ich nur ein paar einfache Plugins habe, kann ich Ihr Problem (das weitaus umfangreicher ist als meines) verstehen und nachvollziehen.
Was Discourse hier jedoch tut, ist nur, das Problem aufzuschieben. Es löst das Problem vielleicht für Discourse, aber nicht für die übrigen Plugin-Entwickler. Alle anderen durchlaufen denselben Schmerz, nur in kleinerem Maßstab.
Eine bessere Lösung wäre eine robustere LTS-Serie, gegen die entwickelt werden kann. Ich weiß, dass dies anderswo diskutiert wurde, daher werde ich es nicht wiederholen, aber eine der größten Herausforderungen für Communities, Plugin-Entwickler und sogar Discourse-Mitarbeiter scheint zu sein, dass es keine LTS gibt. Die stabile Version wird aktiv von der Nutzung abgeraten. Wenn eine traditionellere Entwicklungspipeline verwendet würde, wäre die Plugin-Entwicklung wesentlich einfacher. Wir hätten bekannte Zeiten, in denen Dinge kaputt gehen (Hauptversions-Upgrades), und könnten uns darauf einstellen. Andernfalls können wir sicher sein, dass die kleineren Upgrades unsere Foren nicht zufällig kaputt machen. (Dies ist wahrscheinlich eines der größten Probleme von Discourse meiner Meinung nach und eines, das ich anderswo aufgetreten sehe, wenn Leute über Forum-Optionen diskutieren. Die Volatilität ist ein echtes Manko.)
Ja – Laut dem Link bin ich auf dieses Problem in einer Entwicklungsumgebung gestoßen, die nicht containerbasiert wäre. (Ich habe dies noch nicht in Produktionscontainern ausprobiert)
Ich denke, das ist eines der Dinge, die mir Sorgen machen: Wenn der “Standard”-Pfad davon ausgeht, dass diese Plugins vorhanden sind, könnte ich auf Fehler stoßen, weil alle anderen Werbe-Plugins akzeptieren. Ich muss entweder unerwartete Fehler riskieren oder mit zusätzlicher Plugin-Last umgehen. Mein Ziel ist es, so viel Stabilität wie möglich für meine Deployments zu haben.
Es ist auch erwähnenswert, dass selbst der Discourse-Kern im Vergleich zu anderen Foren ziemlich ressourcenintensiv ist. Ich denke, es lohnt sich, den Kern schlank zu halten, um Leistungsprobleme nicht weiter zu verschärfen.
Ich habe diese noch nicht überprüft, um sicherzustellen, dass sie keinen Tracking-/Phone-Home-JS ziehen, während sie deaktiviert sind, aber bis dahin gehe ich davon aus, dass Sie Recht haben. Ich hoffe, jemand überprüft das, denn es wird ein riesiges Debakel, wenn sich das als falsch herausstellt.
Ich denke, Hellekins Punkt über Unordnung ist berechtigt, und ich denke auch, dass das, was sie mit dem Big-Tech-Werbe-Plugin meinen, von einigen in der Open-Source-Community nicht gut aufgenommen wird – die Art von Leuten, die eher Open-Source-Foren nutzen.
Auf jeden Fall möchte ich auch sagen, dass ich es schätze, dass Sie mein Feedback hören, auch wenn es nicht einfach ist 
4 „Gefällt mir“
Ich denke, es ist schwierig zu wissen, welche bereits Korrektur gelesen wurden und welche nicht.
Ich habe mich kurz gefragt, ob Sie vorher geprüft hatten, ob noch offene Kommentare vorhanden sind, die jetzt fehlen, da nur die Texte und nicht alle Daten aus Crowdin hinzugefügt wurden. Aber ich gehe davon aus, dass ich die Antwort auf diese Frage gar nicht wissen möchte. Letztendlich macht es keinen Unterschied, ob monatelang niemand antwortet oder ob Fragen und Kommentare von Übersetzern einfach verschwunden sind.
1 „Gefällt mir“
Gibt es Tests für keine Nebeneffekte, wenn Plugin-Verzeichnisse mit dem neuen Bundle entfernt werden, um sicherzustellen, dass ein Plugin nicht unbeabsichtigt zu einer Anforderung wird?
2 „Gefällt mir“
Unsere Kern-Testsuite wird ohne geladene Plugins ausgeführt, daher ja, jede Abhängigkeit von Kern → Plugins sollte von CI erkannt werden.
4 „Gefällt mir“
Ich habe die Zeilen zum Klonen der Plugins auskommentiert, aber wenn ich erneut “launcher rebuild app” ausführe, erhalte ich dieselben Meldungen:
FEHLGESCHLAGEN
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' fehlgeschlagen mit Rückgabe #<Process::Status: pid 546 exit 1>
Ort des Fehlschlags: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn'
exec fehlgeschlagen mit den Parametern {"cd"=>"$home", "tag"=>"migrate", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap fehlgeschlagen mit Exit-Code 1
---
HINWEIS: Das Plugin 'discourse-reactions' ist jetzt in Discourse enthalten und sollte nicht in Ihrer Container-Konfiguration aufgeführt werden.
Entfernen Sie die Zeile 'git clone https://github.com/discourse/discourse-reactions' aus Ihrer containers/app.yml-Datei und versuchen Sie es erneut.
Weitere Informationen finden Sie unter https://meta.discourse.org/t/373574
---
---
HINWEIS: Das Plugin 'discourse-data-explorer' ist jetzt in Discourse enthalten und sollte nicht in Ihrer Container-Konfiguration aufgeführt werden.
Entfernen Sie die Zeile 'git clone https://github.com/discourse/discourse-data-explorer' aus Ihrer containers/app.yml-Datei und versuchen Sie es erneut.
Weitere Informationen finden Sie unter https://meta.discourse.org/t/373574
---
---
HINWEIS: Das Plugin 'discourse-solved' ist jetzt in Discourse enthalten und sollte nicht in Ihrer Container-Konfiguration aufgeführt werden.
Entfernen Sie die Zeile 'git clone https://github.com/discourse/discourse-solved' aus Ihrer containers/app.yml-Datei und versuchen Sie es erneut.
Weitere Informationen finden Sie unter https://meta.discourse.org/t/373574
---
** BOOTSTRAP FEHLGESCHLAGEN ** Bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen, es kann mehr als eine geben.
Der Grund für den Fehler befindet sich über der FEHLGESCHLAGEN-Zeile.