Q: 왜 WriteFreely ` ` 숏코드가 이메일 구독 폼 대신 숨겨진 빈 div를 렌더링하나요?

이것은 WriteFreely v0.16.0의 알려진 버그입니다: Markdown 렌더러가 ` ` 숏코드가 생성한 ` ` 요소를 제거하기 때문에, 게시된 글에는 화면 밖에 위치한 자리표시자 ` `만 표시됩니다. 이 수정 사항은 PR #1646에 병합되었습니다. 이 문제를 해결하려면 자체 호스팅 인스턴스를 v0.16.0 이후의 릴리스로 업그레이드하세요(또는 PR #1646이 포함된 커밋에서 소스로부터 직접 빌드하세요). 업그레이드 후에는 숏코드를 글 본문에서 사용하든 글 서명으로 사용하든 이메일 구독 폼이 올바르게 렌더링됩니다.

Question 1

WriteFreely가 왜 'bcrypt: password length exceeds 72 bytes' 오류를 표시하나요?

Accepted Answer

이는 bcrypt 해싱 알고리즘의 알려진 제한 사항으로, 72바이트보다 긴 비밀번호를 처리할 수 없습니다. 수정(PR #1664)에서는 이 오류를 방지하기 위해 비밀번호 필드에 maxlength 제약 조건을 추가합니다. 임시 해결 방법으로 73자 미만의 비밀번호를 사용하세요. 버전 0.16.0을 사용 중인 경우, 업데이트가 릴리스될 때까지 비밀번호를 줄여야 합니다.

Question 2

왜 WriteFreely `` 숏코드가 이메일 구독 폼 대신 숨겨진 빈 div를 렌더링하나요?

Accepted Answer

이것은 WriteFreely v0.16.0의 알려진 버그입니다: Markdown 렌더러가 `` 숏코드가 생성한 `

Question 3

블로그 게시물 서명에 이모지를 저장할 때 발생하는 WriteFreely 500 오류는 어떻게 해결하나요?

Accepted Answer

이 오류는 MySQL/MariaDB가 `collections.post_signature`를 `utf8mb3`으로 생성했기 때문에 발생하며, `utf8mb3`는 4바이트 이모지를 저장할 수 없습니다. issue #1572의 수정이 포함된 릴리스가 제공되면 WriteFreely를 업그레이드하세요. 즉각적인 해결 방법으로, 데이터베이스를 백업하고 해당 열을 `utf8mb4`로 변환하세요:

```sql
ALTER DATABASE writefreelydb CHARACTER SET utf8mb4;

ALTER TABLE collections
  MODIFY post_signature VARCHAR(400)
  CHARACTER SET utf8mb4
  NOT NULL DEFAULT '';
```

열이 다른 타입을 사용하는 경우, 먼저 다음 명령으로 확인하세요:

```sql
SHOW FULL COLUMNS FROM collections LIKE 'post_signature';
```

`VARCHAR(400)`을 실제 타입으로 바꾸면서 `CHARACTER SET utf8mb4`를 추가하세요. 또는 전체 테이블을 변환할 수도 있습니다:

```sql
ALTER TABLE collections CONVERT TO CHARACTER SET utf8mb4;
```

그런 다음 서명을 다시 저장하세요.

Question 4

WriteFreely 클래식 에디터에서 폰트 토글이 작동하지 않는 문제를 어떻게 해결하나요?

Accepted Answer

WriteFreely 0.15에서는 에디터의 font-family CSS 클래스가 누락되어 글꼴 전환이 실패할 수 있습니다. 다음 스타일을 `less/pad.less`에 추가하세요:

```less
.norm { font-family: Lora, 'Palatino Linotype', 'Book Antiqua', 'New York', 'DejaVu serif', serif; }
.sans { font-family: 'Open Sans', 'Segoe UI', Tahoma, Arial, sans-serif; }
.wrap { font-family: Hack, consolas, Menlo-Regular, Menlo, Monaco, 'ubuntu mono', monospace; }
```

그런 다음 UI 에셋을 재생성하고 애플리케이션을 다시 빌드/재시작하세요:

```bash
make ui
```

생성된 CSS 파일은 무시되거나 덮어쓰이므로 직접 편집하지 마세요. 공식 수정 사항은 WriteFreely 0.15 이후 릴리스에 포함되어 있으므로 업그레이드가 영구적인 해결 방법입니다.

Question 5

WriteFreely API를 통해 게시물을 작성할 때 'created' 날짜가 무시되는 이유는 무엇인가요?

Accepted Answer

WriteFreely API는 날짜 파싱이 일관되지 않습니다: 게시물 생성 엔드포인트(`POST /api/posts` 및 `POST /api/collections/{alias}/posts`)는 `created`/`updated` 필드가 RFC3339 형식(예: `2023-11-10T12:00:00Z`)인 경우에만 해당 필드를 인식합니다. `2023-11-10 12:00:00`(`%Y-%m-%d %H:%M:%S` 형식)을 보내면 해당 필드가 조용히 무시되고 대신 현재 서버 시간이 사용됩니다.

해결 방법:
- 게시물을 **생성**할 때는 RFC3339 형식으로 날짜를 보내세요: `{"body":"test", "created":"2023-11-10T12:00:00Z"}`
- 게시물을 **업데이트**할 때(`POST /api/posts/{id}`)는 타임존 없이 공백으로 구분된 형식 `2006-01-02 15:04:05`를 사용해야 합니다. 여기에 RFC3339를 보내면 500 오류가 반환됩니다(`Unable to parse Created date: parsing time ... cannot parse "T12:00:00Z" as " "`).
- 또는 먼저 게시물을 생성한 다음, 원하는 `created`/`updated` 값으로 즉시 업데이트 요청을 보낼 수도 있습니다.

날짜 형식을 통일하는 정식 수정이 PR #1492에 제출되었습니다. 이 수정이 포함된 WriteFreely 버전으로 업그레이드하면 모든 곳에서 하나의 일관된 형식(RFC3339)을 사용할 수 있습니다.

writefreely

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트