PCサイトとスマホ(スマートフォン)サイトの画像を切り替える方法(2)


1)designer contentをインストールする

 詳しいインストール方法は、日本語ユーザー会の説明をご参照頂くこととします。

 一応簡単に説明しますね。
まず、本家アドオンのサイトから、圧縮されたファイルをダウンロードしてきます。
(※designer conctentは、開発者向けのため、マーケットプレイスからは直接インストールできません)

 ダウンロードしてきたファイルを解凍して、フォルダごと(「designer content」フォルダ)、 concrete5のサイトの「packeges」フォルダにアップロードします。

 concrete5を拡張 → 機能追加、「Designer Content」[インストール]を押す。

Designer Content install.jpg

 「新しいパッケージがインストールされました。」が表示されれば、インストール完了です。

Designer Content install_ok.jpg

PCサイトとスマホ(スマートフォン)サイトの画像を切り替える方法(3)

PCサイトとスマホ(スマートフォン)サイトの画像を切り替える方法(1)

 concrete5(5.6.3.3-ja)で、PCサイトとスマートフォンサイトの画像を切り替える方法

 concrete5は、CMSとしてある程度ファイル数も多く、どうしても速度面が気になるところではあります。しかしながら実際は、高機能なキャッシュシステムによってそれを感じさせないレスポンスをもたらしてくれます。

 高速に表示してくれるのはいいのですが、一つだけ困った事があります。

このキャッシュシステムは、各ページのブロック単位で働かす事が可能なのですが、
標準でかつよく使う、『記事ブロック』の設定を変更するわけにはいけないですね。
 (※変更しても問題 ないなら当然 可能です!)

concrete5では「カスタムテンプレート」を使って、サイトの表示仕様や、見栄えは修正するのですが、 アクセスしてきた端末によって画像を切り替えたい場合があります。

ですので、記事ブロックのカスタムテンプレートに、画像切り替えロジック(User Agentによる:方法は後述)を書きました。

concrete5のキャッシュ設定は、

『キャッシュとスピード設定』にて、
フルページキャッシュ → 有効 - 該当のページ上のブロックで許可されていれば

に設定しました。

あれ?
実際の動作は、最初にアクセスされた機器の画像になっている
そうなんです。画像が切り替えできていないのです。

仕方がないので、キャッシュをトップページのみ無効にしていました。
そして、調査を開始。

concrete5-japan.orgの検索 欄 より
検索ワード::キャッシュ ブロック単位

テーマで叩いたAPIのキャッシュについて
http://concrete5-japan.org/community/forums/development/post-8796/
をみつけました。それによると、(リンク変更を考慮して引用&転記しました)

----------------------------------------
テーマでやると、フルページキャッシュしか効きません。ただ、フルページキャッシュで良ければ、ログアウトして閲覧する際は超高速になります。ページ内に動的なブロックがあるとフルページキャッシュが作られませんので、たまに困ります。

ブロックで作れば、ブロックキャッシュが効きます。ブロックキャッシュはブロック単位で表示結果をキャッシュしますので、フルページキャッシュが効かない場合でも高速化できます。Designer Contentで適当にブロックを作ってから、controller.phpのキャッシュ設定をいじればOKです。

$btCacheBlockRecord : ブロックの設定をキャッシュするかどうか。普通はtrue
$btCacheBlockOutput : ブロックの出力結果をキャッシュするかどうか。ページリストやコメント欄など常に更新がある動的なものはfalse
$btCacheBlockOutputOnPost : フォームの送信があったときにキャッシュするかどうか。最初の表示はキャッシュされていて、送信ボタンを押した際の表示はキャッシュされない。完全にフォーム用の設定項目。
$btCacheBlockOutputForRegisteredUsers : ログインしているユーザーにもアウトプットキャッシュを表示するかどうか。キャッシュしたいがログインユーザーによって表示が変わる場合があるとき $btCacheBlockOutputLifetime : アウトプットキャッシュの有効期間。秒単位
----------------------------------------

ブロックのcontroller.phpの、
// $btCacheBlockOutput = true;
$btCacheBlockOutput = false;
にするだけなんです。

が、これを行うためには、前述の通り記事ブロックや画像ブロックのcontroller.phpを修正するわけにもいきません。

 そこで登場するのが、前述の引用にもあります通り、

designer conctent」を使って適当なブロックを作成して(この言い方がふさわしいのです)それに、画像切り替えロジック追加と、 キャッシュの設定変更すれば出来上がりです。


【目次】
 1)designer conctentのインストール
 2)オリジナルブロックの作成(リンク付き画像2個[PC用/スマホ用]表示ブロック)
 3)画像を切り替えるロジックの追加(ただし、関数として設定::helper(navigationにメソッドとして)
 4)画像切り替え追加( 2)でできたブロックのview.php(カスタムテンプレートでもどうぞ)に 3)のメソッド(関数)を使って作成 )
 5)controller.phpのキャッシュの修正
 6)動作検証(キャッシュ設定変更、キャッシュをクリア後)::PCとスマホから画像が切り替わっていることの確認
   (※当マインドハーツのトップページがこの機能を使って、ビルボード画像を切り替えています)

PCサイトとスマホ(スマートフォン)サイトの画像を切り替える方法(2)

さくらのスタンダードで、sitemapページがsitemap.xmlになる

 『さくらのレンタルサーバ スタンダード』

※2015/06/19時点(仕様は適宜変更される場合がございますので、ご注意ください)

●ページ : サイトマップ
●カノニカルURL : sitemap

と設定して、sitemap.xml のファイルがある(通常は作成しているのである)とき

『サイトマップ』のページを表示すると、『sitemap.xml』の中身が表示されてしまいます。

 ★原因は、『さくらのレンタルサーバ スタンダード』が、特殊な「URLルーティング」 設定になっているためだと思われます。

(※未確認の推測ですが、独自ドメインのサービス仕様と、セキュリティ確保のため?) 「concrete5.6.3.3日本語」にて、「プリティーURL」をONにすると起こります。

 最も、本家サイト の質問があるように、実際には存在しないフォルダよりも、存在するファイルを 優先して表示するように、mod_rewrite(URLを自由に変換する機能)の設定されているようです。 これを一般的に、「特殊」設定と言われているものかと思います。

他のサーバで、かつ特殊な設定になっていないものは起こりません。


 ★回避方法ですが、2つあります。

1)●ページ : サイトマップ ●カノニカルURL : sitemap-list

というように、sitemap.xmlの「sitemap」と重ならないようにします。

なお、「プリティーURL」は、デフォルトのままでOKです。
ドメインのルート以外のフォルダにインストールしてある時は、
例) concrete5が、http://example.com/concrete5/ に保存されている場合
「RewriteBase /」 → 「RewriteBase /concrete5/」

 

2)他のサーバーと同じ表示にしたい(普通はね)

●ページ : サイトマップ
●カノニカルURL : sitemap
●ファイル表示(Rss): sitemap.xml

と機能してほしいとき

★concrete5がインストールされているフォルダに、
『sitemap』フォルダ(中身は空にする)を作成します。

★「プリティーURL」を以下のように設定します。

# -- concrete5 urls start --

RewriteEngine On
RewriteBase /
RewriteRule ^sitemap\.xml$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}/index.html !-f
RewriteCond %{REQUEST_FILENAME}/index.php !-f
RewriteRule . index.php [L]

# -- concrete5 urls end --

※確認時、ブラウザのキャッシュを削除しておかないと、表示がかわりません。
concrete5のキャッシュではないです。

WordPressとconcrete5の構造の違い

階層構造を作る

 concrete5のサイトに更新しました。

まだ、WordPressの移植の名残から、不要なクラスや情報が残っていそうです。
記事ブロックエディタの スタイルシートも最適化しないと少し 少し使い にくいです。
今後のテンプレートを最適化する時のための宿題ということにさせてください。

 さて、今回CMS(コンテンツ管理システム)に関しては、特徴がそれぞれあると言うのを幾度となく記載しました。

 その理由が「階層構造」に関することです。

concrete5を知らないとき、あるWordPressの参考資料(といっても有名な書籍です)から、
「カスタム投稿」「カスタム分類」機能による階層化の方法を学び、実際に実装してみました。

当マインドハーツのサイトで言うと、「お知らせ」にあたります。
これは、さらに「新着情報」「リリース情報」のサブカテゴリーがあります。
構造は以下です。

また、サイトの構造上、「お知らせ」をクリックすると、「新着情報」「リリース情報」サブカテゴリーに関係なく、時系列に[項目]を表示する仕様になっています。会社のコーポレートサイトでありがちですね。

結果的に、ある程度コードを書いて、その機能は実現できています。
もっと技術やプラグインをご存知の方なら、きちんと実装できるのでしょう(事実そんなプラグンを発見しました)が、実は困ったことが起こります。

それは、URLの階層構造です。

よくSEO的にどうなの?

とかいわれますが、人なら気にならないことでも、ロボットなり、AIだと正当に評価するから気になるかもですね。

お知らせ
 ・新着情報
   項目1
   項目2
   項目3
 ・リリース情報
   項目4
   項目5

とあったとします。
http://mindhearts.com/information/

WordPressを熟知されたかたなら、同様の階層構造を作ることはできるんでしょうが、
私は、そこまで残念ながらできませんでした。というか、おかしいとは思っても、
それが、どれだけSEO的に影響するのかがわからないからです。
リンク的には、問題なく機能しているし、参考資料でも同様の構造になっていたからです。
具体的には、

お知らせ(WordPress)
http://mindhearts.com/information/
お知らせ(concrete5)
http://mindhearts.com/information/

これはいいですよね。固定ページで作るので。

新着情報(WordPress)
http://mindhearts.com/news/whatsup/

新着情報(concrete5)
http://mindhearts.com/information/whatsup/

リリース情報(WordPress)
http://mindhearts.com/news/release/

リリース情報(concrete5)
http://mindhearts.com/information/release/

リリース情報→サイトをリニューアルしました!(WordPress)
http://mindhearts.com/info/renewal20141122/
トップページ > お知らせ > リリース情報 > サイトをリニューアルしました!

リリース情報→サイトをリニューアルしました!(concrete5)
http://mindhearts.com/information/release/renewal20141122/
トップページ > お知らせ > リリース情報 > サイトをリニューアルしました!

あれ、でしょ? パン屑ナビや、構造は見かけ上どちらも同じなんですが、階層が ・・・
urlの表示ながなんだかおかしい。
そりゃプラグインで作れば、問題なく、同じurlを出力できるのかもです。(ごめんなさい。未実装です)

※もともと、固定ページとカスタム分類を同じハンドルのinformationにしてたのですが、ページナビが機能しなくなったので、カスタム分類は、informationinfo に変更しました。

これはそもそも仕様の違いです。

 WordPressの本来の機能である、ブログ機能では、
カテゴリーや分類を使えばできそうですが、これができない。
よく考えると、カテゴリーや、分類分けで、情報(コンテンツね)を「時系列」に保存します。
そりゃそうですね。ブログなんだから。

新しい記事が最初にきて、古い記事を後に持ってくる。
それだけでことが足ります。

記事を書く時も、カテゴリーや、分類を選ぶだけ。後は投稿するだけです。
そして、お好みでタグクラウドを追加してできあがり。
これでブログとしては、完了です。
わかりやすいですね。

 他方、これに「階層構造」を取ろうとすると、記事(投稿ね)を一つの管理基準とする
WordPressにはとたんに敷居が上がります。潤沢なプラグインを有するので、実現可能な、
プラグインは、当然あるはずです。ざっと検索しましたが、カスタム投稿の階層化のみです。
(すみません、あると思いますが、検索しきれていません。ご存知のかた教えてください。)

ちょうど、前述の「お知らせ」ー「新着情報」、「お知らせ」ー「リリース情報」ですね。
これが、「カスタム投稿」「カスタム分類」の機能です。

基本「時系列」が原則で、あとの並びは、アルファベット等、ある検索順序になります。
通常のサイト部分なら、直接順番にリンクを出すなりして、調整できますが、いちいち、細かいカスタマイズができない、サイトマップ(もともと、標準の機能ではなく、プラグインで実現しています)だと、デフォルトの並びになってしまっています。(スラッグや投稿IDは、内部管理や、URLを出力するためのハンドル名)を見るとお分かりのように、

リリース情報(WordPress)
http://mindhearts.com/news/release/
新着情報(WordPress)
http://mindhearts.com/news/whatsup/

のようにサイトマップでは並びます。
こんな感じ。

お知らせ
 ・リリース情報
 ・新着情報

本来は、

お知らせ
 ・新着情報
 ・リリース情報

 理由はお察しの通り、アルファベット順だからです。このスラッグをうまくアルファベット順と、
並べたい順をあわすか、もっと詳細設定できる、サイトマップのプラグインを使うかです。
結局完璧にこだわると、膨大なお手間が必要となります。できないことはないし、頻繁に変更がない、コーポレートサイト(会社のホームページ)なら、いいかもです。
しなしながら、サイトマップを小細工しても、そもそもの目的である、検索エンジン対応はできるのでしょうか?

ということです。ある意味そこにこだわってもしかたがないかもです。

当、マインドハーツのWordPress版の時は、サイトマップは詳細カスタマイズはしませんでした。
なので、

お知らせ
 ・リリース情報
 ・新着情報

のように表示されます。


 他方、concrete5は、元々ニュースサイト運用など、大規模サイト運用のために作られていますので、階層構造が基本となっています。管理画面のサイトマップを見ていただくとわかりやすいかと思います。

ただし、管理する単位は、WordPressが「投稿」なのに対して、concrete5は「ページ」となります。

ページは、「ブロック」と呼ばれる機能の単位を積み上げることで、作成されます。
(これが、concrete5の名前の由来だそうです)

concrete5(5633ja)SiteMap.jpg
(参考:マインドハーツサイト構造)

と階層構造になっているのがわかります。
数字で、親子を設定するのではなく、単にドラック&ドロップしてページ
を好きな配置にできます。並びは、好きにできますし、「お知らせ」のように、新しいものから表示することもできますし、
サイトマップ(標準機能です)の並び通りにも、表示が可能です。

これが、いいとか悪いとかでなく、WordPress, concrete5とも、あくまでツールなので、
用途に応じて使い分けるのが、いいかと思います。