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

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト