Sobald Sie aktualisieren, werden die Deprecations zu Fehlern, wie Sie sagten
Ja, diese können über die injizierten Eigenschaften von Komponenten abgerufen werden, oder durch Importieren der Site- und User-Module aus discourse/models/user und discourse/models/site.
Für mein Plugin, das ich entwickle und ./bin/ember-cli ausführe, muss ich mir keine Sorgen machen, da ich ember-cli verwende.
Meine Sorge gilt jedoch den Dutzenden oder Hunderten von Leuten, die dies erst erfahren werden, wenn es zu spät ist. Jemand, der kein JavaScript von CSS oder ein Plugin von einer Theme-Komponente unterscheiden kann, muss sich keine Sorgen machen, es sei denn, er hat JavaScript in einer Theme-Komponente.
Ich hätte gerne einen einfachen Test, damit sie wissen, ob sie sich irgendwie Sorgen machen müssen. Für diese Leute werde ich empfehlen, einen neuen Server hochzufahren, ihre Datenbank wiederherzustellen und zu sehen, ob etwas explodiert. Richtig?
Oder sollten sie einfach EMBER_CLI_PROD_ASSETS: 1 aktivieren, einen Rebuild durchführen und wenn es explodiert, es wieder ausschalten und dann einen neuen Server hochfahren, um es zu beheben.
. . . Es sei denn, Sie haben das letzte Jahr damit verbracht, ein Tool zu entwickeln, das es „einfach“ macht, neue Server zu starten?
Was also mit denen passiert, die dem keine Beachtung schenken, ist, dass es kaputt geht, wenn das Ember-by-default-Fenster eintritt, und dann können sie diese Umgebungsvariable für ein oder zwei weitere Monate (und wahrscheinlich zur Behebung) deaktivieren, bevor dies nicht mehr funktioniert.
Ich habe ein Backup auf einer neuen Website wiederhergestellt, auf der das Kanban-Theme aktiviert ist, und es treten Fehler auf (ich habe dies im Kanban-Thema gemeldet). Ich habe versucht, Folgendes festzulegen:
EMBER_CLI_PROD_ASSETS: 0
und die Neuerstellungen sagen immer noch:
Warum Sie es regelmäßig tun sollten:
https://github.com/browserslist/browserslist#browsers-data-updating
was ich (glaube ich) von ember-cli wiedererkenne. Gibt es eine Möglichkeit, dies auf neuen Websites zu deaktivieren?
Wenn ich eine alte Website neu erstelle, erhält sie dann das neue Basisimage und kann ember-cli nicht deaktivieren?
Die Prüfung im Code scheint unverändert zu sein, aber ich bin nicht sehr vertraut mit Ruby. Verwendet eine boolesche Bedingung mit ENV['EMBER_CLI_PROD_ASSETS'] den Wert dieses Schlüssels oder ist sie wahr, wenn dieser Schlüssel existiert?
Wenn Letzteres der Fall ist, könnte die Antwort darin bestehen, EMBER_CLI_PROD_ASSETS aus der yml zu entfernen, anstatt ihn auf 0 zu setzen.
Keines meiner Probleme hatte mit ember-cli zu tun, sondern mit meiner eigenen Fehlkonfiguration, da dies eine 2-Container-Installation war und web_only.yml nicht aktualisiert wurde, als standalone.yml es wurde. Hier ist ein PR:
Ember CLI ist jetzt der Standard für alle Installationen von Discourse. Wenn Sie das nächste Mal ein Update durchführen (entweder über die Benutzeroberfläche /admin/upgrade oder über ./launcher rebuild app), werden Sie automatisch auf Ember CLI umgestellt.
Wir betreiben Ember CLI jetzt auf dem Großteil unseres Managed Hostings, daher erwarten wir keine größeren Probleme. Wenn Ihnen jedoch etwas auffällt, erstellen Sie bitte ein Thema hier auf Meta und wir werden es untersuchen.
Ich habe gestern eine Website neu erstellt, die aufgrund von Ember CLI fehlgeschlagen ist, und sie behoben, indem ich EMBER_CLI_PROD_ASSETS=1 entfernt habe.
Zu einem frühen Zeitpunkt habe ich versucht, Ember CLI zu deaktivieren, indem ich EMBER_CLI_PROD_ASSETS=0 gesetzt habe, und ich bin ziemlich sicher, dass es Ember_cli immer noch enthielt und mir jemand sagte, dass man es nicht durch Setzen auf 0 deaktivieren könne (was keinen Sinn ergab, aber wahr zu sein schien).
Dies ist für Self-Hoster, die alte Themes haben und nie die JavaScript-Konsole überprüfen, etwas schwierig.
Das war richtig, aber ich habe die Logik mit diesem letzten Commit korrigiert, sodass =0 wie erwartet funktioniert. Dennoch beabsichtigen wir, die ‘Legacy’-Umgebung in wenigen Wochen komplett zu entfernen. Verwenden Sie daher =0 nur auf äußerst kurzfristiger Basis.
Wir haben Abwärtskompatibilität für die häufigsten Fehler hinzugefügt, die wir bei unserem Hosting gesehen haben. Zum Beispiel fügte dieser Commit vor ein paar Wochen Abwärtskompatibilität für Discourse.User und Discourse.SiteSettings hinzu. Dieser Commit behob einige Probleme bei Themes mit nicht standardmäßigen Initialisierungsprozessen.
Wir möchten diese Einführung so reibungslos wie möglich gestalten. Wenn Sie in der letzten Woche oder so auf Fehler gestoßen sind, teilen Sie uns bitte den genauen Fehler und den Code, der ihn verursacht hat, mit.
Oh. Hurra. Das ergibt Sinn. (Es funktioniert so, wie ich es mir die ganze Zeit vorgestellt habe. Und ich bin nicht verrückt, weil ich mich daran erinnere, dass mir gesagt wurde, dass es nicht so funktioniert, wie ich es mir vorgestellt habe. Das sind großartige Dinge!).
Das finde ich wirklich schwer herauszufinden (wahrscheinlich aufgrund von Unwissenheit). Wenn ich auf das Ding klicke, von dem ich denke, dass es mir zeigen sollte, was den Fehler verursacht, bekomme ich den Code, der anscheinend der Code ist, der die Veralterung testet, nicht den Code, der sie aufweist. Ich werde mich bemühen, bald einige Beispiele zu senden.
Wenn du Hilfe beim Herausfinden brauchst, wäre ein #support-Thema mit einem Screenshot des Fehlers ein guter Ausgangspunkt – dann können wir von dort aus bei der Fehlersuche helfen. Wahrscheinlich hat jemand anderes einen ähnlichen Fehler gesehen und erkennt die Symptome.
Und nun zum letzten Schritt dieser Saga: Das Legacy-Build-System ist jetzt deaktiviert. Alle Discourse-Installationen kompilieren Assets mit Ember CLI.
Diese Änderung betrifft nur Personen, die EMBER_CLI_PROD_ASSETS=0 absichtlich in ihrer Konfiguration gesetzt hatten. In diesem Fall wird während des Builds eine Warnung ausgegeben und Ember CLI wird verwendet.