앞으로 몇 주 동안, 인기 있는 Discourse 플러그인 중 일부를 코어 저장소로 이동할 예정입니다. 이는 Discourse가 기본적으로 더 많은 플러그인을 포함하게 되며, 모든 플러그인의 테스트 및 최신 상태를 유지하는 것이 더 쉬워진다는 것을 의미합니다.
이 모든 플러그인은 기본적으로 비활성화 상태로 유지되므로, 기존 커뮤니티에는 눈에 띄는 영향을 미치지 않습니다. discourse.org와 같은 관리형 호스팅 서비스를 사용 중이라면 아무 조치도 필요하지 않습니다.
자체 호스팅 커뮤니티
Discourse를 자체 호스팅 중이고 이미 이 플러그인 중 하나를 사용 중이라면, 다음 재빌드 전에 app.yml 파일에서 관련 줄을 제거하도록 안내받게 됩니다.
개발 환경
이미 로컬에 플러그인 중 하나가 설치되어 있고 최신 버전의 Discourse 코어를 가져온 경우, 다음 두 가지 중 하나가 발생합니다.
플러그인에 심볼릭 링크를 사용하는 경우, git pull 실행 중 오류가 발생합니다. 문제를 해결하려면 심볼릭 링크를 삭제한 후 git pull을 다시 실행하십시오.
플러그인을 직접 클론한 경우, 코어의 git pull은 성공하지만 중첩된 git 저장소로 인해 예상치 못한 'unstaged changes’가 발생할 수 있습니다. 가장 좋은 진행 방법은 영향을 받은 디렉토리를 삭제한 후 main에서 restore하는 것입니다. 예를 들어:
Thanks. With my poor knowledge of development and programming, I would still like to ask you a question. Can these plugins, which are originally components intended to be added to a basic installation may one day lose their plug-in character and become a complete part of a basic installation, without being called plug-ins at all?
They might do, yes. In particular, the authentication plugins (e.g. apple-auth) are quite likely to be absorbed into core eventually, just like our other builtin authentication methods (e.g. Google, Facebook, etc.).
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.
I’m wondering, would having all these plugins bundled in core bloat forums? As in, there’ll probably be a few plugins that admins don’t want on their forum (e.g. Discourse AI), but have no choice but to have it added. It can be disabled, of course, but I’m wondering if the added files and stuff will slow down forums?
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.
Is there a reason why you are doing all this at once shortly before the release? For translators who do this in their spare time, 3,000 additional strings within two weeks is a lot. And even in languages where the plugins were previously translated, all 3,000 texts have to be proofread again. Every now and then, 300 would probably be more manageable than 1,500 each week.
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
