세 번째_party 커스터마이징을 사용하다가 문제가 발생하면, 대부분의 사용자가 먼저 안전 모드(Safe Mode)를 시도하는 경향이 있습니다. 이는 당연한 반응입니다. 문제가 어디서 비롯된지 알 수 없으니까요.
하지만 안전 모드는 자바스크립트만 비활성화할 뿐입니다. 서버 측 코드가 포함된 경우, 즉각적인 해결책은 보통 app.yml 파일의 모든 플러그인을 주석 처리하는 것입니다. 이 방법은 유효하지만, 재빌드(rebuild)가 필요하고 상대적으로 '기술적’인 작업입니다. 비기술적인 사용자에게 app.yml 파일에서 내용을 주석 처리하는 것은 결코 가볍게 여길 수 있는 작업이 아닙니다.
안전 모드에 서버 측 플러그인 비활성화 기능을 추가하는 PR의 실현 가능성에 대해 고민하고 있습니다. 안전 모드 컨트롤러에 다음과 같은 코드를 추가하는 방안을 고려 중입니다.
find_opts = {
include_official: params["only_official"] != 'true',
include_unofficial: params["no_plugins"] == "true"
}
Discourse.find_plugins(find_opts).each do |plugin|
if plugin.enabled_site_setting.present?
SiteSetting.set(plugin.enabled_site_setting, false)
end
end
물론 사용자가 사이트 설정을 통해 직접 플러그인을 끄는 동일한 효과를 얻을 수 있습니다. 하지만 실제로 이렇게 하는 사용자는 매우 드뭅니다.
핵심은 비기술적 사이트 관리자가 사이트가 깨졌을 때 작동하도록 고치는 방법을 찾는다는 점이라고 생각합니다. "안전 모드"는 그런 역할을 한다고 인식되는 경우가 많습니다(정당한 이유든 아니든). 이를 위한 방법 중 하나는 추가적인 관리자용 안전 모드 제어를 제공하는 것입니다.
/admin/plugins 경로에 모든 플러그인을 동일한 방식으로 자동으로 비활성화하는 큰 버튼을 추가할 수 있습니다. 하지만 그렇게 하면 동일한 효과를 낼 수 있을지 의문이 듭니다. 아마도 그럴 수 있겠죠.
현재 Discourse 플러그인 아키텍처 내에서 충분히 구현 가능하기 때문에 이 아이디어에 끌립니다.
다만, 서버 측 플러그인 API로 감싸진 코드에서 상당한 수의 오류가 발생한다는 점을 지적하고 싶습니다. 이 기능(이라고 생각하는데)이 그런 오류들을 처리해 줄 수 있을 것 같습니다.
현재 ‘안전 모드’(또는 유사한 기능)도 깨진 문제를 완전히 해결하는 방안은 아닙니다. 플러그인을 자동으로 비활성화하는 기능을 추가하면 이 해결책이 조금 더 좋아질 것입니다. 이를 통해 전체 재시작 또는 설정 변경이 필요한 경우가 줄어들고, 비기술적인 사이트 관리자가 보는 관점에도 더 부합하게 됩니다.
결국 저는 비교적 쉬운 단계적 조치를 찾고 있는 것입니다. 아마도 도커 관리자 변경도 기술적 관점에서만큼은 똑같이 간단할 수 있습니다.
네, 가능하다면 언젠가는 관리자 설정에 컨테이너 재빌드 없이 작동하는 “모든 플러그인 비활성화” 단일 불리언 옵션이 있으면 정말 좋겠습니다. 다만 저는 Discourse 개발자가 아니라(node.js, vuejs 앱 개발 경력 1년뿐) 직감적으로 이 변경이 쉽지 않고 아키텍처에 매우 큰 변화가 될 것 같다는 생각이 듭니다.
우리의 기존 LAMP 포럼에는 이 기능이 있었고, 플러그인 관련 오류를 빠르게 포착하기 위해 이 불리언 옵션을 사용한 횟수를 셀 수 없을 정도였습니다. 하지만 소프트웨어 아키텍처가 너무 달라 비교하는 것조차 무의미합니다.
개인적으로는 Discourse 팀이 무언가를 내놓을 것이라고 확신합니다. 많은 사용자가 플러그인에 의존하고 있으며, 시간이 지남에 따라 더 많은 문제(용어들)가 생길 것입니다.