Over the next few weeks, we’ll be moving a number of popular Discourse plugins into the core repository. That means that Discourse will come with a larger number of plugins by default, and it’ll be easier for us to keep them all tested & up-to-date.
All these plugins will remain disabled by default, so this won’t have any visible impact on existing communities. If you use a managed hosting service like discourse.org, you don’t need to do anything.
Self-hosted communities
If you self-host Discourse, and are already using one of these plugins, you’ll be prompted to remove the relevant line from your app.yml file before your next rebuild.
Development Environment
If you already have one of the plugins installed locally, and then pull the latest version of Discourse core, one of two things will happen.
If you use symlinks for your plugins, then you’ll get an error during git pull. To resolve the issue, delete the symlink, then run git pull again
If you clone plugins directly, then the git pull of core will succeed, but you will have some surprising ‘unstaged changes’ caused by the nested git repositories. The best way to proceed is to delete the affected directory, and then restore it from main. For example:
תודה. עם הידע הדל שלי בפיתוח ותכנות, עדיין ארצה לשאול אותך שאלה. האם התוספים הללו, שהם במקור רכיבים המיועדים להתווסף להתקנה בסיסית, יכולים יום אחד לאבד את אופי התוסף שלהם ולהפוך לחלק שלם מהתקנה בסיסית, מבלי להיקרא כלל תוספים?
הם עשויים לעשות זאת, כן. בפרט, תוספי האימות (למשל, apple-auth) צפויים להיבלע בליבה, בדיוק כמו שיטות האימות המובנות האחרות שלנו (למשל, Google, Facebook וכו’).
If I recall correctly from my experience, you will only be able to update docker at first. Once you’ve updated docker, you will be shown a message in the update UI explaining that you have to update via the command line, and how to do it.
Then when you update on the ocmmand line you’ll see the HINT for each plugin you need to remove from app.yml as explained in the first post above.
This is a good update but was this really necessary? Giving a rebuild failure seems a little bit harsh to me.. a UI warning or automated update (or just ignoring them entirely) would have been nicer than putting a gun to my head and saying “remove these now”
This caught me out last week when I tried to update via cmd line and it failed (reactions plugin).
It caught me out again when my cmd line update failed again this morning (data explorer plugin).
I would very much welcome a warning on the cmd line before the update process starts, and then inevitably fails.
Twice in two weeks now my updates have failed and this has meant my Discourse is offline for the duration of time it takes me to debug the issue, edit configs, try again, etc - all while in a mild state of panic because everything is broken.
אני תוהה, האם ריכוז כל התוספים האלה בליבה ינפח את הפורומים? כלומר, בטח יהיו כמה תוספים שמומחים לא ירצו בפורום שלהם (למשל, Discourse AI), אבל לא תהיה להם ברירה אלא להוסיף אותם. ניתן כמובן להשבית אותם, אבל אני תוהה אם הקבצים הנוספים והדברים האלה יאטו את הפורומים?
On the client side, Discourse does not serve any javascript assets for disabled plugins, so there won’t be any impact there.
On the server side, for properly implemented plugins (which all of these are), customizations from plugins are bypassed when they’re disabled. So yes technically there might be a slight overhead to check for enabled/disabled state, but it should be miniscule.
The plugins we’re merging here are the ones which we run on every single instance of Discourse on our discourse.org hosting. So they’re all very well-tested at scale.
האם יש סיבה שאתם עושים את כל זה בבת אחת זמן קצר לפני השחרור? עבור מתרגמים שעושים זאת בזמנם הפנוי, 3,000 מחרוזות נוספות תוך שבועיים זה הרבה. וגם בשפות שבהן התוספים תורגמו בעבר, יש לבדוק שוב את כל 3,000 הטקסטים. מדי פעם, 300 יהיו כנראה ניתנים יותר לניהול מאשר 3,000.
For self-hosted communities already running one or more of these plugins, will the plugins lose config data when removed from app.yml and folded into core?
I’ve got the AI plugin set up exactly how I want it; if I need to reconfigure it (or at least write down the config options so I can re-add them), it’d be nice to know now.
We’ve been trying to make this as smooth as possible for translators by making use of the translation memory in crowdin, so that translations don’t have to be re-made from scratch. But still, I agree, there are a lot to proofread.
I wonder if there’s more we can automate here, e.g. maybe we can “auto approve” any strings from these plugins, instead of requiring a proofread
