이전에 Vbulletin을 사용해보신 적 있으신가요? Discourse에서 VBulletin의 어떤 기능이 아쉬우셨나요?
2개의 좋아요
2001년부터 2020년까지 vBulletin을 사용했으며, 현재도 vB 3.8.X 버전을 “읽기 전용” 참조 사이트로 유지하고 있습니다.
솔직히 vBulletin에서 그리워하는 점은 아무것도 없습니다. 오히려 vBulletin으로 이관한 후, 시스템 관리자와 웹 개발자 관점에서 Ruby on Rails의 MVC 모델이 vBulletin이 사용하던 LAMP 모델보다 훨씬 우수하다는 것을 알게 되었습니다.
사용자 경험 측면에서는 대부분의 사용자가 Discourse에 매우 만족하고 있지만, vBulletin 포럼 특유의 레거시/빈티지한 룩앤필을 좋아했던 몇몇 장기간 활동해 온 전문가들은 떠났습니다.
2021년에 기존 vB 참조 사이트를 Rails로 이식할 계획이 있었습니다. 즉, 기존 MySQL 데이터베이스 위에 Rails, Redis, Sidekiq, MySQL, jQuery, Bootstrap 기반의 참조 사이트를 구축하여 재설계할 예정이었으나, 2021년에는 재미있고 흥미로운 유료 Rails 클라이언트 작업에 너무 바빠서 올해 기존 사이트의 재설계는 어려울 것 같습니다.
Discourse를 설치하기 전에는 열성적인 PHP 프로그래머였지만, Discourse로 이관하고 Ruby와 Rails로 작업하게 된 후로는 PHP와 LAMP 웹 개발에 대해 더 이상 흥미를 느끼지 못합니다. vB에서 Discourse로 이관하고(수년간의 PHP 웹 개발 후 Rails를 학습하면서) Rails의 큰 팬이 되었습니다.
반복되는 말씀이지만, 우리의 vB 사이트와 관련해서는 vBulletin과 그들의 LAMP 아키텍처에 대해 "잘 됐다"고 말하고 싶고, Rails 위에 Discourse를 구축해 준 것에 대해 "감사합니다, Discourse!"라고 전하고 싶습니다.
이 정보가 도움이 되길 바랍니다. @MKDan
13개의 좋아요
2007년부터 2016년까지 이 플랫폼을 사용했으며, 전환 과정은 순조로웠고 Discourse에 대해 불만을 제기한 회원은 소수였습니다. 하지만 회원들이 Discourse와 그 기능 사용법에 익숙해지자, 다시 vBulletin으로 돌아가고 싶어 하지 않았습니다.
대부분의 회원들이 아쉬워했던 점은 포럼과 하위 포럼이 나열된 vBulletin의 홈페이지와 스레드 내 페이지네이션이었습니다. 시간이 지나면서 이러한 불만은 점차 줄어들었고, 이제 ‘클래식’ 포럼에서 온 신규 회원이 Discourse 기반 게시판에 가입할 때만 이런 이야기를 들을 수 있습니다.
이러한 점을 고려할 때, Discourse에 이미 없는 vBulletin의 기능을 떠올리기 어렵습니다. Discourse에서 vBulletin으로 돌아가는 것은 큰 퇴보가 될 것이라고 생각합니다.
11개의 좋아요
수년 동안 vBulletin 라이선스를 보유하고 있었고, Photopost도 함께 사용했습니다(그립네요).
저는 화를 내는 글을 올렸다가 라이선스 정책이 변경된 날, 그 포럼에서 영구 퇴거 처분을 받았습니다. 저 외에도 많은 사람들이 같은 처분을 받았죠.
제가 지금까지 받은 유일한 영구 퇴거입니다(이것을 명예로 여깁니다) 
.
이 사건 이후 Xenforo가 독립하게 되었습니다.
그 이후로 vBulletin은 한 번도 돌아보지 않았습니다.
갤러리 플러그인이 그립네요.
5개의 좋아요
Discourse는 Vbulletin보다 훨씬 더 좋아 보입니다. 하지만 단 하나, Discourse는 공유 호스팅에 설치할 수 없다는 점이 문제입니다.
3개의 좋아요
2021년에 왜 공유 호스팅을 사용해야 합니까?
Discourse는 오픈소스이며 월 $5 이하의 클라우드 서버에 설치할 수 있습니다.
특히 스태프/관리자 입장에서 더 좋고, 외관도 더 좋습니다.
6개의 좋아요
2008년부터 2018년까지 vBulletin을 사용했습니다. (그 전에는 disqus를, 그리고 그 이전에는 1996년부터 1999년까지 사용했던 다른 도구를 사용했는데, 이름이 기억나지 않습니다.)
vBulletin에서 사용했던 기능 중 Discourse에는 (정확히) 없는 것들이 있었는데, 바로 블로그, 갤러리, 그리고 그룹(vBulletin의 그룹은 Facebook 그룹과 유사했습니다)이었습니다. Discourse로 이전했을 때 처음에는 이 세 가지 기능이 모두 부족하게 느껴졌지만, 결국 대부분의 기능이 커뮤니티에 불필요한 혼란만 야기하고 토론에 대한 집중도를 떨어뜨린다는 것을 알게 되었습니다.
멤버들의 창작물을 위해 블로그를 사용했지만, 이를 포럼 주제로 대체했습니다.
그룹은 커뮤니티의 특정 측면에 관심 있는 팀들을 위해 사용했습니다. 하지만 우리는 이를 단계적으로 폐지하고 토론을 메인 포럼으로 옮겼습니다. 실제로 이렇게 하자 모든 주제에 대한 참여도와 인지도가 높아졌습니다.
갤러리의 경우도 마찬가지였습니다…
결론은 이렇습니다. 커뮤니티에 직접적인 가치를 제공하지 않으면서도 오히려 토론의 응집력을 해치는 불필요한 혼란만 초래했습니다.
아니요, 전혀 그리워하지 않을 겁니다!
8개의 좋아요
블로그와 갤러리가 모두 Discourse의 테마 컴포넌트를 통해 사용 가능하다는 점을 알아두면 도움이 될 수도 있고, 아닐 수도 있습니다.
2개의 좋아요
vBulletin과의 유일한 차이점은 블로그와 갤러리가 모두 사용자 범위(user scoped)에 속해 있었다는 것입니다. 즉, 각 사용자의 프로필과 연결되어 있었습니다.
물론 정말 원한다면 Discourse에서도 이를 구현할 수 있습니다. 조금 복잡한 카테고리 설정을 하거나, 정말そこまで 하려면 플러그인을 사용하는 방법이 있습니다…
5개의 좋아요
이것은 제가 10년 넘게 vBulletin 포럼을 이용해 온 경험과도 일치합니다. 10년 동안 vBulletin의 각 페이지에서 잠재적으로 클릭할 수 있는 수백 개의 것들, 화면 여기저기에 흩뿌려진 모든 링크들… 저는 그중에서도 고작 10개 정도의 링크만 클릭해 봤습니다. 정말로요. 정말! 10년 동안 사용하면서요!
정말 미친 짓입니다 
8개의 좋아요
Discourse 사용을 고려하고 계신다면, 그냥 사용하세요! Discourse는 현재 최고의 포럼 플랫폼이며, 앞으로도 그럴 것입니다. 이곳의 개발 속도에 항상 놀라움을 느끼며, 팀은 매우 뛰어난 재능을 가진 사람들로 구성되어 있습니다(가장 경험이 많은 Ruby 개발자 중 한 명이라고 할 수 있는 Sam Saffron 등이 포함됩니다).
vBulletin에 없는 기능에 대해 이야기하자면, 이는 두 플랫폼이 서로 다르기 때문에 좋은 접근 방식은 아닐 수 있지만, 사이트가 주로 포럼으로 구성되어 있다면 사용자들이 Discourse에서 훨씬 더 만족할 것이라고 확신합니다.
vBulletin에서 아쉬운 유일한 ‘포럼’ 유형 기능은 주제 작성자와 관리자/모더레이터 팀만 스레드를 볼 수 있는 섹션을 만들 수 있는 능력입니다. 우리는 포럼 피드백, 스태프에게 문의하기 등을 위해 이러한 섹션을 사용하는데, 이는 나중에 분류하거나 검토하기가 더 쉬운 PM(개인 메시지)보다 이 유형의 용도에 더 적합합니다(한번 확인된 PM은 잊히기 쉽고 분류나 검토가 어렵습니다).
하지만 Discourse에서 보고 싶은 것들도 많습니다. 그 중 하나는 블로그, 기사, 뉴스 등 다른 여러 섹션을 구동할 수 있도록 하는 것입니다. Discourse의 댓글/토론 시스템은 아마도 그 가장 큰 강점 중 하나일 것입니다 - Discourse의 댓글 기능과 모든 것이 포럼의 사용자 프로필과 완벽하게 통합된 WordPress 스타일 블로그를 상상해 보세요. 만약 팀이 이 부분을 검토한다면 Discourse가 WordPress(그리고 다른 CMS)를 대체할 수 있다고 진심으로 생각합니다. 또한 그렇게 어렵지 않을 것입니다 - vBulletin에서는 여러 다른 섹션을 구동하기 위해 이를 사용했는데, 필요한 것은 1) 해당 섹션의 최신 항목을 모두 가져올 수 있는 각 섹션별 커스텀 인덱스 페이지, 그리고 b) 첫 번째 게시물에는 하나의 스타일을, 그 이후의 게시물에는 다른 스타일을 설정할 수 있는 능력(vBulletin에서는 간단한 조건문으로 이걸 관리했습니다)이었습니다. 이렇게 하면 메인 기사와 댓글이 서로 다른 모습으로 보일 수 있습니다.
또한 제대로 된 블록(Block) 기능도 보고 싶습니다. 이는 모더레이터들의 업무를 훨씬 쉽게 만들어 줄 것입니다.
이 두 가지 모두 이전에 포럼에서 논의된 적이 있지만, 추가될 가능성은 낮습니다(개인적으로는 이것이 큰 아쉬움이며, 팀이 언젠가 이 부분을 재검토하길 바랍니다).
5개의 좋아요
이제 사용자별로 Mute와 Ignore 기능을 모두 사용할 수 있다는 것을 알고 계시죠?
2개의 좋아요
저도 언젠가™ 이런 기능을 보고 싶고, 토픽 작성자가 해당 토픽 내에서 제한적인 모더레이션 권한을 가질 수 있는 카테고리(최소한, 다른 사용자의 글 삭제 + 자신의 글 즉시 삭제 + 자기 편집 시간 제한 없음)도 함께 보고 싶습니다.
이것이 가능하다고 꽤 확신하는데, vB의 미친 권한 설정 다이얼로그 어딘가에 숨겨져 있을 겁니다.
1개의 좋아요
하지만 이것은 사용자가 특정 사람의 게시물에 응답하거나 답글을 달 수 있는 것을 막지는 못하나요?
이전에 이 문제에 대해 논의한 적이 있는데, 기억이 맞다면 그 당시 이 아이디어에 대해 긍정적이지 않으셨던 것 같습니다. 이번에는 입장을 재고해 주시길 바랍니다.
https://meta.discourse.org/t/ability-to-ignore-a-user/110254/75?u=astonj
이 부분은 꽤 설득력이 있어야 받아들이겠어요. 이 기괴한 권한 규칙은 vBulletin이 우연히 세상에 강요한 것 같고, 그 결과로 우리 모두가 고통받고 있다고 느껴집니다. 기본적으로 "오, 우리 포럼을 티켓팅 헬프데스크 솔루션인 척하는 One Weird Trick™이 있네, 영업팀에게 그렇게 팔라고 말해!"라는 식이었거든요.
(티켓팅 헬프데스크 시스템이 필요하면 하나를 쓰세요! 그리고 그 위에 "아, 권한을 토픽별로 설정하면 어떨까?"라는 건… 거대하고 불필요한 작업입니다)
우리는 이미 이에 대한 기본적인 형태를 가지고 있습니다. 예를 들어 토픽 소유자는 자신의 토픽에 무제한으로 답변할 수 있습니다.
2개의 좋아요
저희는 현재 소프트웨어에서 이 기능을 상당히 광범위하게 사용하고 있으며, 이 부분에서는 당신의 의견에 더 동의하는 편입니다. 사용자가 "지원"을 위해 생성하는 대부분의 스레드는 실제로는 자신의 게시물이 삭제되었다거나 하는 이유로 스태프에게 불만을 토로하기 위한 수단일 뿐입니다. 물론 다른 누군가의 괴롭힘 이력을 신고하거나, 실제로 논의가 필요한 기타 주제와 같이 정당한 용도도 있습니다.
때로는 섬세한 상호작용이 필요하지만, 티켓 시스템을 억지로 붙이는 것은 지나치게 과한 조치입니다. Discourse로 이주할 때쯤에는 이런 것들은 개인 메시지로 넘어가야 할 것 같은데, 모든 스태프를 해당 주제에 추가해야 모든 사람이 동일한 정보를 공유할 수 있기 때문에 다소 번거로울 것입니다.
3개의 좋아요
이러한 시스템의 훌륭한 활용 사례입니다. 그렇지 않으면 사람들은 더 공개적인 ‘포럼 피드백’ 섹션을 사용하는데, 대부분은 단순히 트러블을 일으키기 위해서입니다. ‘스태프에게 문의하기’ 섹션으로 전환한 후, 그런 종류의 무의미한 행위가 약 90% 감소했습니다.
1개의 좋아요
그룹 페이지에 메시지 버튼과 사용자가 관리할 수 있는 별도의 받은 편지함이 있는 것을 확인했습니다. 이 방식이 내 스레드만 보는 권한과 비교했을 때 어떤 느낌인지 아직 확신이 서지 않지만, 이 방식도 잘 작동할 수 있을 것 같습니다.
또한, 이 유형의 설정은 Staff Contact를 제외하고 ‘개인 워크숍’ 같은 상황에서 사용하기도 합니다. 사용자들이 게시물을 작성하고 포맷을 테스트하거나, 나중에 공개적으로 게시할 때까지 서서히 내용을 쌓아가고 편집하는 용도로 콘텐츠를 저장하는 데 활용할 수 있습니다.
1개의 좋아요
네, 토론이 비공개로 진행되어야 한다면 @moderators 그룹 수신함을 사용해야 합니다.
2개의 좋아요