아래에 표시되는 오류를 수정하는 방법을 알려 주세요.
참고로, 주제에 목차(TOC)를 추가한 후에는 페이지를 새로고침해야 목차 링크가 작동합니다. 이런 동작이 정상적인가요?
1개의 좋아요
안녕하세요 @Yt.w, 보고해 주셔서 감사합니다. 말씀하신 문제를 재현해 보았으나 확인되지 않았습니다. 여전히 해당 동작을 확인하고 계신가요? 그렇다면 재현 단계를 좀 더 자세히 알려주시겠어요?
제 판단으로는 HTML을 다시 생성하기 위해 페이지를 새로고침하는 것은 의도된 동작입니다. 이를 방지하는 것이 가능할 수는 있지만, 그렇게 하려면 현재 컴포넌트가 작동하는 방식에 대한 변경이 필요합니다.
1개의 좋아요
안녕하세요, 이 동작이 여전히 관찰되며, 실제로는 현재 인스턴스를 설치한 직후에 발생했습니다. 저는 아무런 변경 사항을 적용하지 않았습니다.
제 다른 인스턴스에서는 이 문제가 발생하지 않아서 상당히 혼란스럽습니다.
UX 측면에서, TOC가 활성 상태로 유지되려면 페이지를 새로고침하지 않는 것이 더 낫다고 생각합니다.
1개의 좋아요
@Yt.w 이 오류가 발생할 때 브라우저 콘솔을 보여줄 수 있을까요? 오류도 펼쳐서 보여주세요.
멀티사이트 환경에서 호스팅 중인 세 사이트 중 하나에서 동일한 오류가 발생하고 있어, 해당 사이트의 설정 중 하나가 원인이 될 것으로 추정됩니다. 아직 어느 설정 때문인지는 파악하지 못했지만, 원인을 찾으면 다시 돌아와 게시물을 업데이트하겠습니다. 최신 tests-passed 릴리스에서도 같은 문제가 실제로 발생하고 있다는 점만 먼저 말씀드리고 싶었습니다.
콘솔에 표시되는 내용은 다음과 같으며, 좋은 의미든 나쁜 의미든 익숙한 내용들입니다 
1개의 좋아요
감사합니다. 정확한 재현 방법을 아직 찾지 못했는데, 멀티사이트 호스팅 사이트에서는 이 문제를 재현할 수 없습니다.
1개의 좋아요
이것이 적시되지 않은 정보(red herring)일 수도 있고 아닐 수도 있습니다. 아직 충분한 시간을 들여 조사하지는 못했지만, 해당 구성 요소를 삭제한 후 다시 설치하면 항상 다음 오류가 발생합니다:
구성 요소를 다시 설치할 때마다 다른 구성 요소 번호로 설치되기 때문에 필드 번호가 변경되는 것으로 추정됩니다. 계속해서 조사해 보겠지만, 다른 구성 요소에 대해 동일한 작업을 수행할 때는 이런 현상이 발생하지 않습니다.
현재 제 추측은, 제가 언젠가 이 사이트에서 일부 S3 변경 사항을 되돌린 것이 실패의 원인이 될 수 있다는 것입니다. @Yt.w 님, 혹시 당신의 설치 환경에서도 언젠가 S3를 사용하셨나요?
2개의 좋아요
좋습니다. 이제 에러를 없애고 재현하는 데 성공했습니다.
요약 (TL;DR)
- 이전에 정상적으로 작동했던 S3 설정으로 돌아가고 DiscoTOC 구성 요소를 삭제한 후 다시 설치하면, 에러 없이 구성 요소가 설치됩니다.
app.yml의 모든 S3 지시문을 주석 처리하여 S3를 비활성화하면, 구성 요소를 설치할 때 에러가 다시 발생하며, 업데이트 시에도 에러가 재발할 것으로 추정됩니다.DISCOURSE_USE_S3: false를 설정해도 Discourse가 S3 경로를 사용하는 것을 막지 못합니다. 이는 버그이거나, 이 설정이 제가 생각하는 것과 다른 기능을 하는 것 같습니다.
상세 설명
처음에 제가 한 일은 minio 설정을 다시 활성화하고, app.yml의 설정 옵션을 주석 해제한 후 앱을 재빌드하고 s3:upload_assets 태스크를 실행하는 것이었습니다. 사이트가 다시 올라간 후 구성 요소 섹션으로 이동했습니다. 이미 설치된 DiscoTOC 구성 요소는 여전히 에러를 표시했지만, 이를 삭제하고 다시 설치했을 때는 에러가 다시 나타나지 않았습니다. DiscoTOC 구성 요소 설치 과정에서 _sprite.svg_가 제 S3 서버에서 요청되었습니다.
문제를 재현하기 위해 시도하는 동안 흥미로운 문제를 겪었습니다. app.yml의 모든 S3 지시문을 활성화한 상태(즉, 주석 처리되지 않은 상태)로 두되 ``DISCOURSE_USE_S3: false```로 설정하면, minio가 실행 중이지 않으면 사이트 프론트엔드가 로드되지 않는 것 같습니다.
아마도 DISCOURSE_USE_S3: False는 모든 S3 접근을 비활성화하기 위한 것이 아닐 수 있습니다. 이름 때문에 그렇게 추정했지만, 분명히 그렇지 않습니다. minio 서비스를 다시 시작하고 프론트엔드를 새로고침하면 모든 것이 정상적으로 작동합니다. 이 상태에서는 에러를 재현하지 않고도 DiscoTOC 구성 요소를 제거하고 설치할 수 있습니다. 이는 적어도 잠재적으로 하나의 버그로 보입니다.
재현 가능한 에러로 이끈 세 번째 상태는 다음과 같습니다.
minio가 실행되지 않는 상태에서도 사이트가 다시 작동하도록 하기 위해, 설정에서 S3와 관련된 모든 항목을 주석 처리했습니다. 그런 다음 앱을 재빌드했고, 이제 minio가 실행되지 않아도 프론트엔드가 문제없이 로드됩니다. 그러나 DiscoTOC 구성 요소를 제거하고 다시 설치하면 에러가 다시 나타납니다. 이 상태에서 minio만 시작해도 재설치 시 에러가 다시 나타났습니다. app.yml 어디에도 S3 지시문이 설정되어 있지 않아, 백그라운드에서 S3에 접근을 시도하더라도 작동하는 설정 대신 기본값을 사용하여 시도하기 때문일 가능성이 높습니다. 그러나 posts:rebake를 실행한 후에도 일부 이미지가 여전히 S3에서 서빙되도록 시도하는 것 같습니다. (예: 1531a70abda0d81d1a4039b6f3fa38bea79ef0de_2_180x180.png/xl.meta)
2개의 좋아요
네, 문제가 발생했던 포럼은 S3(B2)를 사용 중이었으며, 문제가 없었던 포럼은 S3를 사용하지 않았습니다.
1개의 좋아요