この記事はMovable Type Advent Calendar 2017の10日目の記事です。
ネットの契約切替をミスって1週間ネット難民でした。
テザリング生活は本当に辛かったです。自分にとってネットは大切なインフラと再認識しました(゚A゚;)ゴクリ
記事はMT7ネタを考えようかと思ったのですが、色々と情報が少なく書く自信もないのでいつもやっている開発フローについて書こうと思います。
普段の開発フロー
最近の開発は、以下のようなフローでWebサイトを構築しています。
ローカル環境にLAMP環境構築済み且つMovable Typeをインストールしている状態にしておきます。
- ローカル環境(VirtualBox・Vagrant)にMovable Typeをインストール
- 支給されるHTMLデータを元にテーマ化する
- ある程度構築環境後、テーマを本番サイトにアップし管理画面で適用・再構築
2と3は繰り返しの作業になり手間な部分はありますが、直接サーバを弄る前に調整してからアップするようにしています。
開発ファイルの構成
自分の開発では、HTMLデータ・MTテーマはすべてGitで管理しています。
以下が開発環境のリポジトリのフォルダ構成になります。
- _resource(静的HTML編集ファイル)
- html(出力後のファイル・プレビュー用)
- mtml(MTのテーマ格納ディレクトリ)
- theme_website
- theme_blog
- .babelrc
- .csscomb.json
- .editorconfig
- .gitignore
- .node-version
- Readme.md
- gulpfile.js
- metalsmith.json
- package.json
- webpack.config.js
- yarn.lock</code></pre>
Vagrantのシンボリック共有を使って開発する
Git上では、MTのファイルは入れずに別に仮想サーバ上に設置しています。
mtmlディレクトリ(テーマ格納ディレクトリ)だけは一番いじるファイルになるので、
Gitで管理しVagrantの共有フォルダで繋げるようにしています。
共有フォルダを使うことで、Gitでテーマを管理することもできますし毎回テーマを仮想サーバにFTPに接続しアップする作業を省くことができます。
やり方は、Vagrantファイルにsynced_folderを貼るだけです。
- "/path/to/Gitリポジトリ"でGitのリポジトリのパスを指定する
- "/path/to/cgi-bin/mt/themes"は仮想サーバに設置したMTのテーマディレクトリのパスを指定する
# Vagrantファイル
Vagrant.configure("2") do |config|
config.vm.synced_folder "/path/to/Gitリポジトリ", "/path/to/cgi-bin/mt/themes", owner: 'vagrant', group: 'apache', mount_options: ['dmode=777', 'fmode=775']
EOT
end
MTまるごとGitで管理したほうが良さそうな場合は、設置したmt/以下をシンボリックにすることでGitでも管理することができます。
個人的にMTファイルを一式Gitに入れるのは、ファイルが多かったりするのでいれないようにしています。
テーマを編集したら管理画面から再適用・再構築をする
テーマを修正したら、管理画面から再適用・再構築をします。
適用前にカスタムフィールドは削除しておいたほうがいいかもしれません。
フィールドが入ったままだと名前のバッティングするようです。
なぜ?テーマを再適用したり再構築をする構築フローにしたのか
CMS実装者の経験上カスタムフィールド(製造業??)やカテゴリを大量に設定することが多いからです。
クライアントによって要件が変わったりしますが、多い時は何個も作ることもしばしば。。(゚A゚;)ゴクリ
テーマにはyamlというファイルがあるので、yaml形式で入力することで設定したカスタムフィールドやカテゴリを登録することができます。
以下は、カスタムフィールドとカテゴリを入力した例になります。
author_link: http://example.com
author_name: redamoon
class: website
description: ""
elements:
custom_fields:
component: commercial
data:
entry_mainvisual:
default: ""
description: ""
name: 記事のメイン画像
obj_type: entry
options: ~
required: "0"
tag: entry_mainvisual
type: image
default_categories:
component: ~
data:
category01:
description: カテゴリ01のカテゴリになります。
label: カテゴリ01
category02:
category02_children:
gallery1:
description: category02の子カテゴリになります。
label: 子カテゴリ02
description: category02のカテゴリになります。
label: カテゴリ02
importer: default_categories
template_set:
component: ~
data:
base_path: templates
label: "exported_template set"
templates:
index:
_format_template:
build_type: "0"
label: _format_template.html
outfile: _format_template.html
rebuild_me: "1"
module:
template_config:
label: config
template_footer:
label: footer
template_component:
label: component
template_header:
label: header
template_html_foot:
label: html_foot
template_html_head:
label: html_head
template_navigation:
label: navigation
template_script:
label: script
system:
comment_preview:
label: コメントプレビュー
comment_response:
label: コメント完了
dynamic_error:
label: ダイナミックパブリッシングエラー
popup_image:
label: ポップアップ画像
search_results:
label: 検索結果
importer: template_set
id: website_theme
label: "案件名のテーマ"
name: "案件名のテーマ"
version: "1.0"
MT7からはコンテンツタイプという新しい機能が実装されますが、これからどのように使っていくか考えながら知見を増やしていこうと思っています。
Movable Type 7に期待すること
最後になりますが、MT7に期待したことを書いておこうと思います。
完全に実装者向けの機能要望で恐縮ですが、以下があると今回の記事のようなフローも変わっていくのかなって思っています。
まずは正式リリースに期待しつつもっとMTが進化していくことを楽しみにこれからも触っていきたいですね。
- GithubもしくはGitlabなどのツールと連携
- テーマの適用と再適用からの再構築する隠しコマンドがほしい(デプロイ?)
- ライブプレビュー