[MovableType]基本的な使い方

Reading Time: 1 minute

もー全然わかんない。
触ったことねぇよ!
で、基礎すぎるところから調べたりしてるんだけどうまく見つけられなくてトライアンドエラーで理解していく。

MTタグ

調べたらタグ時点的なものとか参考記事とか出てきて、やりたいことはあらかた網羅されてる。
でも組み込んでも動かない。
MTタグがそのまま表示される。
インデックステンプレートで使う場合は保存だけじゃダメで、再構築もしないとってことなんだけど、それでも表示されないものがあったりする。
参考記事と実行環境のバージョンの違いが問題なのか?
何なんだろうなマジで。

MTタグの使い方

管理画面で覗ける範囲のファイル・モジュールでのみタグは機能する。
「再構築」「公開」を通すことで処理される。
MTタグを使用したファイルを別途で用意してincludeしてきてもタグは機能せず、ただの文字列として処理される。
管理画面で各テンプレートを作成して、管理画面上で内容を記入して、ファイルを書き出す。
ファイルをFTPでアップしたら使えるという認識は間違い。
WPと同じ感覚でやってると躓く。
FTPでアップするファイルはMTタグを使ってない、include元として使用するファイルに留めたほうがいいというか、そもそも使用を控えたほうがいいかも。
あとで混乱しないように画像とかCSSとかJSみたいな装飾用のファイルのみがいい。

テンプレートの種類

インデックステンプレート

サイトのデザインはここでやる。
ベースの部分。
MTタグも効くけどどうなん。
更新時には「再構築」「公開」を忘れずに。
更新内容の反映は即時じゃないっぽいのでちょっと待つ。
「再構築」をクリックしたタイミングでMTタグを処理して各ページを静的ファイルとして生成する・内容更新する仕組み。
サイトリニューアルの場合、ブログ記事がアホみたいにストックされてると個別ページとか記事データに関わるページはくっそ時間掛かる。

アーカイブテンプレート

無くてもブログは作れる。
カテゴリ別のアーカイブを作りたいときとかはここで差別化したものを作る。

テンプレートモジュール

PHP準拠で変数とかパーツを作って格納したりできる。
作ったパーツを分類してジャンルごとに多重配列でまとめちゃえば便利かも。
WPのfunctions.php的なやつ。
MTタグ使えるから、そういうのはこっちでやっといてインデックステンプレートでは変数で呼び出すのがごちゃごちゃしないかも。

システムテンプレート

よくわかんない。
案件で触らなかった。

レスポンシブサイトを作成するにあたって

バージョンにより違うかもしれんし、僕が理解してないところもあるけど。
PC、SP、モバイルでそれぞれテンプレートを割り振れる。
これはこれで便利なんだけど、普段デバイス別にサイトを作るんじゃなくて一元管理的な、全部込みのやつを作ってるタイプの人にはちょっと面倒なことになる。
今回いじったものは各テンプレートを用意する必要があったので、それぞれの読み込み先ディレクトリが違ってて、各パーツのファイル名の指定しかでけんかった。
include祭りにすれば一元化できるけど、そこは複製してそれぞれに当て込んだほうがいいのかもしれない。
useragentで切り替えてるから、デバイス別に表示・非表示を確実に組めるわけで。
共通項をいじらないといけないときはめんどくさいけどね。

ウェブページ(WPでいう固定ページ)の作成

ブログのアーカイブとか記事ページじゃなくて、会社概要とかの単一ページで使うやつ。
「ウェブページ」とか「ページ」の括りがこれ。
専用カテゴリを用意してアーカイブページで記事内容を表示すれば疑似ウェブページも作れる。
でもリンクを付けなくてもひょっとしてで記事ページにアクセスされたり検索結果に上がったりとか稀にある。
リスクもあるっちゃある。
そのリスクを考えずにウェブページを封印するアホは頭おかしいと思うんだけど。
記事一覧に固定ページのコンテンツが紛れるとか無駄だと思うんだけど。
馬鹿なのかな?
自分じゃ絶対にやらないけどやってるところもある。
馬鹿だろうなきっと。

MT+ECCubeについて

複数のCMSを噛ませるのってまあ、たまにあるけど。
コンテンツ別に差別化するんじゃなくて、1つのサイト内のコンテンツ単位としてそれぞれ有用なCMSを採用する。分かるけどさ。
こんなに運営者を不幸にするWEB環境はないんじゃないかってレベルでひどい。

自社ECサイトを外部サービスに頼らずに作ればランニングコスト抑えられますよみたいな、目新しいし財布にも優しいし今後これが流行っていくんじゃねって甘い言葉で物事を知らない人に売りつけたんじゃないのか。
WEB会社も食ってかなきゃいけないからカモがほしかったんだろうけど、あまりにも考えなしすぎる。
WEBサイトは都度手を入れていかなきゃいけないコンテンツなんだから、作っておしまいはありえない。
デザインにしろ機能にしろ、必ずいつか更新する日が来る。

当時はECサイトの機能を求めたい場合、外部サービスに加入しなければ立ち上げが出来なかった。
そんな中にデザインの制約もなく、全部自前で作れるし安上がりっていうのはとても魅力的に見えたんだと思う。
今は変わってきたけど、MTもECCubeもバージョンアップの概念がないというか、新しくサイトを作って中身を載せ替えるしかアップデートの手段がなかった。
バージョンによってはデータベースの構成も変わるからすごい手間だし、新サイトの立ち上げ規模になるからお金もかかるしで、だから作ってしまったら環境を変えることが出来ない。
脆弱性が出たとしてもSSL噛ませるくらいしかできない。

で、複数のCMSで構築するにあたっては、見た目が同一サイトでもコンテンツにより管轄のCMSが違うから、Atomとかみたく外部公開するためのデータ以外の共有はできない。
ECCubeのデータベースをMTで引っ張ってくるとか、そういう仕組はない。
「MTで作ったページ上でECCubeのログイン状況に応じたコンテンツを表示させたい・カートの内容を表示させたい」みたいなのは無理。
やろうと思ったらできるんだろうけど、そこまでしてやるもんか?ってコスパに響くレベルの内容。
MT→ECCubeはできるんだよ。
MTは静的ページを生成できるから、それをECCubeで拾えば済むんだよ。
でも逆にECCube→MTはMTからECCubeのデータベースに拾いに行かなきゃいけないんだよ、んでその立て付けは無いんだよ。
できる範囲でやりましょうつってもECCube管轄下のページだけ表示させてMT管轄下では表示しないなんて、見た目は同一サイトなんだけどページによってなんか違うんだけどどうなん?ってのは本寸法とは言えない。
閲覧側からすれば関係ないわけで、なんだよこれってなる。
「ブログページにはブログのアーカイブを表示させるけど他には表示させない」的なのはいいんだよ、そこまでしても画面がうるさいだけだから。
「カート機能がついてるサイトのはずなのに」って前提で考えると、カート情報とかのどのページでも共通して表示した方が絶対にいいよなって内容が置けないのが問題。
じゃあもういっそのこと全ページ共通のコンテンツには、そういうやつは設置しない、って選択しかとれない。
今はわかんないよ、できるかもしれないよ。

でもそこらで目にするサイトはアップデートできない(しづらい)、機能を制限する羽目になる、そういう環境。
リニューアルにあたってはサイトを1から全部作り直すしかないですねとか、可愛そうになってくるし、案件として関わりたくない。
ECCubeも4まで来てるのに2で跳ねちゃったもんだから、移行できないユーザーが多すぎてサポートが延々続いてる。
織り込み済みで運営してますってところはないんじゃないか、諦めて現状維持してるんじゃないのか、健全とは思えない。

デザイン面に関して言うと、CSSとかJSは指定先を一緒にすればいいだけだから共有できる。
ヘッダーやフッターもincludeすれば同一データを使用できるからまあ共通できる。
でも各管理下のコンテンツについては管理画面が異なるので分けて考えないといけない。
そこはしょうがないと飲めたとして、リニューアルの際にサイトの構築に掛かる手間が半端じゃない。
本来のデータを使わずにincludeしてます、include元のファイルはここにあります、この中身はこうやって拾ってます。
「共有しているコンテンツ」「個別のコンテンツ」「共有してるようで実は個別のコンテンツ」「第三のコンテンツ」これがPC・SPで倍になるかもしれない。
サイトをどうやって構成してるのか、まず仕組みを読み解かないといけない。
どこをいじって良くて、どこを触っちゃいけないかも、理解してないと何も出来ない。
構成の理解の必要性は普通のサイトの引き継ぎもまあ同じっちゃ同じだけど、中身を覗いた時に面倒が多すぎる。
中途半端にテクニカルなことをして、だから何のメリットがあるのか、そこまでのメリットなのか。

つーか、ECとかブログとか全部設置してますよのサイトって必要なのか?ってこともある。
お知らせを更新するたびに静的ページをいちいち弄るのはめんどくさいから、まあブログ機能ほしいよねって気持ちもわからんことはないけど。
でもお知らせとか都度バナー作って貼ればいいじゃん。
年末年始休業のお知らせとか、よく見えるところに置いとけばいいじゃない。
ブログサービスは無料だろうが有料だろうがRSSとかAtomあるんだから、それを引っ張ってもいい。
無ければ無いでどうとでもなる。

全部を一つにまとめたら、ちょっとしたことでも手を入れたら全部に影響が出るんだよ。
良いところは全部取れるけどリスクは分散できますみたいな環境であることが大前提じゃないのか。
MT+ECCubeは所詮別サービス同士の間の子なんだから無理なんだよ。
お互いを外見上似せてるだけで実はまとまってない。

カートとブログ機能の共存を自社環境でどうしてもやりたいならWPでWelcart使うのが安心安全なんじゃないかと思う。
MT+ECCubeの方が出始めは早かったけど、Welcartの追っつきはそんなに遅くなかったはず。
それなのに制作会社がWelcart推してるのを見たことがない。
Welcartが完全無欠とは言わないけど、元々WPはアップデート面で優れていたし、一つのCMS内で完結するんだから使い勝手は当初から圧倒的に上だった。
なんで採用しないかって言えば、どうせ積んだノウハウがもったいないからなんだろうね。
全部無駄になるとでも思ってんのかね。
その場しのぎならともかく継続するようじゃどうしようもないよ。

そんなわけでMT+ECCubeは何も幸せにならない。
CMSを使うならその範囲でできることをしたほうが良い。

シェアする

  • このエントリーをはてなブックマークに追加