ヘッド レス cms。 ヘッドレスCMSとは? ヘッドレス、デカップルド、APIファーストのコンテンツ管理に関するガイド

AWS API Gateway + Lambda と WordPress REST API によるヘッドレス WordPress 入門(1)

ヘッド レス cms

昨今、「ヘッドレスCMS」という言葉をよく耳にします。 CMSは皆さんもよくご存知の通り「」のことです。 Webサイトにおける静的・動的なページを統合的に管理して、サイト全体のデザインや仕様に一貫性を持たせたり、一般ユーザでも記事投稿が自由に行えるなど、Webサイトの運用管理をサポートするシステムの1つです。 では「ヘッドレスCMS」とはいったい何でしょうか?、またなぜ注目されているのでしょうか?本稿では、ヘッドレスCMSの基本について解説していきます。 ヘッドレスCMSとは? CMSの歴史を少し遡ると、最初は「個別のWebページを作成し、FTP通信でファイルをアップロードしてくれるシステム」でした。 そこから発展し、「Webサイト全体のデザイン・仕様およびコンテンツを管理するシステム」へと進化します。 さらに、CMS自体がWebブラウザ上でのサービスとして完結するようになり、今では特別なシステムを構築せずとも、CMSを活用したWebサイトの作成・管理およびコンテンツの作成・管理ができるようになっています。 ビジネスにおけるWebサイトの重要性が増し、多くの企業がCMSを利用していく中で、CMSもワークフロー管理、Webサイト運営担当者のユーザー管理、コンテンツプレビュー、承認フロー、公開予定設定などの機能が備わっていきます。 またここ数年で、TwitterやFacebookといったSNSの利用も重要視され、ソーシャルとWebサイトの連携やデータ配信の機能が追加され、また、WYSIWYGや画像処理を行えるフロントエンドによってCMSは更に強化されています。 そして現在では、CRM(Customer Relationship Management)やDMP(Data Management Platform)とのデータ連携により、ユーザーに表示するWebページをパーソナライズ(個別最適化)するようになり、製品の情報などもバックエンドのと連携することで、各種製品やサービスに関連する情報を動的に表示するといった工夫がなされています。 こうして発展してきた従来のCMSはいわゆる「オールインワン型」であり、CMSさえ導入すれば、これらの機能を使いこなすことで、Webマーケティングも最適化できるようになっています。 しかしその反面、それぞれのCMSには独自仕様が備わっており、ファイルの置き場所、書き方、命令規則など内部構造に一定のルールを持っています。 その中にはかなり複雑な仕様を持ち、一度CMS化するとWebデザイナーやWebコーダーでは中身を触ることができなくなってしまうようなものもあります。 これに対してヘッドレスCMSはWebサイトそのものと作成・管理機能の「分離的な構造」を作っています。 これにより、CMSを導入しても、Webサイトの内部構造を一切変化させないまま、Webサイトの作成・管理、コンテンツの作成・管理ができるということです。 HTML・CSS・JavaScriptのファイル置き場所や名前、階層なども変化しません。 ヘッドレスCMSのメリット では、従来のCMSに比べてヘッドレスCMSにはどのようなメリットがあるのでしょうか?まだ世間では浸透していないメリットについてご説明します。 基本構造を変えずにCMSが導入できる ヘッドレスCMSはその特性から、ページ(ファイル)単位、またはページ内の部分単位で動的に動作するため、Webサイトの全体の構造には一切関与しません。 これは言い換えれば、どのような構造を持ったWebサイトでも、まるでプラグインのようにCMSを導入できるということです。 従って、制作会社がそれぞれの基本構造やルールをまったく変更することなく、CMSが導入できることを意味します。 さらに、動的化したファイルには数行のコードが追記されるのみなので、全体的なコードはさほど変化しません。 プログラミング知識を持たないWebデザイナーやWebコーダーも、CMS導入後引き続きメンテナンスを行うことができます。 デザインや仕様の制約が一切無い 従来のCMSはWebサイト全体を管理するものですが、ヘッドレスCMSはデータのみを管理してWebサイト自体は管理しません。 そのため、Webサイトは一般的な動的サイトと同じ状態で管理できるため、CMSがデザインや仕様に制約を与えることはありません。 さらに、ヘッドレスCMSは「Webサイトの外」で動作しているため、Webサイトに組み込まれた他のプログラムと衝突することがなく、SNSとの連携、カート機能、決済システムと連携など、Webページに独自のプログラムを組み込む場合でも、CMSによる制限が無いのです。 Webサイト・CMSの分業体制が取れる オールインワンパッケージのCMSを導入した場合、コーディングするだけでもバックエンドのプログラムやデータベースをある程度意識する必要があります。 静的なコーディングに専念したいWebコーダーにとっては、ストレスを感じることもあり、コーディングも複雑になる場合があります。 ヘッドレスCMSの場合は、静的なコーディングをする段階ではCMSのことを気にする必要が無いため、Webコーダーはそうしたストレスから解放されます。 完成した静的なWebサイトに、プラグインのようにCMSを付け足すことで、動的なWebサイトに作り変えることも可能です。 従って、ヘッドレスCMSを導入した環境では、静的なコーディングとCMSを利用した管理作業を完全に切り分けて分業体制を取ることができるため、運用が効率化されます。 仕様変更も簡単に行える CMSによっては、一度決定した仕様を変更するのが難しいケースがあります。 そのため、「当初は想定していなかったが、Webページのある部分だけを更新可能な状態に変えたい」、「企業ブログなどのコンテンツを追加したい」といった仕様変更に対応できません。 一方、ヘッドレスCMSはあくまでWebページのデータだけを管理するので、Webサイト自体の仕様にほとんど関与しません。 Webサイトを公開した後も、仕様変更に柔軟に対応できます。 仕様変更にかかる工数も従来のCMSと比べて圧倒的に少ないので、仕様変更が多く、将来的に成長していくようなWebサイトに最適です。 ヘッドレスCMS導入はすぐに取り組むべきか? ここまでの解説から、ヘッドレスCMSに対してさまざまなメリットを期待している方も多いでしょう。 しかし、導入を急がない方が良い理由があります。 従来のCMSとは違いシステム面で複数の検討課題があるため、まずは課題を整理し、解決に向けた対策や計画を立てることが先決となるためです。 たとえば、アクセス権限管理や配信関連のロジックをどこに持つべきなのか?フロントエンド側の各システム用のユーザーログインなどの管理はどこに持つのがよいのか?ユーザー行動関連のデータをどう管理すべきなのか?などなど、他にも必要とされていなかったAPI管理の必要性が生じたり、いろいろな課題が想定できます。 一方で、システム管理面では、Webサイトのコーディング作業から分離されることにより、情報の取りまとめを行うための基盤構築の自由度も高くなります。 例えば、製造業などが抱える課題としては、数万、数十万に及ぶ商品のスペック情報やサポート情報、サイズや色のバリエーションを管理する必要があり、従来のWebサイト管理方法だとページの更新や情報の管理に大きな負担が掛かっていました。 WebサイトとCMSを分離するアーキテクチャーの採用により、例えば、ヘッドレスCMSとPIM(商品情報管理システム)を組み合わせて構成することにより、Webサイト制作の制約を受けることなく商品情報を管理することも可能になります。 これらの課題を十分に理解しつつ、ヘッドレスCMSを適切に導入するための対策と計画を立て、自社環境にとって最適なヘッドレスCMSを目指すことが大切です。 皆さんもこの機会に、新しいCMSのトレンドであるヘッドレスCMSについてぜひ検討してみてください。 当社では、ヘッドレスCMSと併用できる、多くの商品情報を適切に管理するため商品情報管理システムの導入をご支援しています。 、、などの多数の実績に加え、エキスパートによる構想作成支援も実施しています。 にご興味がございましたら、お気軽にご相談ください。

次の

【次世代のWordPress?】aws-cid.boxhill.edu.auでヘッドレスCMS「contentful」を始めてみる

ヘッド レス cms

APIベースのヘッドレスCMS「contentful」を試してみたので、その概要や設定の流れ、API利用の準備についてノートします。 contentfulとは? ドイツのスタートアップが開発したAPIベースのCMS。 WordPressなどの従来型CMSではバックエンドとフロントエンドの両方を提供していましたが、contentfulでは管理サイトとそこで設定したデータ、いわゆるコンテンツをCRUDするAPIだけを提供しています。 バックエンドとフロントエンドを分離したこのようなCMSを「ヘッドレスCMS」と呼び、このcontentful以外にも「」「」「」(GraphQLというAPIの問い合わせ言語を開発している会社が提供するCMS)などがあるようです。 APIベースだと何が良いのか? Webサイトだけでなく、スマートフォンアプリやサイネージなど様々なデバイス向け開発をすることができます。 また、WordPressではPHPによる開発になりますが、APIベースであれば、フロント開発にはどのような言語でも採用できるメリットがあります。 今回はJavaScriptのSPAフレームワーク nuxt. jsでフロントを開発してみます。 contentful側の設定 contentfulにアカウント登録して、設定を進めます。 ログイン後のダッシュボード画面は以下のようになっています。 contentfulには大きく「Space」「ContentModel」「Content」「Media」という概念があります。 ・Spaceはサイト自体のスペース ・ContentModelは、データベースのテーブル定義のようなもの。 テーブル上のカラム定義(フィールド定義)を管理サイトから設定できるようになっています。 ・Contentは、ContentModelに定義したテーブルに登録された実データ というイメージです。 ContentModelでテーブル定義を行う 今回は簡単なブログサイトを制作するので、「ブログ記事」を格納するためのContentModelを定義してみました。 フィールドタイプには、テキスト・数値・日付以外にもJSONデータや他ContentModelとリレーションを貼ったデータなどのタイプを定義することができます。 データを登録する 定義したContentModelにデータを登録します。 データ登録はContentから行います。 記事はマークダウンでも記述することができます。 APIキーを作成する フロントエンドからアクセスするためのAPIキー(トークン)を設定画面から作成します。 続けていよいよフロントエンド側の開発です。 今回はnuxt. jsを利用するので、フロント環境の開発から行いたいと思います。

次の

APIベースのヘッドレスCMS contentful + aws-cid.boxhill.edu.auを試してみた(contentful設定編)|蓮田 健一|note

ヘッド レス cms

正直あまり時流に乗れていないのですが、昨今フロントエンドとバックエンドを分離してフロントにより自由度を! とのコンセプトのもと「Headless(ヘッドレス) CMS」なるものが流行しているそうです。 国内ではあまりサービスは見られないものの、海外ではHeadless CMSの先駆けとして「」、そしてFacebook社も「」をリリースしています。 確かにCMSからViewを分離できれば、• CMS側ではJSON(API)のみになるためフロント側が言語に依存しない• ホスティングされたものが使えるため自前のサーバーがいらず、セキュリティ等もおまかせ 等のメリットがあります。 とはいえ、やはりそこは枯れたWordPress。 痒いところに手が届くプラグイン群や 日本語のUIはクライアントワークには欠かせません。 そこで、「インストールしたらまずはREST APIをオフに」等いわれてはいますが、そこを敢えてWordPressをJSON出力マシーンとして利用し、ViewはReact等のナウいライブラリを使ってやってみたいと思います。 なお、この記事は、22日目の記事です。 そしてわたしはモロ()です。 WordPressのViewを無効化 まずはWordPressのViewをなくす必要があるため、空っぽのThemeを用意します。 空の index. php style. cssと、いくつかの設定を詰め込んだ functions. phpのみです。 個人的にせっかくWordPressの制約から開放される以上、あまり functions. phpで複雑なことをしたくなかったため、あくまで新しいAPIを生やしたりはせずにおります。 com)のようなことをしたほうがいいかも知れません。 プラグイン周り WordPressの利点でもある 豊富なプラグインは活かしたかったため、いくつか導入しました。 Advanced Custom Fields ACF to REST API 言わずと知れたカスタムフィールドを便利にするプラグイン。 併せてを入れることでAPI側からも簡単にカスタムフィールドの値を取得できるようになります。 Jetpack by WordPress. com こちらもWP公式の多機能便利プラグイン。 これを導入することで、WordPress. com経由で「」が利用できるようになり、例えば• アクセス数ランキング• 「メニュー」の取得 等もできるようになります。 WordPress REST APIと比べると• WordPress. com経由のためアクセス元が制限できない• 若干通信が遅い 等のデメリットもありますが、場合によっては重宝するかも知れません。 No Category Base WPML フロント側を例えばReact等で制作する場合、恐らくReact-Router等使うので実際的には必要ないのですが、例えばフロント側で用意するのが面倒くさいSitemap. xml等は• WordPress アドレス URL を api. example. com• サイトアドレス URL を example. com• WordPressの「パーマリンク設定」をフロント側と揃える にして、URLの辻褄を合わせればでさくっと実装できます。 WP REST API Menus 先述のWordPress. com Jetpack APIでもメニューは取れるのですが珍しいAPI対応プラグインだったので一応。 APIのデータを取得する 以上でWordPressのHeadless CMS化はほぼ完了、あとは「」を参考に思う様データを取得するだけです。 この辺りはある程度情報が豊富なため検索すればすぐに調べられますが、基本的な部分のみ念のため書いておきます。 example. example. example. example. example. example. example. example. example. example. com Jetpack API 要Author認証。 wordpress. wordpress. wordpress. なお、肝心のフロント部分はでせっせと開発中です。 ぜひPR等でご助力くださいませ。 ではでは。 関連する記事•

次の