サイトは「作ること」よりも、「無理なく運用し続けられること」の方が難しいものです。
ウェブサイトの構築において、WordPressは非常に広く使われているCMSです。 多くの企業サイトや情報発信の場面では、十分に有効な選択肢と言えます。
ただし、サイトの内容や運用の仕方によっては、別のアプローチの方が無理なく続けられる場合もあります。 その一つがDrupalです。
続きを読む
WordPressは、ページを作り、それを積み重ねていくことに適したCMSです。 一方でDrupalは、最初に「どのような情報を扱うのか」を整理し、構造として組み立てていくことを前提としています。
情報の種類を分け、それぞれに必要な項目を持たせ、 さらに情報同士を関連付けていく。そうした設計が求められる場面では、Drupalの方が自然に対応できます。
サイトは公開して終わりではなく、運用の中で少しずつ変化していきます。機能を追加したり、情報の見せ方を変えたりする場面も増えていきます。
WordPressでは、その多くをプラグインによって対応していくことになりますが、それが積み重なることで構成が複雑になっていくことも少なくありません。
Drupalでは、フィールドや表示の仕組みが標準で用意されているため、機能追加も構造の延長として組み込むことができます。結果として、後から見ても理解しやすい状態を保ちやすくなります。
WordPressでサイトを構築する場合、 初期段階ではシンプルに始められることが大きな利点です。固定ページや投稿を追加し、必要に応じてプラグインで機能を拡張していくことで、無理なく立ち上げることができます。
ただし運用が進むにつれて、カスタムフィールドが増え、似たような情報が別々に管理されるようになり、 さらに検索や絞り込みの要件も増えていきます。
その結果、管理画面が分かりづらくなり、どこに何があるのか把握しにくくなっていきます。機能を追加するたびに調整が必要になるなど、構成そのものに無理が出てくることもあります。
「作れた」ことと「運用できる」ことは、別の問題です。
こうした段階に入ったとき、情報を構造として整理することを前提としたDrupalの考え方が、有効に機能します。
サイト内の情報が増えてくると、必要な情報にたどり着きやすくするための工夫が重要になります。
Drupalでは、条件を組み合わせた検索や並び替え、表示形式の切り替えといった機能を、特別な仕組みに頼らず構築することができます。 これは、情報があらかじめ構造化されているためです。
ウェブサイトは、数年単位で運用されることが一般的です。その中で担当者が変わったり、機能が追加されたりと、状況は少しずつ変化していきます。
Drupalは構造が明確であるため、こうした変化があっても整理しやすく、運用を続けやすい状態を保ちやすいという特徴があります。
WordPressとDrupalは、どちらが優れているかではなく、役割の違いがあります。
WordPressはシンプルな構成で素早く立ち上げるのに適しており、 Drupalは情報の構造を整理しながら長期的に運用していくサイトに適しています。
もし現在のサイトについて、 「更新はできているが、少しずつ分かりづらくなってきている」 と感じている場合、 それは構成を見直すタイミングかもしれません。
といった状態が見られる場合、サイトの作り方そのものを見直すことで、運用の負担を大きく減らせる可能性があります。
「何で作るか」ではなく、「どうすれば無理なく続けられるか」という視点で、現在の構成を整理し、必要であれば再設計をご提案しています。
既存サイトの状況を確認した上でのご相談も可能ですので、気になる点があればお気軽にお問合せください。
LINE、X（旧Twitter）、Facebook、InstagramなどのSNSは、今や情報発信に欠かせないツールになっています。
一方で、「SNSがあればホームページはいらないのでは？」と思われることもあります。
しかし、SNSとホームページは役割が大きく異なります。
SNSは、
という特徴があります。
キャンペーン告知や、日々の情報発信、話題づくりにはとても向いています。
一方で、
という弱点もあります。
ホームページは、
という役割を持っています。
いわば、
「正しい情報を、きちんと置いておく場所」
がホームページです。
営業時間、料金、サービス内容、会社概要など、
は、ホームページにまとめておく方が安心です。
SNSとホームページは、どちらか一方ではなく、組み合わせて使うことで効果を発揮します。
考え方としては、
という関係です。
例えば、
といった使い方ができます。
SNSだけだと情報は流れて消えてしまいますが、 ホームページに載せておけば、いつでも確認できる「公式情報」として残ります。
SNSはとても便利ですが、次のようなリスクもあります。
SNSはあくまで他社サービスの上に成り立っています。
一方、ホームページは自分たちの資産として運用できます。
情報の拠点としてホームページを持っておくことは、長期的に見ても重要です。
これからの情報発信は、
という役割分担が現実的です。
ホームページが「土台」となり、 SNSが「拡声器」となるイメージです。
どちらか一方ではなく、両方をうまく組み合わせることで、 安定した情報発信と集客につながります。
SNSは情報を広めるのに向いていますが、 ホームページは情報を整理し、蓄積するのに向いています。
ホームページを情報のベースとし、 SNSを使ってそこへ誘導することで、より効果的な運用が可能になります。
自社に合ったホームページ構成や、SNSとの連携方法についてお悩みの場合は、 お気軽にご相談ください。
お問い合わせはこちら
Drupal（ドゥルーパル）は、ホームページやウェブサイトを構築・運用するためのサーバー用ソフトウェア（CMS - コンテンツマネジメントシステム）です。
国内ではより一般的に利用されているCMSにWordPressがあり、WordPressと同様に、
という基本的な特徴を持っています。
一方でDrupalは、
に特に向いているCMSです。
Drupalというと「大規模サイト向け」「行政機関向け」というイメージを持たれることがありますが、実際には、
など、中小規模のサイトでもその威力を発揮できます。
むしろ、
といったサイトでは、最初からDrupalを使っておくことで、後々の拡張が楽になるケースも多いです。
Drupalでは、
といった特性の異なるコンテンツを、それぞれ別の「コンテンツタイプ」として管理できます。
これにより、
というメリットがあります。
「ページが増えるほど整理されていくCMS」というのがDrupalの大きな特徴です。
Drupalは、カテゴリ・タグ・年度・種別といった分類（タクソノミー）を自由に設計できます。例えば、
といったことが簡単に実現できます。
情報が増えても「あとから探せるサイト」になるのが強みです。
といった役割（ロール）ごとに操作できる範囲を設定できます。
といった運用も可能です。
複数人で更新するサイトや、社内向けページを含むサイトには特に向いています。
Drupalは、デザイン（見た目）とコンテンツ（中身）を分けて管理できます。そのため、
といった柔軟な運用が可能です。「長く使うサイト」の構築に最適です。
WordPressは、
という用途に向いています。
Drupalは、
どちらが「上」ではなく、サイトの性格によって向き不向きがあるという関係です。
「最初は小さく、後から育てる」という考え方とも相性が良いCMSです。
Drupalは、情報を整理して管理でき、拡張性が高く、長期運用に向いているCMSです。
中小規模サイトでも、将来を見据えた構成や、情報が増えても破綻しない設計をしたい場合には、十分に選択肢になります。
Drupalによりホームページ構築・運用にご興味を持たれればぜひお問合せください。
― WordPressとの違いから考える ―
Drupalというと、官公庁や大企業、大規模ポータルサイト向けのCMSという印象を持たれることが多く、「中小規模サイトにはオーバースペックなのではないか」と思われがちです。
確かに、会社案内やブログ中心の小規模サイトであれば、 WordPressや静的サイトの方が適しているケースもあります。
しかし実際には、 中小規模であっても、Drupalが適しているサイト構成は少なくありません。 重要なのは「サイトの規模」ではなく、「扱う情報の構造」です。
WordPressは導入しやすく、情報も多く、 中小規模サイトでは最も一般的に使われているCMSです。
「ページを作る」「記事を書く」という用途において、 WordPressは非常に優れたCMSです。
一方で、次のような構成のサイトでは、 WordPressでの運用が次第に難しくなるケースがあります。
たとえばスーパーマーケットや美容室チェーンのサイトでは、 店舗、商品、サービス・メニュー、スタッフ、チラシ・キャンペーン、 採用情報、お知らせといった複数種類の情報を相互に関連付けながら管理する必要があります。
このような構成をWordPressで実現しようとすると、 カスタム投稿タイプやカスタムフィールド、プラグインが増え、 管理画面が複雑になりやすくなります。
その結果、 更新が難しい、制作者でないと触れない、改修のたびに不安がある、 といったCMSになってしまうことがあります。
Drupalは、 「構造化された情報を管理すること」を前提に設計されたCMSです。
制作時に、 どんな種類の情報があるか、 それぞれにどんな項目が必要か、 それらをどう表示・一覧化するか、 をあらかじめ設計します。
たとえば、
といったように、情報を「型」として定義して管理します。
規模が小さくても、「構造が複雑」なサイトでは、 Drupalは有力な選択肢になります。
更新頻度が低いサイトであれば、 HTML＋CSSによる静的サイトという選択肢もあります。
しかし次のような場合、静的サイトでは対応が難しくなります。
このような場合、「CMSを使うかどうか」ではなく、「どのCMSを使うか」が重要になります。
Drupalは短期制作向きというより、長期運用向きのCMSと言えます。
Drupalは大規模案件向けという印象がありますが、中小規模で構造が複雑なサイトでは、Drupalの「設計力」そのものが価値になります。
個人事業として構築を行うことで、無駄な工程を省き、意思決定を早くし、コストを抑えることが可能です。
CMS選定では、「小規模だからWordPress」「大規模だからDrupal」という判断がされがちです。
しかし本当に重要なのは、サイトの規模ではなく、情報の構造がどれだけ複雑かという点です。
上町ウェブ製作所では、中小規模サイトを中心に、 Drupalを使った構築・移行・改修を行っています。
といった段階からご相談をお受けしています。
「Drupalが向いているかどうか」から整理することも可能ですので、お気軽にお問い合わせください。
今年1月にサポートが終了しているDrupal7、AIに訊いてみるとまだDrupal7のままのサイトが少なくないようです。自分の携わるウェブサイトは全て昨年末までにDrupal10への移行を完了していますが、なかなか大変な作業で、10サイトほどの移行で調査、学習と試行錯誤を重ね、全てが完了するまで2年くらいかかってしまいました。
概ね上述の流れの作業となりますが、千単位のコンテンツや万単位の画像があっても、コンテンツ自体の移行は完全にできました。Drupal7からDrupal10へのアップグレードとしていますが、自分の場合、実際には、Drupal7→Drupal9→Drupal10と2段階でアップグレードしています。Drupal7とDrupal9は基本的な構造（アーキテクチャ）がごっそり変更されているため、Drupal7→Drupal9はもう諦めようかと思ったくらいの作業でしたが、Drupal9→Drupal10はアーキテクチャの根本的な変更は無く比較的容易。それでも廃止されたモジュール等もあり、それなりに面倒な作業が必要でした。
ウェブサイト開発ツールとして、Drupal10でCMSとしての取り組みやすさのハードルが、WordPress等と較べて上がったことは間違いないと思います。しかしながら、データベースに保存されたコンテンツやその部分をいかようにも出力できるという柔軟性は他のCMSに真似のできないもので、移行してそれを享受できることはありがたいです。一般ユーザーとしての使い勝手の良さは改善され続けており、またセキュリティの高さもDrupalを選択する大きな要素であることに変わりはありません。
もし、Drupal7からDrupal10への移行でお困りの場合、お手伝いできるかも知れません。お問合せからご一報いただき、詳しく状況をお聞かせいただければ、精査の上、対策をご提案いたします。大きく環境が異なるため、100％同じシステムをDrupal10で構築できるかどうかは精査してみないと分かりませんが、代替方法も含め、有効な対策をご提案できると思います。
サイトの規模、複雑さ、利用されているモジュールによって、作業内容や難易度が大きく変わってきますので、一概に概算見積をご提示することはできませんが、個人事業なので、比較的ローコストでお手伝いできるかと思います。少なくとも継続的にDrupal7の延長サポートを利用されるよりもかなり有利と思われます。
逆にある程度の規模がないサイトの場合、Drupalは最適の選択肢ではなくなっているかも知れません。その場合は静的サイトとSNS等ウェブサービスを活用した方がいいというケースもあります。簡易な方法へ変更し固定費を削減する方法も必要に応じてご提案いたします。
当サイトのシステム全体を一新しました。
折をみてそれぞれについて詳しく書いてみたいと思っています。
上町製作所ホームページをたぶん5年ぶりくらいに完全リニューアルしました。Drupal7をDrupal9へ移行、それに合わせてサーバーも移行しています。
デザインは追々手を加えていくつもりで、徹底的にシンプルに変更しています。
港珠澳大橋（Hong Kong-Zhuhai-Macao Bridge）が10月23日に開通したそうです。香港、マカオ辺りのGoogle Mapを見ると地図表示だと何もでてきませんが、航空写真に切り換えると、香港空港から西へ海の上に道路が延びていて、途中で途切れ、その8kmほど東側にアクアラインの海ほたるみたいな島ができています。そこからマカオと珠海のボーダーのすぐ東側に新たに造成された島まで道路が続いていて、この島からマカオと珠海につながっています。
香港空港の東側にも新たに島が造成されていて、ここが入出境のためのターミナルになっています。橋の全長は55kmで世界最長、香港からマカオ、珠海へはシャトルバスが日中5〜15分間隔、深夜でも15〜30分間隔の24時間運行、料金を調べてみると片道HK$65、1000円ほどです。所要時間が明記されていないのですが1時間かからないでしょうね。
従来のターボジェット船だと日中15分間間隔で所要時間55分もHK$171、ターボジェットの経営努力で何とかなる価格差じゃなく、トラムが並ぶ上環のターミナルの賑わいが無くなってしまうのはたぶん必至、寂しくなります。
一方、香港から北京や上海への高速列車も9月23日に開業しています。エアポートエクスプレスの九龍駅の「東側」に隣接して西九龍駅が開設されています。自分が香港に通っていた頃はずっとゴルフ練習場と広大な空地だった場所です。まだ10年ちょっと前なのに、新幹線のような高速鉄道が香港までやってくるとは当時考えもしませんでした。ましてやマカオまで橋でつながるなんて。
まだ香港空港がカイタック空港だった30年ほど前に食品の仕事で珠海へ出張したことがあります。香港から高速船で珠海の小さな港に着き、珠海の街に入ると南国情緒がいっぱい、ビンロウの並木で囲まれたメインストリートとおぼしき道路を牛がのんびりリアカーを引いて歩いていたのをよく覚えています。出張先の食品工場の向かいの飲料工場の清涼飲料水の出荷風景と眺めていると、出荷ケースに並んだボトルのドリンクの入っている高さが全然まちまちだったことを思い出します。
仕事を終え、マカオ経由で香港へ戻る際、珠海マカオのボーダーからみた高層ビルの立ち並ぶマカオを見て心底ホッとした記憶がまだ鮮烈です。それほどのド田舎だった珠海です。
それから10数年して今度はおもちゃの仕事で珠海へ行った時には、もうド田舎どころではなく、マカオを凌ぐほどの高層ビルが立ち並んでいて、度肝を抜かれました。そしてそれから15年ほど経った今、香港から珠海やマカオへバスで行けるようになってしまいました。
日本が明治維新から150年かけてきたことを、あるいは英国が産業革命から200年以上かけてきたことを、中国が30年でやってしまっている訳です。
この極めて急速な変化を香港人皆が手放しで喜んでいるかどうかは、ちょっと疑問です。早速高速鉄道に乗ってきた人のレポートによると、西九龍駅の中で入出境が一遍にできるようになっていて、境界となるところに黄色い線が引かれていてその先は簡体字の世界になっているそうです。MTRの羅湖駅で出境し小さな川を越えて深圳駅側に入境できるまで、自分たちは軽く1時間かかり、香港のIDカードを持つ友人たちをいつも長時間待たせていたという不便は無くなったものの、香港のど真ん中にまで簡体字の世界が出現したことはやはり強い違和感を感じます。
港珠澳大橋では黄色い線がどこにあるのか不明ですが、おそらく香港空港の東側にできた島の中と推測されるものの、対岸の珠海とマカオで体制が異なる訳で、どういう運営がなされているか気になります。
香港は依然グローバル経済の拠点であり、また多くの香港人は英国時代からの中国文化と融合した独特の自由な文化に強い誇りを持っています。いつまでも香港の文化が守られることを願ってやみません。もう10年以上ご無沙汰している香港の友人たちに会いたくなってきました。
上掲の香港サイト、メジャーサイトなのにいずれもスマホ対応していないようです。その辺の事情も探ってみないと。
常時SSL化すると、それまでのFacebookいいね！のカウントが引き継がれなくなってしまいます。常時SSL化後の新規コンテンツについてはもちろんいいね！がカウントされますが、それ以前のコンテンツはゼロになってしまいます。気にしなければいいのかも知れませんが、せっかくいいね！をたくさんもらって、ブログ投稿の大きな励みになっている訳で、やはり復活させたいと思います。
この2点です。（参考）
参考ページはMovableTypeなのでこれをDrupal7に置換えます。
コンテンツ作成日で切り分ける方法もいいかと思いますが、NID（コンテンツ固有の連番）で切り分けるのが簡単かも。html.tpl.phpのheadタグにコードを追加します。
<?php if (arg(0) == 'node' && is_numeric(arg(1))): ?> <?php $nid = arg(1); ?> <?php if ($nid < SSL化する前の最後のNID): print '<meta property="og:url" content="http://DOMAIN/PATH/'.$nid.'"/>'; else: print '<meta property="og:url" content="https://DOMAIN/PATH/'.$nid.'"/>'; endif; ?> <?php endif; ?>
1行目、2行目はNIDを取得するためのおまじないです。SSL化する前の最後のNIDの場合はog:urlにhttpで、それ以降はhttpsにします。
次に.htaccessに1行、下記の3行目を追加します。
# Various rewrite rules. <ifmodule mod_rewrite.c> RewriteEngine on RewriteCond %{HTTP_USER_AGENT} !(Facebot|facebookexternalhit/1.1) [NC] RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
3行目以外はhttpからhttpsにリダイレクトさせる設定です。3行目でFacebookのクローラーだけはリダイレクトさせないように設定します。SSL化以降はリダイレクトさせる必要がないので、Facebookのクローラーはhttpsを読んでくれます。
たぶん何日かするとFacebookのクローラーが回って来てくれて、いいね！カウントは反映されるはずですが、すぐに反映させたい場合はFacebookのシェアデバッガーで「新しい情報を取得」すればいいね！カウントが出てきます。
追記11/23: クローラーは更新してくれないようで、シェアデバッガーで1件ずつ新しい情報を取得するしかないようです。
Googleリーダーがサービス終了してもう5年にもなるんですね。
SNSが爆発的に普及して以前のようにはRSSリーダーが使われなくなってしまったようですが、プライベートな情報が中心となるSNSに対して、よりパブリックな情報を収集するには、今もRSSリーダーは生活に仕事に、趣味に、欠かせないツールだと思います。
世界中から隣近所までカバーする世間の様々な出来事、自らの関わる市場や商品、技術、法律や規制の最新動向、趣味や生活でのお役立ち情報、これまで興味はなかったけど新しい興味を掻き立ててくれる情報、自分と同じだったり似た意見や考えだけでなく、全く賛成できない意見や、腹の立つ考えも知っておく必要はあります。特にライブドアブログ、FC2、goo、sonetといった古くから運営されているブログサイトのブログの情報の充実度は半端なく、SNSでは得られない奥行きの深い、貴重な資料といっていい情報がびっしりです。
もしRSSリーダーを使わなくなっていたとしたら、あまりにもったいないです。SNSでは得られない新しい世界が見つかる可能性が大です。
Googleリーダー終了後、一番メジャーなRSSリーダーはFeedlyで、使っている方も多いかと思います。Googleリーダーのようなタイトルビュー、画像をメインにしたカードビュー等々、自分の好みで様々な設定できます。アプリ版のカードビューのシャッフルするようなユーザーインターフェースの使い心地も快適です。
ところが自分のブログのRSSフィードで、画像のフィードは画像フィールドの1枚めの画像に設定しているのに、サイドバーにランダムに表示している、コンテンツとは直接関係のないお気に入り画像がフィードされたりしてしまうことがままあります。フィード文もティーザー（本文のまとめ）をRSSフィードに設定しているのに、本文の冒頭部分が抽出されています。
どうやらRSSフォード発信元の設定に関わらず、フィードしたURLから画像や文章をFeedly独自の判断で読み込んでいるようです。前から気にはなっていたのですが、別のRSSリーダーだとどうなんだろうと探して見つけたのがInoreaderです。
Googleトレンドで過去3年にさかのぼってFeedlyとInoreaderを比較してみました。以前は比較にならないくらいだったのが、ここにきてかなり接近してきています。それ以上にFeedly検索の絶対数がかなり減ってしまっていることが目を引きます。RSSリーダー自体が使われなくなってきている中でInoreaderが着実に伸びてきているともいえそうです。
さてInoreaderですが、画像フィールドの1枚めの画像もティーザーの文章も自分が設定したRSSフィードを正確に読み込んでくれます。Google ChromeでRSSフィードを表示するとソースしか出てきませんが、FirefoxだとRSSフィードの設定状態をビジュアルに見やすく確認できます。これと同じものがInoreaderで多くの登録サイトと統合し一覧できる訳です。
逆に言うと画像をRSSに組み込む設定をしていないとフィードに画像が無い状態が発生します。このためFeedlyは独自のロジックで画像を抽出しているようです。
Inoreaderにもカードビューがあるのですが、スマホアプリでも1ページ1コンテンツにならないので、カードビューはFeedlyの方がカッコよく、また使いやすいです。一方Inoreaderはユーザーインターフェースが日本語化されているのもウリかと。
がっ！もうひとつ大きな違いがあります。Inoreaderのスマホアプリで個別のフィードを開いて、画面を下へフリックすると「全コンテンツを読み込む」というのができます。これで本文全体が、レスポンシブデザインかどうかなど関係なく、アプリの画面に最適化した出力になり、元のサイトのCSSもJavaScriptも排除されてしまい、殆どの場合、アフィリエイト広告も表示されなくなります。HTMLのマークアップではaタグによるハイパーリンクなど最低限が残されています。文字サイズも大きくて高齢者にも優しく、特にまとめサイトとかは、かなり読みやすくなってしまいます。
「全コンテンツを読み込」めないケースもあるのですが、HTML5のarticleタグとかDrupalだとnode classの要素とか、Wordpressだとid="content"の要素とか、色んな定型的なパターンから本文部分を読み込みに行っているよのでは、と推測します。
これ、自分も含めウェブ屋にとってはかなり脅威です。情報収集にかなり便利ですが、サイト運営者の意図しない出力でもあります。そのことは読む側にも概ね理解された上で利用されていると思われ、また全てのウェブコンテンツをInoreaderで読むことになるとも考えにくいですが、サイトを運営する側としては、デザインやレイアウト、ユーザーインターフェース以上にやはりコンテンツありき、ということを改めて肝に銘じる必要はありそうです。
当サイトのRSSです。現時点では3件のフィードしかありませんが、鋭意更新していくつもりです。 上町のおっさんのブログのRSSです。こっちはフィードがいっぱいあります。よろしかったらFeedlyやInoreaderに登録してください。表示されたURLを購読登録するだけです。
スマホの場合はリンクを開くのではなく長押しでURLコピーできるかと思いますが、パソコンからのほうが登録しやすいかも。スマホからでも登録しやすい方法は再調査中ですm(_ _)m