WordPressで構築するショッピングカートの落とし穴

WordPressを使って「ショッピングカートの仕組みができない?」ということを、最近よく相談されます。

WordPressには「ショッピングカート」をするためのプラグインが、結構な数出回っていたりします。

有名なのは「Welcart」というプラグインでしょうか?
また、有料とはなりますが日本人の開発した、カートのプラグインなどもありますね。

しかしながら、僕らのほうでは、こういった相談に対して全て

「WordPressでやるのはやめた方が良いですよ」

とアドバイスさせていただいています。

それはなぜか!?

▼役割分担を超えてはいけない

そもそもWordPressは、ブログ記事を書くシステムとして、10年ほど前から使われてきました。

今はCMSとしての側面が大いに注目され、ブログだけでは無くコンテンツを管理する仕組みとして、いろいろなサイトで活用されています。

機能面でもここ2〜3年で、CMSとして活用するための「カスタム投稿」や「カスタム分類」といった機能が増え、非常に複雑なサイトも構築できるようになりました。

しかしながら、あくまでWordPressの本質は、「コンテンツを管理する仕組み」であって、物販の仕組みを管理したり、顧客を管理したり、売り上げを管理する仕組みではありません。

1つのシステムに何でもかんでも詰め込もうとすると、軋轢が生まれ、必ずどこかに破綻が生じます。

良い例が「不動産プラグイン」です。

大変高機能なプラグインで、不動産検索サイトなどを構築されたい!という方から、
多数のお問い合わせを頂きます。

しかし、このプラグインには1つ落とし穴があります。
それは「パーマリンク設定がデフォルトしか使えない」ということです。

※パーマリンク設定がデフォルトの場合、URLが以下のようになります。
http://example.com/

これはどういうことかというと、新規にこれからWordPressで構築する場合には良いのですが、今まで投稿毎にURLを設定して運用してきたサイトの場合、今までのURLが一切使えなくなってしまうと言うことを意味します。

また、SEO上でもURL設計は大きな意味合いを持ちます。
このURLがWordPressのデフォルトしか使えない、というのは大きなデメリットになってしまいます。

▼ショッピングカート=非常に複雑である

以上のことを踏まえ、あらためてショッピングカートの仕組み、について考えてみましょう。

ショッピングカートといえば、ただ商品がカートに入れられて、それを購入できれば良い、という単純なものではありません。

基本的に下記のようなことがしたい!
という場合が多いでしょう。

・商品毎に送料の自動計算をしたい
・発送地域毎に送料を分けたい
・○○円以上の購入で送料を割り引きしたい
・会員ランクを設けて割引をしたい
・商品の在庫管理をしたい
・決済方法をいろいろ用意したい
・売り上げを管理したい
・顧客管理をしたい
・商品毎の売れ行きを管理したい
・etc…

どうでしょうか。
すでに、上記の機能だけで、1つのシステムができあがってしまいますね。

現にショッピングカートのシステムというのは、以前よりかなりの数のサービスや、プログラムが開発され提供されてきています。

それだけ、内容が複雑で、単純では無いと言うことです。

特に売り上げ管理や在庫管理の仕組みというのは、ウェブ上のコンテンツを管理するという仕組みにとどまらず、「基幹システム」といってもいいほど、重要な仕組みになってくることが想像できます。

▼1つのシステムに集約することのリスク

そんなショッピングカートの機能を、WordPressにまとめたらどうなるでしょうか。

すでにコンテンツ管理の仕組みを超え、売り上げや在庫を管理するための、基幹システムとなってくることが想像できます。

それを無理矢理WordPressに取り付けたら、どうなるでしょうか。

・ユーザーの権限管理をしっかりしないと、売り上げなどの情報が漏れる可能性がある

・商品の管理や送料の管理、売り上げの管理など非常に多くの機能を追加するため、未知のバグが混入する恐れが多くなる

・プラグインまたは本体がアップデートして、どちらかの機能に不具合が存在したら、単純にサイトが見られなくなるだけでなく、基幹システムも使えなくなると言うことに!

・プラグインのバグなどでWordPressのデータベースが消失・改ざんなどされてしまった場合に、売り上げや顧客データさえも消失していまうことになる

昨今、WordPressを狙う不正なプログラムが、ウェブ上に多数存在しています。

もし、上記のような重要な情報を管理しているWordPressが不正アクセスの対象になったら?

何らかの要因で、データベースが消えてしまったら??

WordPressがコンテンツだけを管理しているなら、最悪ウェブサイトが消えてしまったり、使えなくなるだけで、商品の販売や売り上げ管理には、影響を及ぼさないでしょう。

しかし、WordPressがそこまでも担っていたら・・・!?
考えただけでも、ゾッとしませんか?

▼適材適所ということ

スマートフォンがなんでもできるからといって、スパゲティを食べるときに使う人はいません。(いたらごめんなさい!)

スパゲティを食べるときはフォークを使うように、カートシステムを使うときは、ASPで提供しているカートサービスを利用したり、ECCUBEといった専門的なソフトウェアを使う方が、より便利で、拡張性の高いシステムを構築できます。

いくらWordPressが便利だからといって、何でもかんでも1つにまとめてしまうのは、セキュリティ的にもプログラム的にも問題になります。

適材適所、という単語をよく思い出して頂き、そのシステムの役割分担を超えないようにするのが、一番良い方法になります。

▼では、どうすればよいの?

スマートフォンのカメラのように、高画質を求めるわけでは無いけど、どこでも使えるような簡単なものでもいいや!という場合は、WordPressに決済の仕組みを用意するのも1つの方法です。

ただし、その場合専門のカートのような、売り上げ管理、顧客の管理、送料の地域別設定、会員ランク毎の割引といった、複雑な機能はあきらめるのが得策です。

・会員登録の際に決済を行う
・有料ニュースサイトで、
1記事=○円で決済ができるようにする
・ポイントを決済で購入できるようにし、ポイントを使ってサイトの機能を使えるようにする

上記のような例であればWordPressで行っても問題無いでしょう。

WordPressの可能性をより高め、さらに便利に使えるようにします。

上記以外の、複雑な商品販売の仕組みや、顧客管理の仕組みなどを導入する場合、別システムも視野に入れて検討しましょう。

昨今ではASP型のサービスで、既存のWordPress等に簡単に商品販売の仕組みを組み込むことができるサービスも増えていますので、そういった仕組みを使うのも1つの手段です。

WordPressとECCUBEの連携というのも、以前に実現したことがあります。

フロントエンドはWordPressでコンテンツを管理し、ショッピングはECCUBEで管理するという、理想的なシステムです。

僕らは基本的にWordPressの専門サービスを展開していますが、ECCUBEを専門サービスを行っている、非常に心強いパートナーがいますので、そういったことも実現可能になっております。

WordPressの管理画面が使いづらくてちょっと心配・・

最近、よくこんなお問い合わせを頂くことがあります。「WordPressって管理画面が使いづらいので、ちょっと心配です」このご意見、ごもっともです。

昨今、WordPressでブログを書くだけという需要は、あまり多くありません。

どちらかというと「サイト全体を管理するCMS」としての使い方や、「会員専用の仕組み」を用いた、ポータルサイトのような使い方が、とても多くなってきています。

どちらの場合もWordPressの管理画面を使って、投稿や設定などの管理をするのですが、日頃PCを使い込んでいる方や、ブログの投稿に慣れている方からすれば、
何のことはない、シンプルでわかりやすい管理画面でしょう。

しかし、全く知識の無いPC初心者の方や、ブログを書いたことの無い方などからすると、WordPressの管理画面は以外とごちゃごちゃしていて、わかりづらい印象を与えてしまうのです。

▼以外とカスタマイズできる「管理画面」

WordPressは非常に拡張性の高いブログシステムなので、管理画面も実は簡単にカスタマイズできてしまいます。

メニューを増減したり、投稿画面の入力フォームをカスタマイズしたり、新しい設定画面を設けたり・・・。

僕らもこのカスタマイズ機能をフルに活用して、
お客様にできるだけ使いやすい、管理しやすいCMSになるように、いつも努力させて頂いています。

しかしながらこのカスタマイズは、結局もともとのWordPressの画面に、項目を追加したり隠したりするカスタマイズが基本なので、根本的な「わかりづらさ」を解消するには至りません。

デザインの基本部分などからカスタマイズしようとすると、WordPressの「拡張性の高い管理画面の仕組み」が逆に邪魔をします。

非常に複雑な管理画面をゼロから理解しなくてはならず、またWordPressのコア機能に手を入れる羽目になり、メンテナンス性をさげ、さらにセキュリティホールになる可能性も出てきてしまいます。

▼だったら作ってしまえ!

そこで、僕らが提案する方法は
「独自の管理画面を作ってしまえ!」
と言うことです。

WordPressは管理画面の機能も、基本的には1つ1つが「関数」で作られていますので、どんな関数が何をするのかさえわかっていれば、管理画面さえも「固定ページ」などで作ってしまうことができます。

ということは、管理画面用のスタイルシートや画像などを、テーマの一部にに含んでおき、固定ページを使って管理画面に必要なページを用意してしまえば、そのままそれを管理画面として利用できるのです!!

URLの構造なども普通の固定ページと同じように設計できますし、アクセス制限なども、ユーザーがログインしているかをチェックする関数、ユーザーがどの権限を持っているかの関数などを使えば、簡単に実現できてしまいます!

ユーザー登録やパスワードリマインダーでさえ、関数を使って作ることができるので、管理画面の機能は殆ど独自に再現ができてしまうのです。

▼デザインはどうなるの??

上述したように、独自の管理画面は「固定ページ」を使って作ります。
そのため、デザインはどんなものだって利用することができます。
僕らがよく使う方法は、以前「Twitter Bootstrap」と呼ばれていた、Twitter社が作成したHTMLフレームワークです。

[Bootstrap]
http://getbootstrap.com/

このフレームワークは、入力フォームやダイアログなどの表示、ボタンのデザインなど、管理画面に最適なスタイルが最初から用意されているため、ちょっとHTMLを書けばすぐに「それらしい」管理画面ができてしまいます。

またなにより、レスポンシブデザインに対応しているため、WordPressの管理画面をスマフォからでも取り扱えるようになります!
(WordPress3.9からは標準の管理画面も対応していますね)

デザインも非常にシンプルで、不必要なものの一切無い、使いやすくてわかりやすい画面を作成することができます。

▼同じような機能が再現できるの??

作り方によって、WordPressと殆ど同じような機能を、
取り付けることができます!!

・・・のですが、
逆に、WordPressにある機能を「制限する」ことが、
独自の管理画面を作る最も大きなポイントです。

これは、

「WordPressの管理画面が使いづらい=ごちゃごちゃしている=機能が多い」

というのが一番の問題なのです。

なので、使いづらいというお客様への最適解は、

「機能を絞ってシンプルにする」

ということ!

WordPressと同じ機能を再現するのなら、
「WordPressの管理画面でいいじゃん?」ってことになりますね^^;

不必要なデザインを無くし、必要な項目だけをシンプルに実装する。

それだけでも十分に利用価値がありますが、通常の管理画面には無い「入力チェック」を用いると、さらに親切な管理画面になるでしょう。

管理画面にも手間をかければ「入力チェック」を付けることができますが、非常にコストがかかってしまいます。

独自管理画面ならこの機能を簡単に実装することができるので、入力させたくない内容や、必ず入力させたい内容などを、簡単にさらに詳細に、取り付けることができるのです。

▼実際の例ってあるの?

いくつかご紹介させて頂くと、下記のような事例があります。

1. 会員向けのサービスを独自管理画面で展開

登録されている「会員」宛に、一括でお問い合わせを行うことができるサイトを作成させて頂きました。

一般の方が「会員」に問合せをすると、その問合せ内容などが「会員」に送信され、会員さんはウェブ上でその内容を確認することができます。

この「会員さんが使うウェブの機能」を、独自管理画面で作成しています。

会員さんはWordPressのある固定ページにアクセスすると、ログイン画面が表示され、会員登録の際に入力したIDとパスワードを入力することで、「マイページ」にアクセスできるようになります。

マイページでは、今までのお問い合わせ一覧を表で確認でき、クリックすることで詳細を閲覧することができます。

また、自分の登録内容を確認できる「プロフィール確認画面」や、管理者に対して問合せを行う「管理者への問合せ」といった機能を用意させていただきました。

利用する会員さんは一切WordPressの画面を利用しないため、「全くWordPressとはわからない」けれども、中身はWordPress、といった状態で運用が可能になっています。

2. レストラン紹介サイト

レストランをカテゴリーや地域から検索できる、
ポータルサイトを作成しました。

このサイトではレストランが、
自分のお店を任意に会員登録することができ、サイトに掲載することができるようになっています。

1.の例と同様に「レストラン」が使う管理画面は、全てのページを独自に用意させて頂いており、ログイン後のマイページからはいろいろなことができるようになっています。

例を挙げると、マイページからは「レストランの概要」を編集でき、また、レストランからのお知らせを投稿することができます。

さらに、クレジットカードを使って「ポイント」を購入することで、サイト内に掲載できる「クーポン」を登録したり、「メニュー」を投稿することができるようになります。

クレジットカードでの支払連携なども、わざわざ「Welcart」などのプラグインを導入せず、テーマの機能だけで、シンプルに連携することが可能です。

会員さんの各状態は、管理者が使うWordPressの画面からも、管理することができるようになっています。

▼WordPressでできないことはない!!けれど・・

いかがだったでしょうか?

独自管理画面の可能性は本当に無限大で、WordPressを1つのフレームワークとして取り扱えるため、その他のフレームワークでできるようなことなら、殆ど同じように実装できます。

ただし、CMSとしてWordPrsesを使うメリットというのは、

「管理画面が最初から用意されているのでコストが低く済む」

といった部分が大きいため、全くWordPressの画面を使わないというのであれば、WordPressを使うメリットは薄いといえるでしょう。

そういった場合には、他のCMSやフレームワークが利用できないか、選択肢を考えてみるのも一つの手段です。

どのCMS・フレームワークにもメリット・デメリットはありますので、なんでもかんでも「WordPressで済ませる」というのは、正直あまり良いことではありません。

適材適所のフレームワークを用いることが、システム開発を効率よく進める方法となりますので、その点だけは絶対に忘れないでください!

独自管理画面が最も「生きる」のは、先ほどの事例にあったように、「管理画面は管理者が使うけど、会員機能はWordPressを使わせたくない」といったパターンです。

プログラミングの裏側とビジネスについて

先日、僕が参加している、とあるエンジニアのコミュニティでプログラミングの裏側とビジネスについて語り合いました。

そしてそこでは様々な事実が存在ていたので、本日はプログラミングの裏側とビジネスをテーマにしようと思います。

ちなみにこのコミュニティには、様々なエンジニアが参加しておりますが、WordPressに特化したエンジニアはいません。

ですが時流は外せないと行った感じで、WordPressをビジネスに取り入れている方が非常に多いです。

ビジネスにWordPressを取り入れるのは良いことですが、問題はプログラミングの裏側です。

ビジネスが上手なエンジニアは、顧客の要望をスピード感を持って実現できれば、プログラミングの裏側なんてどうでも良いといった感じ。

そしてビジネスが上手なエンジニアは、自分で手を動かすことをせず、レスポンスの良い外注を見つけて案件を回しています。

このことについて、僕の意見はふたつ。

ひとつめは、「良い気づき」

そういうプログラムの作り方でもビジネスを回し収益を上げているということは、技術力があればお金が稼げるっていうことではなく、いかにクライアントとの信頼を築くか?
短納期でクライアントの求めることを行うか?
と言う部分が大事なんだなというのに改めて気づいた。ということ

そしてふたつめは、「やばい事実」

やばい事実とは、短納期で納品するために、またコストを下げるために、セキュリティなどを全く考慮しない変則的な方法で、プログラム開発をしているってこと。

たとえばWordPressであればWordPressで開発するためのルールがあり、それを守って開発を行わないと自分以外がメンテナンスできないコードになったり、最悪はセキュリティホールの温床になってしまいます。

作った人以外わからないプログラムほどメンテナンス性の悪いものは無い。

僕だったらWordPressの流儀に基づいて、WordPressの機能を使って拡張・実装をするのに。。ということです。

確かにビジネスを上手に回すことは大切なことですが、将来性を考えないプログラミングは如何なものか?と思うのです。

安い外注に仕事を依頼すれば、初期費用は安く済みます。

ですが、メンテナンス性の悪さが仇となり、工数が膨らみ、その会社以外がその後の管理ができなくなったらどうでしょうか?

たとえばその会社が業務の都合で1ヶ月以内にサイトの機能を変更しなくては行けなくなった場合、もしその会社に開発の余裕が無かったら?開発担当が退職してしまっていたら??

後々の管理コストが高くなるのは言うまでもありません。
(余談ですが、そのような会社から相談を頂いていたことが実際にあります。)

また僕はプラグラマーとしてのこだわりが非常に重要だと考えています。

うちの代表もよく言っていますが、
「こだわりは魅力を形成する要素のひとつ」

こだわりの強さが、会社の魅力になり、個人の魅力になっていると思うのです。

そして今回で言うならば、そのこだわりがクライアントのコストに反映させるという、非常に良いスパイラルとなっているのではないでしょうか?

APIとWordPress

APIとWordPress

APIとWordPress

本日はWordPressの活用として外部の仕組みと連携させるということについて書いていきます。

WordPressは日々進化しており、いまでは単純なブログシステムやコンテンツ管理システムとしてだけではなく、Webで動作するアプリケーションのプラットフォームとしての側面を持ち始めています。

最近では「REST API」(※1)を用いた更新性の高い仕組みを本体に統合する、といった方針で本体の開発が進んでいます。

(※1)「REST API」とは外部からWordPressの内部のデータにアクセスするためのAPIです。

いままでWordPressにデータを登録するためには、管理画面や開発したPHPなどから登録をする必要がありました。

この「REST API」を使うと、JavaScript等を使った外部の仕組みからデータの取得や登録ができるようになり、様々な用途に用いることが出来るようになります。

例えば、
WordPressをニュースサイトのバックエンドに利用するとします。

そしてそのニュースサイトをiPhoneなどのアプリとしてリリースしようと思った場合、通常だとWebサイトを読み込むようなインターフェースにする必要があり、結局はWebサイトそのものを利用する方法しかありませんでした。

しかし、この「REST API」が備わっていれば、アプリはアプリとして全く違ったインターフェースを持たせ、内部のデータはWordPressに登録されているデータを使うということが出来るようになります。

このように、単純なWebサイトとして活用するのでは無く、コンテンツを登録・管理するためのソフトウェア、本来の意味での「コンテンツ・マネジメント・システム」として利用出来るようになります。

今後はこのように、WordPressをいろいろなシステムのバックエンドとして、利用していくことができるようになるため、今までのような単純なブログとしてではなく、コンテンツを配信・管理するための仕組みとして利用する方向性でも、WordPressを選択する価値があると言えます。

モバイルデバイスのパラダイムシフトが起こり、今ではPC以上にタブレットやスマートフォンが利用されている世の中、「コンテンツ」そのものを配信するメディアとして、WordPressを活用してみてはいかがでしょうか?

Illustratorから綺麗にWebサイト向けのスライスを作成する

今回はwebデザイナーさんやコーダーさん向けのネタとして、Illustratorから綺麗にwebサイト向けにスライスを作成する方法についてです。

僕の知り合いのコーダーさんでも意外と知らなかったことでしたので、今回のテーマにしてみました!

Illustratorを使ってウェブサイトのデータを作成している、といったデザイナーの方は現在でも多いと思います。

しかしながら、Illustratorにスライスを設定しても、書き出しを行う際に1pxズレてしまったり、指定したサイズと違う大きさの画像がスライスされてしまったりり、Illustratorでのスライスはお世辞にも使いやすいとは言えません。

そこでよく利用する方法が、Illustratorから画像を書き出し、Photoshop上でスライスをすると言う方法です。

この方法であればPhotoshopのスライス機能が使えるため、ピクセルのズレなどを全く気にせずにスライスを行うことができます。

ですが、Illsutratorから書き出した画像に問題が起きる場合があります。
具体的には、「文字」や「細い線」などが太ったり、アンチエイリアスが切れたようにジャギーがかかってしまうのです。

そのため、Illustratorから直接書き出した場合と、画像のクオリティが大きく違ってしまうと言うことになります。

実は、このIllustratorから画像を書き出す方法にコツがあったのです。

最初にIllsutratorから全体の画像データを書き出す時に、画像ファイル形式の選択ができるようになっているのですが、ここはデフォルトで「PNG」ファイルとなっており、このまま書き出してしまうと、上記のようなジャギーが発生します。

また、書き出しをする時に「アンチエイリアス」の処理を設定する箇所がありますが、PNGファイルの場合どの設定になっていても、ジャギーがかかってしまうようです。

そこでどうすればよいかというと、PNGファイルではなく「PSD」ファイルで書き出しをしていただくと、文字のアウトラインが綺麗に出力されるようです。

PSDファイルを書き出す際のアンチエイリアスの設定は、「文字に最適」としてください。「アートに最適」などとなっていると、P`NGファイル同様に文字が太くなったり、
ジャギーが発生する原因になるようです。

まとめますと、

1. Illustratorから全体の画像を出力するときは、PSDファイルで出力する
2. アンチエイリアスの処理を「文字に最適」で行う

として頂きますと、Illustoratorから綺麗に書き出しができます。

もし、Illustratorからの書き出しでお悩みの場合、こちらの設定を試してみてください。

え?WordPressの管理画面て独自にカスタマイズできるの?

WordPress管理画面カスタマイズ

WordPress管理画面カスタマイズ

今回のテーマはWordPressの独自管理画面作成についてです。

WordPressには元々、管理者が使うための画面が用意されています。

精鋭の開発者が作成しているだけあってカスタマイズ性も高く、バージョン3.8からはレスポンシブデザインにもなっているため、サイトを管理するだけならこの管理画面だけで足りてしまう場合がほとんどです。

しかしながら、会員ログインなどを用意する会員制サイトとして運用したい場合や、複数の人間でサイトを管理していて特定の機能だけを使わせたい、といった場合に、最初から用意されている管理画面だけだと難しい場合があります。

会員制サイトの場合、通常のWordPressの管理画面だと入力チェックの仕組みや、メニューを自由にカスタマイズするなど、対応が難しい機能がいくつか存在すること、プロフィール編集画面などにも不必要な項目が残ってしまうことなどから、カスタマイズの労力の割には、完全自由にカスタマイズすることができません。

また、複数人のユーザーでWordPressを管理している場合に、「特定の機能だけを使わせたい」といった際にも権限管理を行えばある程度は実現できるのですが「ダッシュボード」や「プロフィール編集」など、不必要な項目が残ってしまうことは否めず、シンプルに運用したいといった場合には、WordPressの管理画面は逆に足かせになってしまうことがあります。

そこで是非提案したいのが、「独自管理画面を作ってしまおう」ということです。

▼WordPressの管理画面を構成する機能

WordPressには非常にたくさんの機能が用意されており、簡単に言ってしまえば、WordPressの管理画面もその機能を使って作られているにすぎません。

たとえば「is_user_logged_in()」という関数は、WordPressにユーザーがログインしているかどうか、というのを判断できます。

また「user_can()」という関数は、そのユーザーがどういったことができるのか、どういった権限を持っているかということを判断できますし、「wp_insert_post()」という関数は、プログラム側から任意に「投稿」を行うことができます。

このような機能を使って、「ログイン画面」「投稿画面」などを、「固定ページのテンプレート」として機能別に用意し、それぞれをWordPressの「固定ページ」として作成・登録していくことで、実は割と簡単に管理画面を作成することができてしまいます。

▼画面デザインはどうするの?

ここでひとつ問題となるのは管理画面のデザインです。

自分でゼロから作成してしまってももちろん問題無いのですが、ここは先駆者が作った便利なフレームワークを利用することで、さらにコストを下げることができます。

それが「Bootstrap」です。

以前は「TwitterBootstrap」と呼ばれていましたので、耳にしたことがある方は多いのではないでしょうか。

一昔前にとても話題に上ったウェブデザインのフレームワークですが、これが管理画面との相性がとても良いのです。

PHPでプログラミングを行う際に利用するフレームワークとして、有名なものに「CakePHP」や「FuelPHP」といったものがありますが、そういったフレームワークでも積極的に管理画面として利用されているのが、この「Bootstrap」です。

レイアウトのパーツから、フォームのパーツ、入力エラーが起きた際の表現からモーダルウィンドウのダイアログ、ページングのボタンなども含め、管理画面に必要な機能は最初からほとんどそろっており、あとはパーツを組み合わせてちょっとアレンジするだけ。

これだけで
「見た目もきれいで、使いやすく、 レスポンシブに対応したユーザビリティの高い管理画面」が、ササッと用意できてしまうのです。

▼工夫次第でいろいろなことができる

独自管理画面の有用性については理解していただけましたでしょうか?
下記では僕たちの作成した独自管理画面で、有用なものを紹介したいと思います。

1. GPS機能に連動した簡単登録フォーム

スマートフォンなどGPS機能が利用できる端末からの投稿限定ですが、現在の位置を投稿の情報として自動的に付帯し、WordPressに登録することが可能です。

WordPressにログインせずとも投稿できるように作成することで、一般のユーザーが任意に登録できるように作成しました。

写真の共有サイトやスポットの共有サイトなど、「位置情報」を活用したいサイトなどに非常に有用です。

2. 入力制限を設けた登録フォーム

WordPressの管理画面で入力制限を設けようとすると、元々入力制限の方法が管理画面側で用意されていないため、JavaScriptなどでチェックするか、WordPressのフィルターフックなどを用いて、多少手間のかかる方法でチェックをかける必要があります。

そこで、独自管理画面を用いることで、JavaScript等の不安定な要素に頼ることなく、簡単にチェックすることが可能です。

タイトルは●●文字以内、本文はHTMLタグを自動的に排除し●●文字以内、といったフィルター処理も含めた複雑な投稿画面を用意することが可能です。

3. 会員専用の管理画面

会員サイトを構築した場合、会員のプロフィール編集ページや、マイページ、課金処理などを用意する必要が出てきますが、独自管理画面はまさにそういった場合に最適な選択です。

こういった複雑な処理はWordPressの管理画面でやろうとすると、不自由な割にコストがかかってしまいます。

また、会員に「WordPressを使ってるんじゃん」という意識を与えてしまい、適切に権限管理をしていないと、不正な投稿などをされる恐れがあります。

例)投稿機能をメニューから隠しただけで、権限で規制をしていない場合、投稿画面のURLを直打ちされてしまうと投稿画面が表示されてしまい、そこからいくらでも不正な投稿を行うことができてしまいます。

すでに独自ウェブアプリケーションのプラットフォームになりつつある「WordPress」ですが、このようなカスタマイズの方法を知っておくことで、さらにオリジナリティが高く、セキュリティに配慮した堅牢なウェブサイトやアプリケーションを提供することが可能になります。

「WordPress」は「WordPress」だから、という先入観を捨てて、何でもできるウェブアプリケーションプラットフォームであるということを、是非ご理解いただければ幸いです。

なんで?WordPressエディタの不具合?

WordPress エディタ 不具合

WordPress エディタ 不具合

本日はWordPressで起こる「謎」について語っていきます。

以下はWordPressの「謎」について実際にやりとりを行った仲間内のチャットの内容です。

※回答はHP用に加工しました。

2014年3月17日 13:30
平野

>WordPressの別のテーマでもこの不具合起こること多々あるんです。
>私の中で、色々あるんです。WordPressの謎。tableの中のtd内にテキスト入れると、変なインデントが>入っちゃうとか。。改行されないとか、小さいことなんですけど

2014年3月17日 13:37
前島

>あー、わかります。謎ありますよね。
>HTMLを直接貼り付けたいのに、なぜかspanが全部消えちゃうとか私もあります。
>細かいことですけど、気になりますよねえ。

2014年3月17日 18:24
家富回答

それは改行をbrタグとpタグに自動変換している、wpautopという関数が悪さをしている可能性が高いです。

WordPressには記事の改行を<p>タグと<br />タグに変換する関数や、制御記号などを害の無い表現に変換する関数など、いろいろな関数が自動的に動作するようになっています。

これはCSRF攻撃などの被害に遭わないように対策をしていたり、不正なタグを除去したりと、いろいろなセキュリティの面を考えての対策となっています。

しかしながら、この自動変換の機能が悪い方向に作用することがあります。
その主な代表となるのが、冒頭でも紹介した「wpautop」という機能です。

この機能は、エディターで入力した改行を自動的にpタグとbrタグに自動変換し、レイアウトを調整してくれる機能なのですが、その自動的に挿入されるpタグが問題となります。

このpタグは改行が2連続している場合に、該当のエリアをpタグで囲むという機能なのですが、改行が2つ無くとも、インラインタグ(spanタグやaタグ、imgタグ)が単独で存在している箇所は、すべてpタグで囲ってくれるという厄介な機能になっています。

pタグは汎用的なタグなので、デザイン上もスタイルを割り当てている場合が多く、
それが全く意図していない箇所に突然挿入されてしまうため、画像がずれてしまったり、改行がおかしくなるなどレイアウト上の問題が発生します。

よくある例としては、imgタグをpタグで囲われてしまったために回り込みが聞かなくなってしまったり、tableタグのtdタグの中にまでtdタグの中にもpタグを挿入してくれるので、テーブルの中に余計な空白が生まれてしまうなど、枚挙に暇がありません。

以上のように結構苦しめられるこの機能ですが、簡単な解決方法があります。
PS Disable Auto Formattingというプラグインで、こちらのプラグインを利用することで、上記の機能を一括で無効にすることができます。

https://wordpress.org/plugins/ps-disable-auto-formatting/

お客様に納品する際など、ナイーブなエディタにお困りの際はこちらのプラグインなどを導入して対策してみてください。

全て裏側語ります!MovableTypeからWrodPressへの移行について

今回は、ご相談ご依頼を頂く事が多くなった、
MovableTypeからWordPressへの移行について、

私どもがどういった手順で移行を行っているかの、
具体的な手順と方法の裏側をご紹介いたします。

▼ステップ1 確認をする

まず、MovableTypeではバージョンによってサイトの構築方法が異なってくるため、
移植元のサイトがどのMovableTypeを利用しているかを確認します。

MovableTypeの主に利用されているバージョンとしては、
大きく分けると3、4、5の3つのバージョンがあります。

まず、バージョン3までは、
1つのMovableTypeで1つのサイトしか運用することができませんでした。
主にブログとしてのイメージが強かった時期です。

次に発表されたバージョン4から「マルチブログ」という機能が実装され、
1つのMovableTypeで多数のサイトを管理することができるようになりました。

この頃から、昨今では標準となっている「カスタムフィールド」の概念が導入され、
ブログとしてのイメージから「CMS」としてのイメージが強くなりました。

さらにバージョン5になると、ウェブサイトとブログという概念が導入され、
ウェブサイトにブログが所属するという構成となりました。

今までのブログというイメージから、完全にCMSという概念を全面に押しだし、
こンテンツを管理するための仕組みとしてアピールされるようになりました。

この3つのバージョンの違いをまずは確認し、どのバージョンが利用されているか、またその運用の形態から、最終的にWordPressでどのように管理するべきかを判断します。

▼ステップ2 設計をする

MovableTypeでどのバージョンが利用されているか、1つのMovableTypeでいくつのブログやサイトを運営しているかが確認できたら、次にそれをどのようにWordPressに当て込んでいくかを設計します。

例えばMovableType4で複数の全く別々のブログを利用している場合です。
この場合、以前同様に複数のブログを1つのWordPressで管理する、いわゆるマルチサイトで移植する方法が1つ。

・ブログA-A → ブログA-A
・ブログA-B → ブログA-B

また、各ブログを全く別々のアカウントで管理しているならば、1つのWordPressで管理するメリットも無いため、全く別々のWordPressとして管理するという方法もあります。

・ブログA-A → ブログA
・ブログA-B → ブログB

次に、MovableType5で1つのウェブサイトに、複数のブログを追加して運用している場合です。

この場合はいくつかの移植方法が考えられます。
例えば、ウェブサイトの「お知らせ」「よくある質問」「Q&A」などを、
ブログとして管理している場合。

この場合、それぞれのブログをいちいちマルチサイトで構築しなくとも、WordPressでは「カスタム投稿」という便利な機能がありますので、そちらに割り当ててしまうことで、複数のブログ管理という煩わしさから抜け出すことができます。

・ウェブサイト → ウェブサイト
・ブログA-A  → カスタム投稿A
・ブログA-B  → カスタム投稿B

URLの設計も忘れてはいけません。
2つのブログを別々のドメインで運用している場合などは注意が必要です。

MovableTypeでは1つのサーバーをマルチドメインで運用している場合でも、1つのMovableTypeで、それぞれのドメイン上のサイトを管理することが可能です。

しかしながらWordPressのマルチサイトを利用する場合、1つのサーバーに複数のサブドメインが割り当てられているという運用であれば問題無いのですが、もしマルチドメインとなった場合、対応することができません。

※厳密にはプラグインなどを利用することで対応することは可能ですが、
オフィシャルに対応している機能では無いためリスクを孕みます。

※サブドメインとは下記のように1つのドメインに複数のプレフィクス(aaa.やbbb.など)を用いたドメインのことを指します。
aaa.example.com
bbb.exmaple.com
ccc.exmaple.com

※マルチドメインとは下記のように複数の全く異なるドメインが1つのサーバーに割り当てられている状態のことを指します。
example.com
hogefuga.com
foobar.com

そのため、複数のドメインを1つのMovableTypeで管理している場合などは、
WordPressを分けて設置するなどの工夫が必要となってきます。

また、カスタム投稿を利用する場合やカスタム分類を利用する場合も、元のサイトのURL構造を確認した上で、以前と同様の構成となるように、スラッグ(URL文字列)の設定などを行います。

▼ステップ3 テーマ作成

ステップ2で設計した内容を元に、実際の構成をテーマファイルとして作成します。
MovableTypeのテンプレートを元に、WordPressのテーマファイルに落とし込んでいきます。

幸いなことにMovableTypeもWordPressも、MTMLなのかPHPなのかの違いはありますが、同様の構造をしている事が多いためよほどのことが無い限り、構成を保ったままテーマファイルを作成することが可能です。

※MTML ・・・ MovableTypeのテンプレートに利用されるマークアップ言語

▼ステップ4 移植用のテンプレートを作成

MovableTypeからWordPressに移植する場合、MovableType標準のエクスポート機能を利用すると考えてしまいがちですが、これは大きな落とし穴となります。

例えば、カスタムフィールドなどを利用している場合です。

MovableTypeのエクスポート機能はブログでの運用を元にしているため、
カスタムフィールドなどの細かな属性は、データに含まれません。

そのため、WordPress側で取り込もうとしても、
カスタムフィールドなどの情報を正しく取り込むことができません。

ここで、WordPressの記事データをエクスポートする際に作成される、
xml形式のデータに注目します。

WordPressが生成するxmlファイルには、各記事のタイトルや本文などの
データとは別に、カスタムフィールドのデータも全て記述されて出力されるため、
完全な形式でのエクスポートが可能となっています。

このデータはWordPress形式でのインポートとして利用する事ができるため、MovableType側でこの「WordPressがエクスポートに利用するフォーマット」を、再現することでカスタムフィールドを含めた完全なデータを、MovableTypeから移植することが可能となるのです。

ということで、MovableType側で必要なテンプレートを作成、再構築を行い、インポートするためのxmlファイルを生成します。

▼ステップ5 インポートとURLの修正

作成したxmlデータをWordPress形式のデータとしてインポートすると、記事のデータやカスタムフィールドのデータは、ほぼ正しくWordPressに取り込まれます。

しかし、MovableType側でアップロードした画像やファイルのURLなどは、この時点では以前のままのため、リンク切れなどが発生してしまいます。
そこで次に、ファイルの移動とURLの書き換えを行っていきます。

まず、MovableType側でアップロードしたファイルを、全てWordPress側で参照できる場所に移動(アップロード)します。

アップロードしただけでは各記事に埋め込まれたURLや、カスタムフィールドの値は書き換わっていませんので、合わせてそのURLを修正する作業を行います。

URLの修正を1つ1つ手動で行うのは、記事が多い場合あまり現実的な方法ではありません。
かといって、WordPressには便利な置換機能などが備わっていないため、この場合、データベースを直接書き換えて対応するのが最も効率的です。

しかしながら、直接SQLを使って修正してしまうと、WordPressのデータベースにはPHPのシリアライズされたデータが壊れてしまう場合があり、せっかく移植したデータが壊れてしまう場合があります。

そこで、WordPressを移設する際などに利用する、便利なデータ書き換えツールを利用します。

・Search Replace DB
http://inspire-tech.jp/2013/10/wordpress-search-replace-db/?utm_source=submitmail&utm_medium=26

※詳細な利用方法などをまとめた僕のブログをご覧ください。

このツールを利用して、記事中のリンクURLやカスタムフィールドのURLを、正しいURLに書き換えていきます。

▼ステップ6 URL構造の確認

ここまで来ればあと一息で移植完了です。
最後に、移植前のサイトと同様のURL構造をできる限り再現します。

WordPressでは通常、URLの末尾に.htmlなどの拡張子を付ける事ができません。
MovableTypeは静的ファイルを生成して管理する方法のため、多くの場合、URLの末尾には.htmlという拡張子がついているはずです。

そこで、プラグインの力を借りてこの問題を解決します。

【.html on PAGES】
https://wordpress.org/plugins/html-on-pages/?utm_source=submitmail&utm_medium=26

固定ページの末尾に強制的に .html の拡張子を取りつけます。

【Custom Permalinks】
https://wordpress.org/plugins/custom-permalinks/?utm_source=submitmail&utm_medium=26

投稿や固定ページ、各種カスタム投稿のURLを、
自由な構造に変更することができます。

上記2つのプラグインを用いる事で、
各種URLを任意の形式にまとめる事ができます。

唯一再現できないURLとして、
ページネーション(ページ切り替え)などが発生したときのURLについては、MovableTypeとWordPressでは完全に管理構造が違うため、再現することができません。

完全に一致をさせなくてはならない場合などは、注意をした方が良いでしょう。

▼最後に

以上、僕が行っている
MovableTypeからWordPressへの移行の手順と方法です。

こちらの方法を用いる事で、ある程度簡素なサイトであるなら、移植を行うことができるかと思います。

トミーがレスポンシブデザインを斬る!後編

前回に引き続き
レスポンシブデザインについて
語っていきたいと思います。

▼WordPress上でのレスポンシブデザイン

WordPress上でもデフォルトのテーマなどはレスポンシブデザインに対応し、積極的に利用しているサイトが増えています。

僕らがお客様からいただくご要望の中にも「レスポンシブデザインでお願いします」というのが非常に増えておりますが、デメリットの部分も含めると、安易にお勧めできません。

そこで僕らが提案しているのが、

「PC向けとスマフォ向けのテーマを用意する。」

という方法です。

WordPressでは

「アクセスする端末ごとにテーマを使い分ける。」

ということを簡単に実現することができます。

具体的にはAというPC向けのテーマと、

Bというスマフォ向けのテーマを用意しておいて、

アクセスしてきた端末がPCならばAのテーマをサイトに適用し、スマフォならばBのテーマをサイトに適用する。

という単純な方法です。

テーマファイルをPC向けとスマフォ向けに2つ作成しなくてはならないという
面倒な部分もありますが、レスポンシブデザインのデメリットに挙げた項目を、ほぼ全て払拭することができます。

PC向けとスマフォ向けで別々のHTML構造を用意することにより、

例えば高解像度で巨大な画像ファイルをPCで扱っていても、スマフォでは、プログラムで画像をリサイズすることで、ファイルサイズを圧縮して表示させることができます。

コンテンツの出し分けも同様で、PCでは200文字を表示させるが、スマフォでは
50文字しか表示しない、などとということが簡単に実現できます。

各デバイス向けのソースコードには、他のデバイス向けのソースコードは一切含まれないので、

スマフォ向けテーマなどモバイル環境からのアクセスを想定する場合は、非常にシンプルなコーディングにしておくことで、3G回線などの速度の遅い回線でもアクセスのしやすい環境を構築することができます。

またデザインのワークフローでも、レスポンシブデザインのように共通のデザインや、共通のコンテンツ部分をソースコードレベルで意識する必要がないので、自由にデザインができることもコストの削減につながります。

さらにこの手法では、スマートフォンユーザーが

「PC向けの画面を見たい」

といった場合にテーマを切り替える
インターフェースをつけることで、簡単に実現することが可能なため、ユーザービリティにも配慮したサイトにすることが可能です。

そうなってくるとワンソースマルチデバイスというメリットが全くないじゃないか!

と言われてしまいそうですが、ワンソースマルチデバイスのそもそものメリットは、
プログラムを使わない静的なサイトが、

「1つのHTMLソースで複数のデバイスに対応できる」という点であり、ユーザーの目線ではなく開発者目線でのメリットです。

これは、プログラムを利用できる環境ではメリットにはなりません。

なぜならば、プログラムを利用することで表示領域の制御や、画像サイズの制御などは、CSSなどでやるよりも簡単にできてしまうからです。

また「1つのソースを複数のデバイスに最適化する」という意味では、ソースの指す部分をHTML構造ではなくコンテンツの内容とするならば、こちらの方が利用するユーザーの目線に立った、本来の意味でのレスポンシブデザインではないかと思います。

トミーがレスポンシブデザインを斬る!前編

昨今のスマートフォンの普及率については、
ウェブサイトを作成する上ではスマートフォン対応はほぼ必須となってきました。

そこで数年前より注目されている、
レスポンシブデザインについて改めて説明したいと思います。

▼レスポンシブデザインとは 〜まずは基礎から〜

レスポンシブデザインとは端的に言えば、
1つのHTMLでPC、スマフォなど複数のデバイスに対応できるデザインのことです。

一昔前のサイトであれば、アクセスしてきた端末の情報から、プログラムで「OS」「ブラウザの種類」などを取得して判定し、プログラムで出力するデザインを切り替えるようなものが主流でした。

レスポンシブデザインの画期的なところは、
一切のプログラムを使わずに、CSSだけでこれが実現できるところです。

具体的には「メディアクエリー」という仕組みを用いて、
■「画面の幅が○○ピクセル以下になったら、このスタイルを適用する」
■「画面の幅が○○ピクセル以内だったら、このCSSを読み込む」

といった、画面の幅や高さを条件に適用するスタイルシートを変えることで、スマートフォンや、そのほかのデバイスに対応するといったものです。

▼レスポンシブデザインのメリット 〜トミーが感じるメリット〜

レスポンシブデザインのメリットは、ワンソースマルチデバイスを実現できることです。

読み込むCSSを変えていろいろなデバイスに対応するため、1つのHTMLだけで実現ができるということです。

これはGogoleからも推奨されている方法で、Googleがインデックスを作成しやすくなったり、クロールの効率が上昇するため、SEO上も効果があると言われています。

さらに、複雑なプログラムを利用する必要がなく、CSSだけの知識で対応することができるので、今までプログラムを利用したことのない制作者でも対応できます。

静的なHTMLのサイトにも後付けで導入することができ、上記のようにプログラムの設置もいらないため、非常に導入がしやすいというのもメリットです。

▼レスポンシブデザインのデメリット 〜トミーが斬る〜

プログラムがいらないことやHTMLレベルでワンソースマルチデバイスに対応できることから、非常に注目を集めているレスポンシブデザインですが、メリットばかりではありません。

まず1つは、どのデバイスでアクセスした場合も、すべてのソースコードを読み込んでしまうという点です。

たとえば画像などが良い例で、PC向けに高解像度で作った写真をサイトに配置していた場合、レスポンシブデザインではCSSを用いて画像の見た目の大きさを変更したり、非表示にするといったことしかできないため、実際にはすべてのデータを読み込む必要がでてきます。

端的に言えば、必要のない画像やHTMLソース、CSSなどをすべて読み込むため、3G回線などの転送速度が遅い回線を使っている場合、ネックとなる可能性があります。

もう一つは、デザインが非常に面倒ということです。
レスポンシブデザインにするということは、PC向けの画面もスマフォ向けの画面も、ある程度構成やデザインなどは同一にしなくてはなりません。

特性上、HTMLのソースコードは1つなので、それを如何にCSSで制御するかと言うことになるのですが、PCはPC向けの構造を用意して、スマフォで見たときはそれを非表示にする。

スマフォはその逆、といったように完全に別々の構造を複数用意してしまうと、上記の理由から転送速度の低い端末ではアクセスしづらいサイトとなってしまいますし、かといって同一にしすぎてしまうと、各デバイスへの最適化という部分が実現できなくなってしまいます。

そのため、デザインの設計段階でどこまでを共通化するか、どこをデバイスごとの差別化とするかを詳細に検討し、その上でデザインを行う必要があります。

各デバイス向けにコンテンツの出し分けがしにくいというのもあります。

PCはPC向けのコンテンツ、スマフォはスマフォ向けのコンテンツを1つのHTMLに入れ、CSSで表示・非表示を制御すると言ったことでは、結局のところ「ワンソースマルチデバイス」である必要性がありません。

同じコンテンツを複数のデバイスで
共通して利用できるところに価値があるのであって、そこを誤解してしまっては、そもそもの価値がなくなってしまいます。

ユーザービリティでも一部問題が発生します。

CSSで実現するレスポンシブデザインは、画面の横幅を絶対的な条件としてデザインを切り替えるため、スマートフォンの画面からでは、絶対にPC向けのデザインを確認することができません。
(画面の解像度を変えることができるならば別ですが・・)

スマフォからでもPC向けのデザインを利用したい!
というユーザーがいたとしても、強制的にスマフォ向けの画面が表示されてしまうため、利用する手段を提供することができません。

〜トミーがレスポンシブデザインを斬る!後編に続く〜

次回は「WordPress上でのレスポンシブデザインについて」
記事を書きますね。