לאחר שננשכתי על ידי בעיית “כישלון בניית תוסף” בשלב מוקדם של אירוח Discourse עצמי, אני יכול להעריך את הרצון לארוז לתוך הליבה גרסאות ידועות וטובות. ופוטנציאלית להציע מבחר עשיר יותר של תכונות.
ארגון ממוקד לקוח יכול היה לערוך סקר על כיוון התוספים בליבה, או לפחות על התזמון. אולי פספסתי את זה. כספק כלי IT ללקוחותיי (כלומר, משתמשי קצה) המנסים לבצע עבודה אמיתית עם IT, ראיתי מוצרים רבים שעברו שינויים למורכבות יתר ולהחלפה בסופו של דבר. עכשיו יהיו לנו מארחים עצמיים ש"יסירו -rf" תוספים שהם לא צריכים. אני מבין את זה ואולי אצטרף למועדון הזה. מניסיוני, קוד נוסף מגדיל את מורכבות האינטגרציה, את הסיכון לטעויות תצורה, ואת שטח התקיפה. אבל במוקדם או במאוחר הסרת משהו שמפתח האפליקציה מניח שיהיה שם, גם תשבור משהו.
הייתי מעדיף הרבה יותר שהמאמצים של ג’דיי Discourse יופנו לעבודה על שיטה חזקה, מתוחזקת וסקריפטית להפעלת אחסון ענן לתמונות, כולל אינטגרציית CDN. אינטגרציית דוא"ל SMTP היא טריוויאלית בהשוואה, וזה נשבר עם שינויים ב-MailGun ואחרים שגרמו לאתרים מארחים עצמיים צער.
Indeed, I would strongly recommend against using rm -rf on these plugins. As you say, there are risks around unexpected inter-dependencies in future. But also, you’ll be creating a diff in the core git repository, which means UI updates via docker_manager are almost certain to fail.
Of course, leaving these plugins in their default ‘disabled’ state is totally supported, and will ensure they don’t have any measurable performance impact.
עבור מארחים עצמיים או עבור אלה כמוני המספקים שירותי אירוח ללקוחות, הנה grep פשוט שיפרט אם אחד מהתוספים החדשים שצורפו כבר נמצא ב-containers/app.yml שלכם
Might consider changing it to reference containers.*.yml so that it also helps out anyone who has done a standard two-container install where they would instead by in web-only? You really don’t want them in any of your container definitions, after all.
@david would you consider adding that to the top post and maintaining it once you integrate cakeday?
Thank ChatGPT which crafted it exactly correctly in one go from this prompt:
Please scrape the GitHub urls of each of the plugins mentioned in this post https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574#p-1810533-affected-plugins-3
Compile them into a list and create a unix command which will tell me if any of these plugins are already mentioned in a ‘git clone’ in that Discourse’s containers/app.yml
On the surface, to me, this does sound like a reasonable thing to consider doing at some point – having a more declarative way to define which plugins are loaded or not at boot time, even if the source is still sitting there on disk.
That said, I don’t know what the feasibility or lift of doing that would be.
It’s certainly possible. But it adds complexity - yet another thing to support/maintain. And it would only be useful in single-tenant environments (i.e. not in shared hosting environments, where different tenants want different plugins).
If anything, I think it would be more beneficial to spend time improving the UX & performance of ‘disabled’ plugins (which we have already started doing since this big merge into core).
אוף, זו הייתה עדכון קשה. זיהוי הבעיה בבלגן של יומן הבנייה מחדש אינו טריוויאלי כלל מלכתחילה. מצאתי את זה, התעלמתי מתוסף נוסף להסרה מהתצורה שלנו פעמיים, ולכן ניסיון הבנייה מחדש השלישי עבר סוף סוף את החלק הזה. זה היה עוזר באמת לבדוק ולהתריע מלכתחילה שהתצורה צריכה להיות מותאמת. discourse-doctor בודק (פשוט מדי, אבל ניתן לקחת אותו כהתחלה) תוספים בתצורה, כך שניתן להשתמש בו כבסיס. כנראה מאוחר מדי עכשיו 3 שבועות מאוחר יותר, לא משנה מה…
אבל זה לא היה הכל, נתקלנו גם בשגיאות db:migrate. ניסינו שוב פעמיים, ואז הרצנו את discourse-doctor, שגם הרץ את הבנייה מחדש, ובאופן מוזר הצליח. בדקתי את הקוד שלו, והוא לא עושה שום דבר, וקורא לבנייה מחדש בדיוק באותה דרך שאנחנו עושים. לכן נראה ש-db:migrate הצליח בניסיון השלישי מסיבה כלשהי? קראתי את השרשור שהמספר הגדול של תוספים שהוספו מוסיף תלויות, אשר עלולות להתנגש/להיות ישנות יותר ממה שהיה בשימוש קודם. למרבה המזל לא היינו צריכים להוסיף שלב ידני של הסרת תוסף, התאמת תלויות או שינוי מסד נתונים, כמו שאחרים נראו שנדרשו. האם זה צפוי איכשהו שהרצת db:migrate מספר פעמים תצליח סוף סוף? אני יכול רק לקוות ששום דבר לא שבור…
It was installed earlier, we just omitted it from the UI with the rest of the bundled plugins from before. Our UI was improved to properly surface everything that exists. (we had a bunch of omissions including Chat which was hidden via CSS)
I have already observed internal dev team velocity increase in the very short time this has been in place. It is leading to a more stable product, something I am very happy about.
No plans to back track here. You need to adjust to the new world.
IMO if something breaks because a plugin isn’t installed, then that itself is a bug. Core should not depend on plugins. Plugins themselves should clearly list their requirements on their respective pages.
But yes, this is going to make the self-hosted version even less stable going forward, since it’ll be the self-hosters stumbling through these issues. Between this and the forked thread, I really don’t get the impression that stability of self-hosters is a high priority for the team.
We hadn’t thought about that in advance, so some approvals might have gone missing. But we managed to transfer a good chunk of them from the plugin projects on Crowdin to core. We’ll do better next time since we now have the tools to transfer approvals between projects.
No, we didn’t check beforehand, but I checked afterward. None of the plugins had unanswered comments on Crowdin. We have an internal tool that stores all comments that are posted on our Crowdin plugins. We could even use it to post missing comments on Crowdin again, e.g. when Crowdin deletes comments because the source string was updated. It just hasn’t been a priority to implement this.
I agree with the sentiment. Imho the real disconnect is keeping them listed as plugins.
Once merged it should be moved to something branded like “Core Features” as plugins are seen as optional components that can be installed. Vs part of the main program. So it is a misnomer imho to keep them listed as plugins when the intent is not be uninstalled.
Similar to TC that were merged in core like “personal bubbles” is not listed in Theme Components. Granted in that particular case you cannot disable the former TC. If you wanted to go back to what it was before you needed to create a TC to undo the changesm
Definitely agree with additional filtering options. To also have one for disabled plugins as well.
However after more thought and reading more posts. If the plugins are merged with core. They really maybe should no longer be called plugins and not listed in Plugins. But maybe something like Core Features or Optional Features. Since these are no longer really meant to be able to uninstall them.
There is no reason properly engineered forum software should require advertising code to run.
If Discourse decides to bake in anti-features, the only thing it’s going to force people to do is either fork Discourse or migrate to something else. Those of us that do not like big tech / ad stuff feel very strongly about this. Discourse will NOT force it on us, no matter how hard it is pushed. (Ubuntu tried this on us and now my highest starred repo is something that removes the ads ;))
Not sure I follow. If by advertising code you mean plugins that are merged into the core product vs remaining optional add-ons/installs. If we go back you will find a variety of “Advertising code” was merged in core.
I can see from the DeV team perspective that many of their plugins may have started as plugins to allow more flexible testing before making it integrated in the core program.
I can appreciate like any software there is often features ppl might not use and choose to disable it and up to finding ways to uninstall features.
While I will admit there are a lot of recent merged plugins that I likely would not use. But having a simple disable and filtering them out is something good for all.
I understand that in part as stated by the team the intent is to make things easier with add-ons for self hosted.
Now imho the admin interface should be more customizable like it once was. As this can also help with ppl migrating from another platform by being able to load an admin there that is similar layout as the platform they are coming from. Much like how Linux does this with some mimicking other OSes. But that is another topic.
I can appreciate the feeling that discourse might be starting to head towards bloatware. Reactors demonstrated how much leaner Windows NT could be.
