Drupal で長くコンテンツを編集していると、この小さいながらも厄介なワークフローの中断に遭遇したことがあるでしょう。単語を選択したりカーソルを置いたりして、マークアップを微調整するためにソースモードに切り替えると… 位置を見失ってしまうのです。私はまさにこれを解決する小さなモジュールを作りました。

あるとき、デカップルド Drupal の計画ミーティングの途中で、CTO が私にこう尋ねました。「で、どの API を使うべきなんだ?」

一瞬、部屋が静まり返りました。フロントエンドは GraphQL を望んでいました。バックエンドは JSON:API を望んでいました。ある連携ベンダーはすでに REST を前提にしていました。プロダクトオーナーは、モバイルアプリがウェブサイトのリリースを待たなくて済むようにしたいだけでした。

この小さな問いは、たいてい技術的な問いのように聞こえます。しかし違います。これはガバナンスの問い、予算の問い、そして時には開発者のパーカーをまとった採用の問いなのです。

あるとき、数千のリンクを持つ Drupal のメニューを開いたところ、私より先にブラウザが音を上げるのを目にしました。ページは、技術的には読み込まれました。しかしその後、クリックのたびに、古いプリンターに自分の気持ちを説明してほしいと頼んでいるような感覚でした。

BigMenu と Menu Select から始める

Drupal サイトに大きな編集用メニューがある場合、最初の問題はたいていアーキテクチャではありません。編集画面です。コアのメニュー管理ページは、メニューが数千のリンクにまで膨らむと苦痛になり得ます。BigMenu は、編集者がメニューを閲覧・管理する方法を変えることでこれに対処します。ツリー全体をページに強制的に表示するのではなく、編集者が必要とするときに AJAX でサブツリーを開けるようにします。https://www.drupal.org/project/bigmenu

多言語のバックログには独特の匂いがあります。月曜に英語で公開し、ドイツ語は「今週中」と約束し、金曜には更新された47ページを前にして、「で… 本当のステータスはどうなっているんだ?」ときれいに答える方法がない、という状況です。

私は、チームがこれをより多くのプロセスを投入して解決しようとするのを見てきました。スプレッドシート、翻訳チケット、週次の同期ミーティング。誰かが200ページのヒーロー段落を編集するまではうまくいきます。そのあとは、また推測に逆戻りです。

私たちにとって最終的にうまくいったのは、翻訳を本番システムのように扱うことでした。追跡と統制のための TMGMT、cron 経由で自動的にジョブをトリガーする小さなカスタムモジュール、そしてバックグラウンドで動作し、チャンク分割によって大きなフィールドを扱える AI 翻訳ツールです。

この記事はマネージャーの視点です。成果、リスク、そして静かな混乱に陥らないためにチームに何を尋ねるべきか、です。

まず、「自動翻訳」が本当に意味すること(Drupal の観点で)

サイト全体を瞬時に5言語に変換する魔法のボタンを思い描いているなら、忘れてください。信頼できる版は、もっと遅く、もっと退屈です。

DrupalBook では、編集体験が技術的な後回しではなく、ビジネス上の重要事項である Drupal プラットフォームを支援しています。Drupal が CKEditor 4 から CKEditor 5 へ移行したとき、それはモダンな編集基盤をもたらしましたが、同時に、確立された CKEditor 4 プラグインに依存していた組織にとって大きなギャップを生み出しました。この記事では、私たちがどのように不可欠な機能を移行することでそのギャップに対処し、編集チームの継続性を確保しつつ、クライアントがモダンな Drupal バージョンへ前進できるようにしたかを説明します。

パラグラフ(Paragraphs)ベースの構造化コンテンツが、多言語サイトを最新・スケーラブルに保ち、AI 支援の翻訳に対応できるようにチームを助ける方法。

1 はじめに

Lightbox プラグインは、10 年以上にわたって Drupal ベースのウェブサイトの定番でした。現在のページから離れることなく、オーバーレイで画像・動画・その他のメディアを表示できるようにするもので、これはモダンでメディアの多いサイトで訪問者が期待するパターンです。

Colorbox は歴史的に、Drupal エコシステムで定番のソリューションでした。コントリビュートモジュール colorbox は Drupal の画像フィールドフォーマッターと密に連携し、成熟した API を持ち、コミュニティに広く知られています。しかし、ウェブの進化とともに Colorbox はその古さを見せています。jQuery に依存し、より重いペイロードを配信し、現代のアクセシビリティの期待に後れをとっています。

1. なぜ CI 主導の設定管理が重要なのか

Drupal の設定システムは、このプラットフォームの最大の強みの1つであり、同時に最も確実な痛みの源の1つです。サイト設定のあらゆる要素を YAML ファイルとしてエクスポート・インポートできる能力は強力です。しかしそれは、それらのファイルを環境間で移動させる責任者が誰なのかについて全員が合意している場合に限ります。ほとんどのチームでは、その合意は決してきちんと存在しません。

古典的な問題は、Drupal サイトをリリースしたことのある人なら誰でもよく知っています。

Drupal 7 のサポートはすでに終了し、新しい更新はもうなく、新しいモジュールはすべて Drupal 11 以降向けにリリースされていますが、それでも多くのサイトが Drupal 7 を使っており、新しいバージョンへ移行できずにいます。それには理由があり、特にカスタムコードの多いサイトではそうです。

なぜこの変更が必要なのか?

• Drupal 9 では、jQuery Cookie がコアから削除され、js-cookie ライブラリに置き換えられました。後方互換シム(core/jquery.cookie)が Drupal 9 の間は存在しましたが、Drupal 10 で削除されました。
  https://www.drupal.org/node/3104677
• Drupal 10.1 では、コアがもはや使わなくなったため、core/js-cookie アセットライブラリ自体が非推奨となり、Drupal 11 での削除が予定されました。変更記録は、コントリビュートの JS Cookie モジュールへの切り替えを推奨しています。
  https://www.drupal.org/node/3322720