Quantcast
Channel: 西沢直木のIT講座
Viewing all 415 articles
Browse latest View live

Advanced Custom Fieldsの画像オブジェクトの使い方

$
0
0

Advanced Custom Fieldsプラグインで画像フィールドを作る場合、返り値として画像URLや画像オブジェクトなどを選べます。要件を満たせばどちらでも構わないのですが、画像オブジェクトを使うと、アップロードした画像からサイズを指定して表示することができます。

画像フィールドの返り値は選べる

画像フィールドの返り値は選べる

アップロードした画像が大きすぎるので中サイズやサムネイル画像を表示したいときに役立ちます。

以下、画像オブジェクトの使い方を紹介します。

Advanced Custom Fieldsの「画像オブジェクト」の使い方

Advanced Custom Fieldsプラグインで画像のカスタムフィールド(ここでは店舗画像)を作成する際に返り値を「画像オブジェクト」にします。

画像フィールドを作成

画像フィールドを作成

カスタムフィールドを使う編集画面を開いて画像を追加します。

カスタムフィールドの画像を追加

カスタムフィールドの画像を追加

画像が追加されます。プレビューはサムネイルに設定したので小さく見えますが実際の画像は幅2000pxくらいのビッグサイズです。

画像が追加される

画像が追加される

そのまま表示したくないので、できれば中サイズ画像などを表示したいことがあります。

カスタムフィールドを表示するにはthe_field関数を使いますが次のように記述してもうまくいきません。

<?php the_field("image"); ?>

具体的には次のように意味不明な文字が表示されます。

画像フィールドの表示に失敗した例

画像フィールドの表示に失敗した例

文字の内容を見ると画像のURLなどが入っているように見えるので、その内容をいったん取り出してから表示するというステップが必要です。

それには、the_field関数の代わりにget_field関数を使います。

具体的なコードは後回しにしますが、get_field関数を使うと、次のような情報が返されます。少し変った構造に見えるかもしれませんが、これはPHPの「配列」という形式のデータです。

Array
(
[id] => 319
[alt] => 
[title] => a
[caption] => 
[description] => 
[mime_type] => image/jpeg
[url] => http://…/wp-content/uploads/2018/03/a.jpg
[width] => 2000
[height] => 1318
[sizes] => Array
    (
    [thumbnail] => http://…/wp-content/uploads/2018/03/a-150x150.jpg
    [thumbnail-width] => 150
    [thumbnail-height] => 150
    [medium] => http://…/wp-content/uploads/2018/03/a-300x198.jpg
    [medium-width] => 300
    [medium-height] => 198
    [medium_large] => http://…/wp-content/uploads/2018/03/a-768x506.jpg
    [medium_large-width] => 640
    [medium_large-height] => 422
    [large] => http://…/wp-content/uploads/2018/03/a-1024x675.jpg
    [large-width] => 640
    [large-height] => 422
    [post-thumbnail] => http://…/wp-content/uploads/2018/03/a-200x200.jpg
    [post-thumbnail-width] => 200
    [post-thumbnail-height] => 200
    )
)

ここからデータを取り出すにはPHPの配列についての知識が必要ですが、「sizes」以下に画像のサイズらしき文字やURLが入っていることに気づけば大丈夫です。

たとえば、「medium」には中サイズ画像のURLが入っているようなので取り出してimgタグを組み立ててみましょう。具体的には次のようなコードになります。

<?php
$image = get_field("image");
?>
<img src="<?php echo esc_attr($image['sizes']['medium']); ?>">

これにより、次のようなimgタグが組み立てられます。

<img src="http://…/wp-content/uploads/2018/03/a-300x198.jpg">

画像のURLに「-300x198」が付いていることから中サイズ画像だとわかります。結果として、中サイズの画像が表示されます。

カスタムフィールドの画像が表示される

カスタムフィールドの画像(中サイズ)が表示される

あとは使いたいサイズに応じて上記のコードを書き換えれば大丈夫です。各サイズの画像を表示するためのコードをまとめておきます。

  • サムネイル画像:
    【コード】
    <img src="<?php echo esc_attr($image['sizes']['thumbnail']); ?>">
    【実行結果の例】
    <img src="http://…略…/wp-content/uploads/2018/03/a-150x150.jpg">
  • 中サイズ画像:
    <img src="<?php echo esc_attr($image['sizes']['medium']); ?>">
    【コード】
    【実行結果の例】
    <img src="http://…略…/wp-content/uploads/2018/03/a-300x198.jpg">
  • 大サイズ画像:
    【コード】
    <img src="<?php echo esc_attr($image['sizes']['large']); ?>">
    【実行結果の例】
    <img src="http://…略…/wp-content/uploads/2018/03/a-1024x675.jpg">
  • フルサイズ画像:
    【コード】
    <img src="<?php echo esc_attr($image['url']); ?>">
    【実行結果の例】
    <img src="http://…略…/wp-content/uploads/2018/03/a.jpg">

WordPressの条件分岐・定番の10パターン

$
0
0

WordPressでif文と条件分岐タグを使うと条件に応じて表示を切り替える(条件分岐)ことができます。たとえば、特定のページのみに表示したいパーツや、PCとスマホで別々のパーツ、ログインユーザーと非ログインユーザーで異なるパーツなどを作成できます。

ここでは、if文と条件分岐タグを使って違う内容を表示するコードの例をいくつか紹介します。

特定の固定ページで分岐する

特定の固定ページか判断するにはis_page関数を使います。以下の例ではスラッグがcompanyまたはcontactのページのみで表示されるブロックを作成しています。

<?php if(is_page(array('company', 'contact'))) : ?>
スラッグがcompanyまたはcontactのページで表示される

<?php else : ?>
それ以外のページで表示される

<?php endif; ?>

分岐対象ページが1つだけの場合はis_pageの部分を「is_page('company')」または「is_page(array('company'))」とします。

紛らわしいのでご注意ください。1行目は次のようになります。

<?php if(is_page('company')) : ?>

または

<?php if(is_page(array('company'))) : ?>

です。

親ページか子ページで分岐する

表示中のページが親ページなのか子ページなのか判断するには$postのpost_parentプロパティを調べる方法があります。子ページの場合はpost_parentに親ページのIDが入ってきます。親ページの場合はpost_parentが0になります。つまり、post_parentが0の場合は親ページ、それ以外は子ページとして分岐できます。

<?php
$parent_id = $post->post_parent;
if(is_page() && $parent_id) : ?>
子ページで表示される

<?php elseif(is_page()) : ?>
親ページで表示される

<?php endif; ?>

ここで分岐した「親ページ」は親がない(post_parentが0)のページというだけで、子ページを持つかどうかは判定していないので用途によっては注意が必要です。

「&&」は「条件A かつ 条件B」(両方の条件を満たす)を指定するときに使う記号です。

トップページとサブページで分岐する

トップページか判断するにはis_front_page関数を使います。ヘッダー画像のようにトップページのみで表示したいブロックに使われます。

<?php if(is_front_page()) : ?>
トップページで表示される

<?php else : ?>
それ以外のページで表示される

<?php endif; ?>

使用中のテンプレートで分岐する

指定テンプレートが現在適用されているか判断するにはis_page_template関数を使います。

「テンプレート」に応じて分割したい

「テンプレート」に応じて分割したい

通常は「デフォルトテンプレート」ですがテンプレートに応じて処理を切り替えることができます。

<?php if(is_page_template('page-lp.php')) : ?>
テンプレートがpage-lp.phpのページで表示される

<?php else : ?>
それ以外のページで表示される

<?php endif; ?>

特定カテゴリーの投稿で分岐する

投稿が特定のカテゴリーに属するか判断するにはin_category関数を使います。現在のページが個別記事か判断するis_single関数と組み合わせて使います。

現在のページが
個別記事か(is_single)
特定のカテゴリーに属するか(in_category)
という2つの条件を組み合わせます。

<?php if(is_single() && in_category(array('news', 'event'))) : ?>
newsまたはeventカテゴリーに属する投稿で表示される

<?php elseif(is_single()) : ?>
それ以外の投稿で表示される

<?php endif; ?>

特定のカテゴリーページで分岐する

上記の例と紛らわしいですが、現在表示中のページが特定のカテゴリーアーカイブページ(記事一覧)か判断するにはis_category関数を使います。

<?php if(is_category(array('news', 'event'))) : ?>
newsまたはeventのカテゴリーページで表示される

<?php elseif(is_category()) : ?>
それ以外のカテゴリーページで表示される

<?php endif; ?>

タクソノミーアーカイブで分岐

投稿のアーカイブではなくカスタムタクソノミーのアーカイブページで分岐するにはis_tax関数を使います。

<?php if(is_tax(array('eigyo', 'tenpo'))) : ?>
eigyoまたはtenpoのタクソノミーアーカイブで表示される

<?php elseif(is_tax()) : ?>
それ以外のタクソノミーアーカイブで表示される

<?php endif; ?>

アイキャッチ画像の有無で分岐する

アイキャッチ画像を持つか判断するにはhas_post_thumbnail関数を使います。以下の例では投稿かどうかを判断するis_single関数と組み合わせて、アイキャッチ画像を持つ投稿かどうかで分岐しています。

<?php if(is_single() && has_post_thumbnail()) : ?>
アイキャッチ画像を持つ投稿で表示される

<?php elseif(is_single()) : ?>
それ以外の投稿で表示される

<?php endif; ?>

ログイン中かどうかで分岐する

ページを見ているユーザーがログイン中かどうかで分岐するにはis_user_logged_in関数を使います。

<?php if(is_user_logged_in()) : ?>
ログイン中のユーザーに表示される

<?php else : ?>
非ログインユーザーに表示される

<?php endif; ?>

PCとモバイル端末で分岐する

PCとスマホ(モバイル端末)で分岐するにはwp_is_mobile関数を使います。モバイル端末(スマホ・タブレット)とそれ以外で分岐します。

次の例のwp_is_mobileの前にある「!」は条件を反転させる記号です。これにより、「モバイル端末以外は」という条件になります。PCのみで表示したいブロックを作る場合はこのように分岐します。

else以下がモバイル端末で表示されるブロックです。

<?php if(!wp_is_mobile()) : ?>
PCで表示される

<?php else : ?>
モバイル端末(PC以外)で表示される

<?php endif; ?>

WordPressの条件分岐のコードを生成できる条件分岐ジェネレータを用意しました。ご活用ください。

【WordPress制作用ツール】条件分岐ジェネレータはこちら

Excelで作成した投稿をWordPressにインポートする方法

$
0
0

Excelで作成された投稿をWordPressにインポートする方法を紹介します。WP All Importプラグインを使えば簡単にインポートできます。

以下、手順を紹介しますが、お試しする場合、まずは数件のデータで試してみることをおすすめします。いきなり膨大なデータをインポートして「失敗した!」にならないようにご注意ください。

Excelの投稿をWordPressにインポート

たとえば、次のように投稿がExcelファイルで作成されているとします。A列がタイトル、B列が本文という構成です。

Excel形式で作成された記事

Excel形式で作成された投稿

このデータをインポートするため、「プラグイン」‐「新規追加」メニューからWP All Importプラグインをインストール、有効化します。

WP All Importプラグインのインストール

WP All Importプラグインのインストール

インポートするExcelファイルをアップロードするため、「All Import」‐「New Import」メニューを開いて「ファイルをアップロード」をクリックします。

「ファイルをアップロード」をクリック

「ファイルをアップロード」をクリック

Excelファイルを選択すると、アップロードが始まります。

Excelファイルを選択

Excelファイルを選択

アップロードの完了後、「新しいアイテム」「投稿」が選択されていることを確認してステップ2に進みます。

ステップ2に進む

ステップ2に進む

ステップ2では不要なデータを除外できますが、ここでは全てインポートするので何もせずステップ3に進みます。

ステップ3に進む

ステップ3に進む

Excelファイルの投稿からタイトル列・本文列を指定する画面が開きます。

タイトル・本文を指定する画面

タイトル・本文を指定する画面

タイトルから指定してみます。それには、画面右側のExcelファイルからタイトルが入力されている「undefined」を画面左側のタイトルにドラッグアンドドロップします。

タイトル列をドラッグアンドドロップ

タイトル列をドラッグアンドドロップ

タイトルに「{undefined0[1]}」と入力されます。これで、Excelファイルに入力されたタイトルがWordPressの投稿タイトルにインポートされる設定が完了です。

Excelの入力内容がタイトルにインポートされる設定

Excelの入力内容がタイトルにインポートされる設定

同じように本文が入力された列(ここでは「undefined1」)を本文にドラッグアンドドロップします。

本文の列をドラッグアンドドロップ

本文の列をドラッグアンドドロップ

画面を下にスクロールして、必要に応じて投稿のカテゴリーを設定します。それには、「タクソノミー、カテゴリー、タグ」をクリックして画面を開き、インポートする投稿のカテゴリーを設定します。

インポートする投稿のカテゴリーを設定

インポートする投稿のカテゴリーを設定

画面を下にスクロールしてステップ4に進み、データを識別する番号が入った列を指定します。よくわからなければ「自動検知」をクリックします。

データを識別する列を設定

データを識別する列を設定

画面を下にスクロールして「続行」をクリックし、開いた画面で「インポートの確認&実行」をクリックします。

インポートの実行

インポートの実行

問題なければインポートが完了します。

インポート完了

インポート完了

投稿一覧を確認すると、Excelファイルに入力した記事が1件ずつの投稿として作成されています。

インポートされた投稿

インポートされた投稿

これでExcelファイルからWordPressへの投稿のインポートは完了です。あとはいつも通りに編集画面を開いて投稿を編集できます。

WordPress誕生15周年記念!「PHPとWordPressと私の履歴書」

$
0
0

5月27日はWordPressの誕生日、2018年で15周年です!

1990年代にホームページ作成ブームが起きてから2003年にWordPressが誕生するまでには、CGIが生まれ、ASPが生まれ、PHPが生まれ、、、さまざまな技術が覇権を争い、「戦国時代」を経て今があります。

ここではWordPress誕生15周年を記念して、私の記憶を振り絞って1990年代からWordPress誕生までの時代背景を振り返ってみたいと思います。そのころ私が何をしていたかもオマケで書いてありますが、半分ウソだと思って気にしないでください。

HP作成の流行とHP作成ソフトの隆盛

時代は1990年代、インターネット網の整備と共に流行し始めたホームページ作成

世界中に情報発信!会社も個人もホームページ作成にチャレンジする時代の幕開け!

とはいえ、HTMLを手書きするのは難しい、、、そんなユーザーのために、強力なツールが誕生!

それがホームページ作成ソフト(Webオーサリングツール)です。

HTMLの文法がわからなくても簡単・手軽にホームページ作成できるというコンセプトに多くのユーザーが飛びつき、1994年リリースのホームページ・ビルダーや1997年リリースのDreamweaverなどによる激しいシェア争いが繰り広げられました。

【参考】Adobe Dreamweaver - Wikipedia
【参考】ホームページ・ビルダー - Wikipedia

「静的ページ」から「動的ページ」へ

手軽にホームページ作成できるようになるとユーザーのニーズも進化。

「会社概要」や「サービス紹介」のような内容が固定の「静的な」ページだけでなく、問い合わせフォームや掲示板、予約管理システムなど「動的な」ページも作りたい!

とはいえホームページ作成ソフトは主に静的ページを作るツール。動的ページ作成には別の技術を頼る必要がありました。

動的ページの作成に使われた「CGI/Perl」

ホームページ作成ソフトの弱点を補完する技術として動的ページの作成に使われていたのがPerlというプログラミング言語によるCGIという技術。

静的ページはホームページ作成ソフトで作成し、動的ページはCGI/Perlで作成。そんな協力関係が確立されていったのが1990年代です。

【参考】Perl - Wikipedia

CGI/Perlの弱点は「HTMLとの親和性」

ホームページ作成ソフトの弱点を補完できるCGI/Perlにも弱点が。

それは、プログラミング経験が少ないWebデザイナーさんには親しみにくいこと。

Perlはホームページ作成用の言語ではなく、言語仕様が複雑でした。

また、この時期のPerlはデータベース連携機能が弱かったり、サーバーに高い負荷をかけてしまう特性からレンタルサーバーで使用制限がかけられるなど、技術的な課題も。

この頃、フリーのエンジニアとして独立、2000年問題の尻ぬぐいをしていた私にもPerlはわかりにくく、、、

「もっと簡単に動的サイトを作れる技術はないのか?」と模索していたのは私だけではないでしょう。

HTMLとの親和性が高い「ASP」の登場

そんな中で2000年前後に注目を浴びたのがASP(Active Server Pages)。

マイクロソフトが1996年に開発した技術で、掲示板のような動的ページを作成できる点はCGI/Perlと同じですが、大きな特徴はHTMLとの親和性の高さ。

HTMLにタグを埋め込むようにプログラムを記述できるので、HTMLタグの編集に慣れたデザイナーさんも親しみやすく。

<html>
<head>
<title>Hello World</title>
</head>
<body>
<%
'文字列を表示します。
Response.Write "Hello World"
%>
</body>
</html>

マイクロソフトの技術なのでSQL ServerやAccessなど人気のデータベースと連携する機能も充実しており、Webアプリケーション開発の現場でもASPが使われるようになり、誰もが知っている価格検索サイトで採用されるなどして人気を博しました。

【参考】Active Server Pages - Wikipedia

私も「これは面白い!」と飛びついてASPの解説サイトなどを作っていた中、某価格検索サイトの創業者から声をかけられてシステム開発を受注したり、、、

ASPの流行に乗って、こんな本を書いたり、、、

ASPポケットリファレンス(2001年発刊)
ASPによるWebアプリケーションスーパーサンプル(2001年発刊)

この頃はコンピュータ本が売れた時代です。

なにしろ、Google.co.jpが登録されたのが2001/03/22、Yahoo.co.jpが2000/11/17という時代。

「わからないことはググって調べる」時代ではなかったので。

コンピュータ関連本を書いている私にとっては良い時代でした。

さて、私の身の上話はさておき、そんなASPが一部で流行していたのが2000年ごろ。WordPress誕生の3年前です。

ASPを凌駕した「Linux+PHP連合」

その後、ASPが爆発的に普及したかと言えば、そうではありません。あくまで「一部での流行」と言わざるを得ない弱点があったのです。

それは、主にWindowsサーバーで動作するという点。

そのため、当時からUNIX/Linux系のOSを採用していた多くのレンタルサーバーではサポートされず、、、

面白い技術でありながら、一部のレンタルサーバーや、Windowsが多い企業内のイントラネットでのアプリケーション開発に用途が限定されてしまった感があります。

そんな中、ASPを凌駕する勢いで頭角を現してきたのがPHP。WordPressの動作基盤となるプログラミング言語です。

ASPと同じようにHTMLに埋め込める手軽さがメリットで、WindowsでもLinuxでも動作する点がASPとの違いです。

【参考】PHP (プログラミング言語) - Wikipedia

そんなこともあって、エンジンが改良されたPHP 4のリリース(2000年5月)を機に多くのレンタルサーバーで使用可能になり、2002年ごろから爆発的に人気が上昇しました。

プログラミング言語人気ランキング(TIOBE index)

プログラミング言語人気ランキング:2002年ごろからPHPの人気が沸騰!

TIOBE index より引用)

「Linux+PHP連合」はLAMP(Linux/Apache/MySQL/PHP)というキーワードでまとめられ、Webアプリ開発ならPHP、そんな時代になりました。

ちなみに、

  • Linux --- OS
  • Apache --- Webサーバー
  • MySQL --- データベース
  • PHP --- プログラミング言語

です。

これだけあればWebアプリ開発できるパッケージというわけです。

そんなLAMPが世の中に広まるにつれて「PHPで面白いシステムを作ってやろう!」という熱気がみなぎっていた時代とも言えます。

MACでも動作することからデザイナーが作ったデザインにエンジニアがプログラムを埋め込むという協業もスムーズで「Webアプリ開発ならPHP」という流れができた時期でもあります。

そのころASPに心酔していた私も2002年ごろにはPHP隆盛の臭いをかぎ取り、あっさりPHPに乗り換えてこんな本を書いていました。

PHPによるWebアプリケーションスーパーサンプル(2002年発刊)

そして、この本を本格的に宣伝すべく取得したのが当サイトの「nishi2002.com」というドメインです。どうでも良い話ですが、、、

動くだけのプログラムから「開発の効率化」へ

さて、私の身の上話はさておき2002年、PHPの人気が大爆発。

一気に増えたPHPユーザーが次に考えたのは開発の効率化です。

単にシステムを作るだけでなく、「できるだけ簡単に作りたい」もっと言えば「できるだけコードを入力せずに作りたい」というニーズです。

コードは短い方が良い。これはプログラミングの鉄則ですよね。それだけ作業時間もミスも減りますし。

そんなニーズを満たすべく、開発者向けに流行したのがフレームワークです。

簡単な命令で複雑な処理を呼び出せるというコンセプトで、同じような処理のために長いコードを何度も書かなくても済むのが大きなメリットです。

Zend FrameworkやCakePHP、CodeIgniterなどが誕生し、PHPフレームワーク戦国時代に突入。

その戦国時代に私が注目したのは開発者向けのフレームワークではなく、いまふたたびのDreamweaverです。

なぜ今さらDreamweaverに注目したのか?

それは、この時期のDreamweaverに組み込まれたサーバービヘイビアー機能。

メニュー操作でPHPのコードをWebページに差し込めるという画期的な機能です。

静的ページから動的ページまで作成できるようになったDreamweaver。

「今こそDreamweaverだ!」と思って私が書いたのがこの本です。

PHP+MySQL Web制作ガイド featuring DREAMWEAVER MX 2004

我ながら目の付け所はバッチリ。会う人が皆、「あの本、面白いですよね」と絶賛してくれたにも関わらず、この本は思ったほど売れませんでした、、、

なぜ売れなかったのか。今考えると着眼点は良かったのですが、多くのユーザーのニーズにマッチしていなかったかもしれません。

開発者はフレームワークを求める一方で、多くのユーザーは効率化の手段としてDreamweaverではなく「CMS」という別の仕組みに飛びついたのです。

一般的なユーザーはプログラミングを効率化したいわけではなく、最終成果物の作成を効率化したかったのです。このニーズを読み違えました。

効率化の終着点「CMS」、そして「WordPress」の誕生

フレームワークが誕生してWebアプリケーション開発の効率化にしのぎを削る中、効率化の矛先は「Webサイト制作の効率化」に向けられることになります。

その一端がDreamweaverのサーバー機能だったのですが、どうせならホームページ自体を管理画面から作ってしまえば良いという発想で生まれてきたのが「CMS」(コンテンツ管理システム)という仕組み。

DreamweaverなどのようにPCにインストールされたソフトウェアを使ってホームページを作るのではなく、ブラウザから管理画面にアクセスしてページを組み立てるという画期的なシステムです。

専門知識がなくてもメニューを操作していけば成果物(ホームページやショッピングサイトなど)ができてしまうというのが大きなメリットです。

1990年ごろにHTMLを書いて泣きながら徹夜でホームページを作っていた方から見ると、「なんて時代だ!」と叫びたくなるかもしれませんが、あれから20年たってないんですよね。技術の進歩は速い、、、

当時、Webアプリ開発の主流派だったPHPをベースに動作するCMSがいくつも開発されて、、、2003年5月27日、WordPress(バージョン0.7)の誕生です!

当時、Dreamweaverのサーバー機能のことで頭が一杯だった私は、WordPressの存在を知りませんでした、、、

CMS普及を後押しする「ブログ文化」の誕生

WordPressも誕生して注目が集まったCMSですが、ユーザー向けには「ブログ」という名称で普及していくことになります。

「CMSを使ってコンテンツをシステムで管理しよう!」よりも「ブログを書いて世界に情報発信しよう!」の方が圧倒的にユーザー層の裾野が広がりますよね。

ブラウザから管理画面にアクセスできればいつでも誰でもどこからでも記事を投稿できる時代の幕開けです。

「誰が他人の日記なんか見るのか?」という意見もあったものの、誰でも手軽に情報発信できるとあって、ブログは誕生からユーザー数を急速に伸していきます。

そんなわけで2003年はブログ元年ともよばれます。

WordPressだけでなくSeesaa ブログ、livedoor Blog、ココログなど、国内の主要ブログサービスが誕生した年でもあります。

ちなみに、今ではブログの代名詞とも言える(言えない?)アメブロが誕生したのは2004年9月15日です。

一気にブログユーザーが増えたことで何が起きたか?

難しく言えばブログを通してCMSのユーザー教育ができた、とも言えます。

要するに、本当は難しいかもしれないCMSに慣れ親しみ、楽しみながら使う練習ができた、というわけです。

それにより、WordPressのようなCMSを利用したシステムやサービスを使うためのハードルが低くなった。

つまり、WordPressを検討しているユーザーに「ブログを書くのと同じですよ」の説明が通じる。これはWordPressの普及にとって非常に大きかったと思います。

ブログ型ホームページ作成ツール「WordPress」の繁栄

ブログが普及すると徐々に出てくる「ブログだけじゃ物足りない」というニーズです。

ブログを擬似的にホームページとして活用するユーザーも増えてきましたが、あくまで「ブログ」なのでしっくりいきません。

そんな中で徐々に注目度を増したのがWordPress。ブログを作るようにホームページを作成できるのが大きな特徴です。

ブログ型ホームページ作成ツールなどと表現されながら着実にユーザー数を増やしていき、その後の発展はご存じの通りです。

GoogleトレンドによるとWordPress誕生の5年後の2008年ごろにはWordPressがDreamweaverの人気を逆転。ホームページ作成ツールとしてナンバーワンの地位に上り詰めたと言っても良いでしょう。

WordPressとDreamweaverの人気度の比較

WordPressとDreamweaverの人気度の比較(Googleトレンドより)

WordPressの今、そして未来

以上、WordPressが誕生してDreamweaverの人気を逆転した2008年頃までの歴史を主観100%で振り返ってきました。

さまざまな技術が登場して発展したり衰退したり、まさに戦国時代の様相でしたね。

その後の戦国絵巻も気になるかもしれませんが、話が長くなったのでひとまず終わりにします。

WordPressが大流行に至ったのはWordPress自体の素晴らしさもありますが、PHPの大流行ブログ文化の大発展が大きな要因です。

WordPress誕生の2003年には、このような時代が来ることは全く想像できませんでした。ですから15年後にどうなっているのか、全く想像できません。

WordPressがバージョン10くらいまで進化しているのか、WordPressに代わるCMSが大流行しているのか、CMSに代わる想像もつなかい技術が流行しているのか、全く想像できません。

「ブログとかWordPressはもう古い!今はSNSの時代ですよ」と思っている方。半分は賛成しますが、結局は「CMS」という枠組みの中で踊らされているだけです。その仕組みは2000年ごろから変っていないのです。

WordPressやSNSのベースとなるCMS文化がどこまで続くのか、CMSに代わる新機軸が生まれてくるのか、WordPress誕生30周年を楽しみに、世の中の変遷を見ていきたいと思います。

WordPressで子テーマを作るメリットとデメリット

$
0
0

WordPressで子テーマが必須かどうかは議論が分かれますが、本格的にカスタマイズするなら子テーマを使うのが一般的です。ただし、メリット100%というわけではありません。デメリットもイメージしておきましょう。

子テーマを使うメリット

子テーマを作ってカスタマイズするメリットはカスタマイズ内容が消えずに済むことです。

子テーマを使わず親テーマのファイル(CSSやPHPなど)を直接カスタマイズしてしまうと、「外観」-「テーマ」メニューで「更新」ボタンをクリックした時点でカスタマイズ内容が消えてしまいます。

子テーマを使ってカスタマイズしておけば、このような悲劇を避けることができます。

親テーマと子テーマは別フォルダなので、親テーマを更新しても子テーマフォルダ内のファイルには影響しないからです。

ただし、子テーマフォルダ内のファイルをカスタマイズしていることが大前提です。

子テーマを作ったのに相変わらず親テーマのファイルを修正していると、更新後の悲劇が待っています。

子テーマを使うデメリット

いつでも子テーマを使えば良いかと言えば、微妙な部分もあります。

たとえば、テーマのオプションメニューや「外観」-「カスタマイズ」メニューで設定した画像やスライドショー、色設定などは、子テーマに引き継がれない場合があります。

ですから、ある程度サイトが完成したタイミングで子テーマを導入すると、ヘッダー画像やスライドショーなどがリセットされてしまい、設定のやり直しが必要になる場合があります。

納品直前での「念のため子テーマを作っておこう」は慎重に検討する必要があります。余計な工数が増えてしまいます。

また、テーマによっては子テーマ作成が単純ではない場合があります。勉強にはなりますが、急いでいるときは変な汗をかくだけなので、おすすめしません。

納品直前でもどうしても子テーマが必要な場合

納品直前であっても、どうしても子テーマを導入せざるを得ない場合、次のような代替手段も検討しましょう。

CSSをカスタマイズしたいなら、「外観」-「カスタマイズ」メニューの「追加CSS」を使う方法があります。子テーマを使わずにCSSをカスタマイズできます。

functions.phpの修正が必要なら、
カスタマイズ用の空プラグイン「free-customize」のようなプラグインを使う方法があります。

子テーマを導入しなくても、オリジナルのPHPコードを入力することができます。

まとめ

本格的なカスタマイズに子テーマは役立ちますが、無駄な工数が増える場合があるので、作るタイミングには注意が必要です。もしも将来的にサイトをカスタマイズしていく予定なら、サイトを作り始めたころに子テーマを作ってしまうのが無難です。

「送信されたURLにnoindexタグが追加されています」と表示されるとき

$
0
0

Google Search Consoleからインデックスカバレッジの問題として「送信されたURLにnoindexタグが追加されています」とメッセージが届くことがあります。

「送信されたURLにnoindexタグが追加されています」

「送信されたURLにnoindexタグが追加されています」

インデックス カバレッジは Google 検索結果で悪影響を受ける可能性がございますと書かれているので気になりますよね。

インデックス カバレッジ」は Google 検索結果で悪影響を受ける可能性が

インデックス カバレッジ」は Google 検索結果で悪影響を受ける可能性が

警告ではないので焦る必要はありませんが、対策を紹介します。

noindexとは

noindexとは簡単に言えば「検索結果に出さないで」の指定です。サイト制作者が設定することができます。

SEOで不利になりそうなページや、検索結果に出てほしくないページにnoindexを設定するような用途です。

Google Search Consoleの「送信されたURLにnoindexタグが追加されています」とは、あなたのサイト内で「検索結果に出なくて良い」(noindex)と指定されたページがありますよ、のお知らせです。

警告ではないので、理解してnoindexに設定した記憶があれば放置しておいても構いませんが、うっかり検索結果に出さない設定を解除し忘れていることもあります。

検索結果に出さない設定になっていないかチェック

大丈夫だと思いますが、「設定」‐「表示設定」メニューの「検索エンジンがサイトをインデックスしないようにする」がチェックされていないか確認しましょう。

検索結果に出ない設定

検索結果に出ない設定

チェックされていると基本的には検索結果に出ません。「送信されたURLにnoindexタグが追加されています」のメッセージの原因にもなります。検索結果に表示してほしければチェックを外してください。

個々のページがnoindexになっていないかチェック

All in One SEO Packのようなプラグインを使うと、個々の投稿や固定ページをnoindexに設定できます。

個々の投稿や固定ページのnoindex設定

個々の投稿や固定ページのnoindex設定

理解してnoindexに設定したのであれば問題ありませんが、検索結果に出ないと困る場合はチェックを外しておきましょう。

なぜか「noindexにすればSEOに効果的で検索順位が上がる」のようなテクニックの本質を理解せずに、いろいろなページをnoindexに設定されている方がいるようなので、十分にご注意ください。

sitemap.htmlが作成されていないかチェック

意外なところでGoogle XML Sitemapsプラグインが原因の場合があります。

「設定」‐「XML-Sitemap」メニューの「基本的な設定」で「HTML形式でのサイトマップを含める」がチェックされていると、sitemap.htmlというHTML形式のサイトマップが出力されます。

HTML形式のサイトマップが作成される

HTML形式のサイトマップが作成される

このHTML形式のサイトマップは検索結果に出る必要がないのでnoindex設定になっており、Google Search Consoleで「送信されたURLにnoindexタグが追加されています」になります。

通常はこのsitemap.htmlは不要です。チェックを外しておきましょう。

これでnoindexのメッセージは消えるはずです。

これらのnoindex解除についてはリアルタイムで反映されるわけではないので、検索結果に出てくるまで、しばらく時間が必要なこともあります。

WordPressで「外観」-「テーマの編集」メニューが表示されないとき

$
0
0

WordPressで「外観」-「テーマの編集」メニューが表示されないことがあります。焦るかもしれませんが原因は単純です。ここでは、一般的な理由を2つ紹介します。

「テーマの編集」が表示されるのは管理者だけ

現在ログイン中のユーザー権限が管理者ではなく編集者や投稿者などの場合、「外観」-「テーマの編集」メニューは表示されません。

たとえば、編集者権限のユーザーがログインするとダッシュボードのメニュー構成は次のようになります。

編集者に「外観」-「テーマの編集」は表示されない

編集者に「外観」-「テーマの編集」は表示されない

現在のユーザーが管理者かどうか確認しましょう。

マルチサイトの子サイトでは「テーマの編集」を使えない

WordPressをマルチサイトにしている場合、子サイトではテーマを選べるだけで、「テーマの編集」はできません。

現在使用中のテーマは全サイトで共通です。

マルチサイトで「テーマの編集」を使うには、サイトネットワーク管理画面から開く必要があります。子サイトの「外観」メニューに「テーマの編集」はありません。

サイトネットワーク管理画面と子サイトの「外観」メニュー

サイトネットワーク管理画面と子サイトの「外観」メニュー

また、念のため書きますが、テーマをカスタマイズする場合は「外観」-「テーマの編集」メニューではなくFTPを使ってダウンロードしたテーマファイル(CSSやPHP)をテキストエディタで編集した方が安全です。

WordPressのテンプレートを編集するときの注意点

WordPressでCSSが反映されないときのチェックポイント

$
0
0

「WordPressでCSSを変更しても反映されない」とか「style.cssを修正しても表示が変わらない」は多くの方が悩む問題です。当サイトでも何度か記事を書いていますが相談が多いので、ここでも簡単に原因と対策をまとめておきます。

テーマのstyle.cssは変更しない方が良い

そもそも「テーマのstyle.cssを変更したのに反映されない」に悩んでいる方へ。

テーマ(親テーマ)のstyle.cssを直接修正するのはおすすめできません

なぜなら、現在見ている画面の色や文字の大きさ、余白などのスタイルはテーマのstyle.cssによるものとは限らないからです。

現在表示中の画面には多くのCSSファイルが読み込まれています。

テーマだけでなく多くのプラグインもCSSファイルを持っています。

また、テーマにもstyle.css以外のCSSファイルがある場合もあります。

現在表示中の画面の色やフォントサイズなどが、どのCSSに由来するのか調べる必要があります。

ですから、親テーマのstyle.cssを開いて修正したCSSが反映されないのは不思議なことではありません。

「絶対禁止!」とまでは言えませんが、style.cssを修正してデザインを変更するのは、あまりおすすめできません。

CSSカスタマイズの基本コンセプト

CSSを変更する(CSSカスタマイズ)には、親テーマを修正せずに子テーマまたは「追加CSS」メニューを使います。

「外観」-「カスタマイズ」‐「追加CSS」によるCSSカスタマイズ

「外観」-「カスタマイズ」‐「追加CSS」によるCSSカスタマイズ

その使い方はともかくとして、基本的な考え方は最も優先されているスタイルを上書きすることです。たとえば、見出し2(h2)のフォントサイズを修正したいとします。

h2 {font-size:18px;}

このスタイルを修正するには、新たなスタイルを書いて“上書き”します。

h2 {font-size:18px;}

h2 {font-size:24px;}

これは、後に書いたスタイルが優先されるというCSSの仕組みによるものです。これにより、h2のフォントサイズは24pxになります。

問題は、このスタイルをどこに書くかですが、理想は子テーマのstyle.cssです。

子テーマのstyle.cssにCSSを入力

子テーマのstyle.cssにCSSを入力

通常は、親テーマのstyle.cssが読み込まれた後に子テーマのstyle.cssが読み込まれるからです。

「テーマのカスタマイズは子テーマを使おう」と説明されるのは、そのためです。

後に書いた方が優先されるという特徴を活かしたものです。

h2 {font-size:18px;}
h2 {font-size:24px;}

子テーマを使えば親テーマを修正せずにCSSをカスタマイズできるということです。

子テーマを作るのが面倒であれば「外観」-「カスタマイズ」メニューの「追加CSS」に入力しても同じことです。これも親テーマより後に読み込まれるという特徴を活かした機能です。

「外観」-「カスタマイズ」‐「追加CSS」によるCSSカスタマイズ

「外観」-「カスタマイズ」‐「追加CSS」によるCSSカスタマイズ

CSSカスタマイズの基本コンセプトをまとめておきます。

  • できれば親テーマのCSSファイルを直接修正しないこと
  • 後に読み込まれるCSSが優先されるという仕組みを利用すること
  • 親テーマより後で読み込まれるのが子テーマや追加CSS
  • そこにCSSを書けば親テーマを修正せずにスタイルを上書きできる

子テーマや「追加CSS」に書いたCSSが反映されない場合

上記のコンセプトは「基本的には」なので例外もあります。

ですから、子テーマや追加CSSに書いたCSSが反映されないことも少なくありません。

主な原因は優先度の問題です。

CSSには優先度が高いスタイルが適用されるという特徴もあります。

前述の「後から書いたCSSが優先される」というのは、次のように2つのスタイルの優先度が同じという前提です。

h2 {font-size:18px;}

h2 {font-size:24px;}

ただし、先に書いたスタイルの方が優先度が高ければ、後に書いたCSSが反映されません。たとえば、次のような例です。

#content h2 {font-size:18px;}

h2 {font-size:24px;}

何が違うのか。それは、スタイルを適用する場所(CSSセレクタ)の指定方法です。

後に書いたスタイルは単純にh2に対してスタイルを指定しています。

「見出し2のフォントサイズを24pxに」という意味ですが、単独のCSSとしては問題ありません。

ただし、先に書いたスタイルでは#content h2のようにCSSセレクタが詳細に指定されています。

「コンテンツ部分の見出し2のフォントサイズを24pxに」のような解釈になりますが、いずれにせよh2のフォントサイズを設定するという意味で違いはありません。

問題は、「h2」と「#content h2」では優先度が異なる点です。

一般的にCSSセレクタを詳細に指定した方が優先度が高くなります。「h2」だけの場合は1ポイントですが、「#content h2」が101ポイントというイメージです。

先に書いた「#content h2」の方がポイントが大きいので後に書いたCSSよりも優先されます。

つまり、上記の例では後に書いたスタイルが反映されないという悩みが生まれます。子テーマのstyle.cssに書いても、追加CSSに入力しても同じです。

これが、他人の作ったテーマやプラグインを利用するWordPress特有の悩みです。

Dreamweaverを使って1人ですべてのCSSを制御できる場合は、そのCSSを修正すれば済みますが、WordPressでは他人が書いたCSSの中で最も優先されるCSSを書く必要があります。

ですから「h2のフォントサイズを変更するにはh2 {font-size:24px;}」という教科書的な知識やコピーペーストするだけの作業では通用しません。

現状をしっかり分析してコードを書いていく必要があります。

CSSの優先度について詳しくは以下のページも参考にしてください。

CSSの変更が反映されないときはセレクタの優先順位をチェック

CSSの優先度を上げる

上記の問題の解決策はいくつかありますが、基本的には自分が書くCSSの優先度を上げるという考え方です。以下、優先度を上げる2つの方法を紹介します。

CSSセレクタを詳細に指定する

まず、CSSセレクタを詳細に指定して先に書いたスタイルと同じ優先度にする方法があります。たとえば、後から書くスタイルのCSSセレクタを次のように「#content h2」にします。

#content h2 {font-size:18px;}

#content h2 {font-size:24px;}

同じCSSセレクタであれば優先度が同じになるので、後から書いたスタイルの方が優先されることになります。

スタイルに「!important」を付ける

または、後から書いたスタイルの最後に「!important」を付ける方法もあります。

#content h2 {font-size:18px;}

h2 {font-size:24px !important;}

「!important」を付けたスタイルの優先度が上がるため、先に書いたスタイルを上書きすることができます。

ただし、「!important」は強力で、変更したくない部分のスタイルにも影響する可能性があるので、変更後は入念なチェックが必要です。

できれば、「解決策1」のように限定的にスタイルを適用した方が無難です。

キャッシュを見ているとCSSの変更は反映されない

ここまでの話はCSSの仕組みから見た「変更が反映されない」の対策でしたが、ちょっとした原因の場合もあります。

たとえば、ブラウザのキャッシュを見ている場合、修正前の古いCSSを見ているので、変更は反映されません。キャッシュ(履歴)を消去して、ブラウザの「更新」ボタンをクリックして最新の表示で確認してみましょう。

同じようにWordPress内でキャッシュプラグインを使っている場合、最新の内容が画面に反映されない場合があります。キャッシュプラグインのメニューでキャッシュを削除してから確認してください。

まとめ

以上、WordPressでCSSの変更が反映されない問題について説明してきました。ポイントをまとめておきます。

  • 基本的には後に書いたスタイルが適用される
  • 後に書いたスタイルが適用されないのは優先度の問題
  • CSSセレクタを詳細に書いた方が優先度が高くなる
  • 優先度を上げるには上書きしたいスタイルのCSSセレクタを参考にする
  • どうしてもうまくいかないときは「!important」を使う
  • CSSが反映されないのは単純にキャッシュが原因ということも

それでもうまくいかないときはWordPress個別サポートにご相談ください。私が直接サイトのCSSをチェックして対応いたします。

この記事ではCSSカスタマイズの考え方を説明しましたが、具体的な作業について詳しくは以下のページも参考にしてください。

BizVektorのCSSの直し方


WordPressでプラグインを使って画像のマウスオーバーアクションを作成する

$
0
0

画像にマウスオーバーするとキャプションなどがフェードインしてくるマウスオーバーアクション。作ってみたくても難しそうですよね。

そんなときはWordPressのImage Hover Effects Ultimateプラグインが便利です。

画像を選んだりキャプションの文字を入力したりするだけで次のようなマウスオーバーアクションを作成することができます。

以下、手順を紹介します。

Image Hover Effects Ultimateプラグインによるマウスオーバーアクションの設定

「プラグイン」‐「新規追加」メニューからImage Hover Effects Ultimateプラグインをインストール、有効化します。

Image Hover Effects Ultimateプラグインのインストール

Image Hover Effects Ultimateプラグインのインストール

「Image Hover」メニューからマウスオーバーアクションを定義していきます。

まずは、「Image Hover」メニューのサブメニュー(例:General Effects)を開いて、使いたいアクションが決まったら「Select」をクリックします。

使いたいアクションの選択

使いたいアクションの選択

任意の名前を入力して「Save」ボタンをクリックします。

設定を保存

設定を保存

「Add New Items」をクリックして、マウスオーバーする画像や、フェードインしてくる文字などを設定します。

マウスオーバーアクション設定画面を開く

マウスオーバーアクション設定画面を開く

最初に表示される画像や、フェードインする内容を設定して、「Submit」ボタンをクリックします。マウスオーバー時の背景画像も設定できます。

マウスオーバーアクションの設定

マウスオーバーアクションの設定

その他、画像や文字について細かく設定できますが、ひとまずショートコードをコピーして動かしてみましょう。

ショートコードをコピー

ショートコードをコピー

コピーしたショートコードを任意のページにペーストすれば、次のようなマウスオーバーアクションの完成です。

サンプル喫茶

オープンしました!

詳しくはこちら

あとは、いろいろなパターンを試してみてください。

WordPressインポートツールをサイト引っ越しに使うな!その理由と対策

$
0
0

WordPressで作成したテストサイトを本番用のサーバーに移転したり、サイトを別のサーバーに引っ越すときに「ツール」メニューからエクスポートしてインポートすることを思い付くかもしれません。

「ツール」‐「エクスポート」メニューでサイト移転しようと…

「ツール」‐「エクスポート」メニューでサイト移転しようと…

この「ツール」メニューで使えるインポート・エクスポートメニュー(WordPressインポートツール)は便利かもしれませんがサイトの引っ越しに使うのはおすすめできないので注意が必要です。

WordPressインポートツールによる引っ越しがうまくいかない

たとえば、次のようなテストサイトができたとします。

完成したテストサイト

完成したテストサイト

本番サーバーに移行するため「ツール」‐「エクスポート」メニューからすべてのコンテンツをエクスポートします。

「ツール」‐「エクスポート」メニューでコンテンツをエクスポート

「ツール」‐「エクスポート」メニューでコンテンツをエクスポート

移行先のサイトの「ツール」‐「インポート」メニューで上記のエクスポートデータをインポートします。

テストサイトのデータをインポート

テストサイトのデータをインポート

インポートの完了後、投稿や固定ページはインポートされているようですが、、、

固定ページはインポートされているが、、、

固定ページはインポートされているが、、、

サイトを表示しみてると、全く別物のサイトになっています。テストサイトのデザインが反映されていません。

インポートしたサイトは別物に…

引っ越し前のデザインが反映されない

これは「ツール」‐「エクスポート」メニューでエクスポートしたデータにはテーマやプラグインなどのファイル一式が含まれないためです。

また、次のような情報も復元されません。

WordPressインポートツールでは復元されない内容
  • テーマ・プラグイン(再インストール・再設定が必要)
  • テーマのオプション(ヘッダー画像・ロゴなど)
  • ウィジェット(サイドバー・フッターなど)

これらの設定をもう一度行う必要があります。

長い制作期間をかけて作ったサイトについて上記のような作業をやり直すのは面倒なだけなので、サイト移転にはWordPressインポートツールを使わない方が無難です。

サイトの引っ越しが簡単にできる「All-in-One WP Migration」

「WordPressの引っ越しって、こんなに面倒なんですね」と割り切って作業できるなら、WordPressインポートツールを使ってサイト移転すれば良いのですが、面倒な作業なら、それを解決してくれるプラグインがある。それがWordPressを使うメリットです。

たとえば、サイトの引っ越しにはAll-in-One WP Migrationのようなプラグインが便利です。

サイトをエクスポートして移転先でインポートするのはWordPressインポートツールと同じですが、テーマやプラグイン、オプション設定なども含めてエクスポートできる点が違います。

手動では面倒なサイト引っ越しも簡単に済ませることができます。また、テストサイトのURLを移転先のURLに変更してくれるので非常に便利です。

All-in-One WP Migrationについて詳しくは、以下のページをご覧ください。

WordPressの移行が簡単な「All-in-One WP Migration」

WordPressのアーカイブをカテゴリーで絞り込む方法

$
0
0

WordPressで年月ごとの記事一覧を表示できるアーカイブ。全カテゴリーの記事が含まれていますが、特定のカテゴリーで絞り込みたいこともありますよね。

その方法が以下のサイトに掲載されています。ここでは以下のサイトを参考にさせていただき、実際に作業するときの手順を紹介します。

【参考】カテゴリー毎の日付別アーカイブを表示する方法 | デザイナーのタネあかし

※以下の手順で使うPHPおよびjQueryのコードは上記のサイトから引用させていただきました。ありがとうございます。

プラグインの準備

PHP Code Widgetプラグイン

まずは、ウィジェットにPHPコードを入力できるように、「プラグイン」‐「新規追加」メニューからPHP Code Widgetプラグインをインストール、有効化します。

PHP Code Widgetプラグインのインストール

PHP Code Widgetプラグインのインストール

Simple Custom CSS and JSプラグイン

jQueryを使ってリンクを書き換えるためSimple Custom CSS and JSプラグインをインストール、有効化します。

Simple Custom CSS and JSプラグインのインストール

Simple Custom CSS and JSプラグインのインストール

自分なりにjQueryを入力する手順を確立できている場合は上記のプラグインは不要です。

アーカイブウィジェットの作成

「外観」-「ウィジェット」メニューでアーカイブウィジェットを作成します。

それには、任意のウィジェットエリア(例:サイドバー)にPHP Codeウィジェットを追加して次のコードを入力します。

<ul class="archive-links">
<?php
wp_get_archives( 'type=monthly&limit=12' );
?>
</ul>

作成したウィジェットのイメージは次のようになります。

アーカイブウィジェットの作成

アーカイブウィジェットの作成

比較のため、通常のウィジェットも追加しています。上が全カテゴリー記事を表示する通常のアーカイブ、下が特定カテゴリー対象のアーカイブになります。

アーカイブを特定カテゴリーで絞り込む

アーカイブを特定のカテゴリーで絞り込むため、次のjQueryを入力します。

/* アーカイブをカテゴリーで絞り込む */
jQuery( function() {
  jQuery( ".archive-links a" ).each( function() {
    var obj = jQuery(this);
    var link = obj.attr("href");
    obj.attr("href",link+"?cat=2");
  });
});

それには、「Custom CSS & JS」‐「Add Custom JS」メニューを開いて、jQueryを入力(1)します。わかりやすくタイトルを入力(2)しておくとよいでしょう。

アーカイブをカテゴリーで絞り込むjQueryを入力

アーカイブをカテゴリーで絞り込むjQueryを入力

コードのポイントは6行目です。「cat=2」の「2」を絞り込みたいカテゴリーのIDに変更する必要があります。

カテゴリーIDの調べ方がわからないときはCatch IDsプラグインをインストールしておくと便利です。

Catch IDsプラグインのインストール

Catch IDsプラグインのインストール

「投稿」‐「カテゴリー」メニューでカテゴリーIDを調べることができます。

カテゴリーIDをチェック

カテゴリーIDをチェック

jQueryを保存して、アーカイブの動作を確認してみましょう。

まず、通常のアーカイブをクリックすると、さまざまなカテゴリーの記事が混じって表示されます。

通常のアーカイブ(全カテゴリーが表示される)

通常のアーカイブ(全カテゴリーが表示される)

特定カテゴリーに絞り込んだアーカイブをクリックすると、指定したカテゴリー(ここでは「イベント情報」)の記事のみが表示されます。

カテゴリーを絞り込んだアーカイブ

カテゴリーを絞り込んだアーカイブ

これで作業は完了です。動作確認できたら、通常版のアーカイブは削除しましょう。

アーカイブをカテゴリーで絞り込む仕組み

予備知識として仕組みを理解するため、カテゴリーで絞り込んだアーカイブのリンクを見てみましょう。

「http://example.com/date/2014/07?cat=2」のようにURLの最後に「?cat=2」が付いています。アーカイブページにこの文字を付けることでカテゴリーで絞り込める仕組みです。

うまくいかないとき

テーマによってはアーカイブページのURLが異なる場合があるので、上記のjQueryによる絞り込みがうまくいかないかもしれません。

その場合、「?cat=2」の「?」を「&」に変更(つまり、&cat=2)してみてください。話が長くなるので理由は省略しますが、これでうまくいく場合があります。

「外部リンクはSEOに効果がある」は半分間違い

$
0
0

「外部リンクはSEOに効果がある」はSEO対策として有名なフレーズです。一度は聞いたことがあるかもしれませんが、すべての外部リンクにSEO効果があるわけではないので注意が必要です。

Twitterからの被リンクにSEO効果は期待できない

たとえば、Twitterから自分のサイトに大量のリンクをはってSEO対策!

そんな作戦は間違いです。残念ながら検索順位の上昇には役立ちません。

仮に大きな効果があるとしたら、私はブログを書くのを止めて一日中、Twitterから自分のサイトへのリンクをはりまくることでしょう。

それで検索順位が上がるなら、です。

実際は、そんなことはありません。Twitterから自分のサイトにリンクをはっても外部リンクの効果は期待できません

その理由はTwitterに書き込んだリンクを見ればわかります。

Twitterからのリンクには「nofollow」が付いている

Twitterからのリンクには「nofollow」が付いている

Twitterに限りませんが、SNSに書き込んだリンクには「nofollow」という属性が付いていることが多いです。

この「nofollow」によって検索エンジンのロボットがリンクをたどらないようになります。いくら自分のサイトのリンクをはっても、検索エンジンはそのサイトを見に行かないのです。

つまり、「nofollow」が付いたリンクは基本的に外部リンクとしての効果を持ちません。

【参考】nofollow属性とは | SEO用語集:意味/解説/SEO効果など [SEO HACKS]

FacebookやYahoo知恵袋、カカクコムの掲示板も同じように外部リンクには「nofollow」が付いています。

というわけで、TwitterやFacebookなどから一生懸命に自作自演の外部リンクを設置してもSEO的な効果はないので、そのような施策に力を注ぐのは止めましょう。

【参考】Facebookにリンクを設置したり、いいねを集めたりすることはSEO上の効果がありますか? | SEO対策Q&A [SEO HACKS]

実際はTwitterからのリンクが厳密に効果がゼロなのかといえば、そうとも言い切れませんが、自作自演の外部リンクに力を注ぐより、コンテンツの充実に時間をかけた方が良いのは言うまでもありません。そんな教科書的なまとめで、この記事を終わります。

どうしても手っ取り早く検索順位を上げたいなら記事のタイトルを見直した方が効果的ですよ。

Contact Form 7からのメールにページタイトルを自動入力する

$
0
0

Contact Form 7から送信するメールにページのタイトルを入れたいこともあります。

たとえば、ブログ記事の下に設置した問い合わせフォームです。どのページから送信されたメールなのか判断するためにページのタイトルが入ってくれば便利です。

どの記事への質問なのか、どの物件への問い合わせなのか知ることもできます。

どのページからの問い合わせなのか知りたい

どのページからの問い合わせなのか知りたい

とはいえ、お客様にページのタイトルを入れてもらうのは現実的ではありません。自動でメールに入力されれば助かりますよね。

そんなときはContact Form 7で使える特別なメールタグが役立ちます。

たとえば、[_post_title]にはページのタイトルが入ってきます。また、[_post_url]はページのURLです。

これらのメールタグをコンタクトフォームの設定画面に入力すれば、どのページから送信されたメールなのか知ることができます。

たとえば、「メッセージ本文」を次のように組み立てます。

差出人: [your-name] <[your-email]>

問い合わせ元のページ:[_post_title]
URL:[_post_url]

メッセージ本文:
[your-message]

これにより、送信されるメールにページタイトルやURLが入ってきます。

メール本文にページタイトルやURLが入ってくる

メール本文にページタイトルやURLが入ってくる

これで、どのページから送信されたメールなのか知ることができます。どの記事の感想なのか、どの物件への問い合わせなのか、さまざまなケースで役立ちます。

Contact Form 7で使える特別なメールタグについて詳しくは以下のページも参考にしてください。

【参考】特別なメールタグ | Contact Form 7 [日本語]

WordPressのフォルダ構成

$
0
0

WordPressを使っていると気になるのが「フォルダ構成はどうなっているのか?」ですが、勘違いしている部分もあるかもしれません。基本的なフォルダ構成を理解しておきましょう。

WordPressのフォルダ構成

WordPressのフォルダ構成はレンタルサーバーのFTPツールまたはFTPソフトで確認できます。WordPressをインストールしたフォルダを開くと、次のようにwp-admin、wp-includes、wp-contentというフォルダが見つかります。

WordPressのインストール先フォルダ

WordPressのインストール先フォルダ

「WordPressの移転がうまくいかない」というご相談をよくいただきますが、少なくともwp-admin、wp-includes、wp-contentという3つのフォルダが存在しなければ、ファイル一式のコピーに失敗しています。

インストールされたフォルダの用途は次のとおりです。

  • wp-admin --- WordPressの管理画面のためのファイル一式
  • wp-includes --- WordPressのシステムファイル一式
  • wp-content --- コンテンツ一式(テーマ・プラグイン・画像など)
  • 上記のフォルダに含まれないファイル --- インデックスファイル・設定ファイルなど

主なフォルダとファイル構成は上記のとおりですが、それ以外のフォルダが存在する場合があります。たとえば、「images」や「lib」などです。

定番ではないフォルダが存在する

定番ではないフォルダが存在する

これらのフォルダはWordPress本体がインストールしたものではなく、サイト制作を依頼した制作業者が独自に作った可能性があります。

WordPressの動作には問題ありませんが、注意が必要なのはバックアップです。こうした本来のWordPressに存在しないフォルダも忘れずにバックアップされているか確認した方が良いでしょう。

特に重要なのはwp-contentフォルダ

wp-admin、wp-includes、wp-content、それぞれ膨大なサブフォルダとファイルで構成されていますが、特に重要なのはwp-contentフォルダです。

wp-content内のフォルダ

wp-content内のフォルダ

wp-contentフォルダにはインストールしたテーマやプラグイン、画像一式が含まれます。間違って削除しないように注意が必要です。

ちなみに、wp-adminやwp-includesフォルダは間違って消してしまってもWordPress.orgからダウンロードすれば復元できます。

wp-contentフォルダの構成
  • languagesフォルダ --- 翻訳ファイル
  • pluginsフォルダ --- プラグインファイル
  • themesフォルダ --- テーマファイル
  • upgradeフォルダ --- アップデート時に利用
  • uploadsフォルダ --- 画像など
  • index.php --- ダミーのインデックス(フォルダ一覧が見えないようにする)

index.phpは「Silence is golden」

ちなみに、wp-contentフォルダのindex.phpに書かれたコードは次の2行だけですが驚く必要はありません。

<?php
// Silence is golden.

「Silence is golden.」(沈黙は金)としか書いていないので何かのイタズラかと思いそうですが、これで正しい内容です。

これはダミーのインデックスファイルとして機能します。このファイルがないとフォルダ構造が丸見えになる場合があるので、それを避けるためにダミーのインデックスファイルが設置されています。

ダミーのindex.phpを設置することでフォルダ構造も何も表示されず、静寂が保たれるということで「Silence is golden.」ということだと思います。

WordPressに限りませんがWebアプリケーションのセキュリティ対策として「不必要な情報を公開しない」という考え方によるものです。

wp-config.phpに「define('WP_DEBUG', false);」と書いてエラーメッセージを非表示にしたり、あちこちのフォルダに「Silence is golden.」なindex.phpを設置してフォルダ構造を隠すというのもその一環です。

wp-content/themesフォルダ

wp-contentフォルダの中で特に「消さないように」という意味で重要なのはthemesフォルダ、uploadsフォルダです。

themesフォルダにはテーマのファイル一式が含まれます。カスタマイズに使った子テーマのフォルダも存在するので、バックアップしていないサイトでthemesフォルダを削除すると泣くことになります。親テーマは再インストールすれば復旧できますが。

wp-content/themesフォルダ(テーマが含まれる)

wp-content/themesフォルダ(テーマが含まれる)

また、テーマで使われている画像がメディアライブラリに存在しないときはテーマフォルダに保存されている場合があります。wp-content/themesフォルダを探っていけば、テーマで使われているアイコンなどの画像が見つかります。

wp-content/uploadsフォルダ

uploadsフォルダには画像一式が含まれるので、削除しないようにしましょう。元ネタがPC内にあるとしても注意が必要です。というのは、オリジナルの画像(例:a.jpg)からサイズ別の画像が何枚か作られるからです。

wp-content/uploadsフォルダ(画像が含まれる)

wp-content/uploadsフォルダ(画像が含まれる)

画面によって使われる画像サイズが異なる場合があるので、消してしまった画像をPCから再アップロードしただけでは、画面表示が復旧しない場合があります。

投稿や固定ページはwp-contentに入っていない!

さて、WordPressのフォルダ構成を理解する目的の1つに、投稿や固定ページなどをきちんとバックアップしたい、があります。

先に結論を書くと、wp-contentフォルダに投稿や固定ページの内容は入っていません。ダッシュボードから入力した内容はデータベースに保存される仕組みです。

ダッシュボードからの入力内容はデータベースに保存される

ダッシュボードからの入力内容はデータベースに保存される

サイトの画面に表示される画面や文章がどこかのフォルダに保存されているイメージかもしれませんが、wp-contentにはダッシュボードから入力した文章は保存されていません。

ファイルとデータベースに保存される内容は次のようになります。

ファイルとデータベースの構成

ファイルとデータベースの構成

投稿や固定ページの内容はデータベースに保存されています。WordPressサイトを完全にバックアップするには、wp-contentなどのフォルダに含まれるファイルだけでなくデータベースのバックアップも必要です。

ファイルとデータベースは一般的に別のサーバーにあります。レンタルサーバーのFTPツールまたはFTPソフトではアクセスできないので、手動でバックアップするときは注意が必要です。

テーマやプラグインも同じです。ファイルはwp-contentフォルダに保存されていますが、設定内容はデータベースに格納されています。ですから、FTPを使ってファイルだけをバックアップしても不完全です。

「ファイル+データベース」のバックアップは手動では面倒なのでBackWPupなどのバックアップ系プラグインが役立ちます。BackWPupで作成したバックアップファイルを解凍すると、sqlという拡張子のファイルが含まれています。これがデータベースのバックアップファイルです。

データベースのバックアップファイル(.sqlファイル)

データベースのバックアップファイル(.sqlファイル)

このsqlファイルは本来のWordPressのファイル構成に含まれないファイルです。つまり、バックアップからサイトを復元する場合、このsqlファイルをアップロードしないように注意が必要です。

まとめ

WordPressのフォルダ構成を簡単に説明してきました。間違って消しても大丈夫なフォルダ(wp-admin、wp-includes)もあれば、できれば消さないように注意したいフォルダ(wp-content)もあります。

万が一のときのためにバックアップする場合、これらのフォルダだけでなくデータベースの存在も忘れないようにしましょう。

カテゴリーのテンプレートを指定する方法

$
0
0

特定カテゴリーのみレイアウトを変えたい場合、そのカテゴリー用のテンプレートを作成する方法があります。

一般的にカテゴリーアーカイブはcategory.php、個別投稿はsingle.phpというテンプレートが有名ですが、特定カテゴリーに適用する場合は注意が必要です。

カテゴリーアーカイブのテンプレートはcategory.php

カテゴリー記事の一覧ページ(カテゴリーアーカイブ)で使われるテンプレートはcategory.phpです。

特定カテゴリーで違うテンプレートを使いたい場合、category-スラッグ.phpというファイル名にします。たとえば、category-event.phpというファイルを作成すればeventカテゴリーのアーカイブで使われます。

具体的な作成方法は説明しませんが、基本的にはテーマのcategory.phpをコピーしてcategory-スラッグ.phpという名前に変更すればよいでしょう。

category.phpが存在しないテーマではarchive.phpやindex.phpが使われます。これらをコピーしてカテゴリーアーカイブを作っても構いませんが、archive-スラッグ.phpはカテゴリーアーカイブではなくカスタム投稿タイプのアーカイブということに注意してください。

つまり、archive-event.phpはeventというカスタム投稿タイプのアーカイブページのテンプレートとして使われます。

どのタイミングでどのようなテンプレートが使われるのか、詳しくは以下のページも参考にしてください。

【参考】テンプレート階層 - WordPress Codex 日本語版

  • category.php --- カテゴリーアーカイブのテンプレート
  • category-スラッグ.php --- 特定カテゴリーのアーカイブ(category.phpから作る)
  • category.phpがない場合 --- archive.phpやindex.phpが使われる
  • archive-スラッグ.php --- 特定カスタム投稿タイプのアーカイブ

個別記事のテンプレートはsingle.php

個々の記事のテンプレートはsingle.phpですが、カテゴリーの個別記事のテンプレートはsingle-スラッグ.phpではないので注意してください。

single-スラッグ.phpは特定のカスタム投稿タイプの個別記事のテンプレートです。たとえば、single-event.phpは「event」というカスタム投稿タイプの個別記事のテンプレートになります。

  • single.php --- 個別投稿のテンプレート
  • single-スラッグ.php --- カスタム投稿のテンプレート(カテゴリー記事ではない)

特定カテゴリーの個別記事にテンプレートを指定する場合

eventカテゴリーの個別投稿でsingle-event.phpというテンプレートを使いたい場合、次のコードを子テーマのfunctions.phpなどに入力します。

/* 特定カテゴリーの個別投稿のテンプレートを指定 */
function my_template_include($template) {
  if (is_single() && in_category('event')) {
    $template = dirname(__FILE__) . '/single-event.php';
  }
  return $template;
}
add_filter('template_include', 'my_template_include', 999);

in_category('event')は「これがeventカテゴリーの記事だったら」という意味になります。サンプルなので実際のカテゴリーに合わせて変更してください。


PHPのビックリマーク「!」の意味は?

$
0
0

WordPressのテンプレートなどPHPのコードを見ているとビックリマーク(!)を見かけます。かなり多く見かけるので気になるかもしれませんが、このビックリマークの意味は何でしょうか?意外と重要なのでこの記事で説明していきます。

ビックリマークの意味は「否定」

ビックリマークの意味は「否定」ですが簡単に言えば「~ではない」という意味です。わかりやすいように実際のコードで説明します。

<?php if ( !is_front_page() …略… ) { ?>
<?php get_template_part('module_pageTit'); ?>
<?php get_template_part('module_panList'); ?>
<?php } ?>

このコードではパンくずリストを表示(3行目)していますが、トップページにパンくずリストは必要ないですよね。そこで、「トップページ以外に表示する」という条件が必要になるのですが、その条件が1行目のビックリマークで表現されています。

ご存じかもしれませんがis_front_page関数は、このページがトップページかどうかをチェックする関数です。

ですが、単純にis_front_page関数を使って次のようなコードを組み立てると「このページがトップページだったらパンくずリストを表示する」というおかしな意味になってしまいます。

<?php if ( is_front_page() ) { ?>
<?php get_template_part('module_panList'); ?>
<?php } ?>

そこで、「トップページに」という条件を反転して「トップページ以外は」にするため、魔法の記号「!」を使います。といっても難しい話ではなく、「is_front_page」を「!is_front_page」に書き換えるだけです。

<?php if ( !is_front_page() ) { ?>
<?php get_template_part('module_panList'); ?>
<?php } ?>

「is_front_page()」を「!is_front_page()」にしただけですが、これで「トップページだったら」の条件が反転して「トップページ以外は」になります。

これにより、トップページ以外にパンくずリストが表示される仕組みです。

条件を反転するというビックリマークの機能について簡単に説明しましたが、もう少し詳しく知りたい方のためにPHPのビックリマークについて掘り下げます。

PHPのif文の仕組み

そもそも、なぜ「if (is_front_page())」が「トップページだったら」になるのでしょうか。

ifは直訳すると「もしも~だったら」ですが、PHPでは条件分岐の構文(if文)として使われます。条件分岐とは条件に応じて行き先が分岐するという意味です。

たとえば、
もしも60点以上だったら合格
それ以外だったら不合格
のようなイメージです。

得点に応じて判定が2つに分岐します。

is_front_pageの例に置き換えると、
もしも現在のページがトップページだったらパンくずリストは表示しない
それ以外はパンくずリストを表示する
となります。

この要件をコードに置き換えるわけですが、if文で組み立てる分岐は必ず二択になります。

つまり、
「現在のページはトップページですか?」という二択の質問の答えが
「はい」の場合はパンくずリストを表示しない
「いいえ」の場合はパンくずリストを表示する
という分岐になります。

三択以上の分岐も可能ですが、ここでは説明を省略します。

これをプログラムに翻訳してみます。それぞれの言葉は次のように置き換えることができます。

  • 【質問】トップページかどうか:is_front_page関数を使う
  • 【答え】「はい」はtrue・「いいえ」はfalseを使う
  • 【質問と答えを組み立てる構文】if文を使う
  • 【行うこと】パンくずリストの表示:get_template_part関数を使う

これらのキーワードをプログラムに組み立てます。

まずは、空の状態のif文(もしも~だったら)を準備します。

<?php if () { ?>
<?php } ?>

次に「トップページですか?」が「いいえ」だったら、の条件を差し込みます。

<?php if (is_front_page() == false) { ?>
<?php } ?>

最後に、条件を満たすときのコード(パンくずリストを表示)を追加します。

<?php if (is_front_page() == false) { ?>
<?php get_template_part('module_panList'); ?>
<?php } ?>

条件にビックリマークを使う書き方と違って「== false」のようなコードが出てきて難しく思えるかもしれませんが、実はPHP入門という意味では、この書き方が基本です。

if文は省略できる

WordPressテンプレートで「~以外は」という条件を組み立てるのに「== false」の代わりにビックリマークが使われているのは、if文の省略形だからです。

「is_front_page() == false」の「== false」や「== true」は省略できます。

まずは、「== true」を使ったif文で説明します。条件は「現在のページがトップページだったら」になります。

<?php if (is_front_page() == true) { ?>
<?php get_template_part('module_panList'); ?>
<?php } ?>

この「== true」は単純に削除することができます。つまり、次のように記述しても同じ意味です。

<?php if (is_front_page()) { ?>
<?php get_template_part('module_panList'); ?>
<?php } ?>

内容は変わりなく「現在のページがトップページだったら」です。

次は「== false」を使って「トップページ以外は」のコードを組み立ててみます。

<?php if (is_front_page() == false) { ?>
<?php get_template_part('module_panList'); ?>
<?php } ?>

このコードからも「== false」を省略することができます。その代わりに否定を示す「!」を付けるということです。

<?php if (!is_front_page()) { ?>
<?php get_template_part('module_panList'); ?>
<?php } ?>

このように「!」は「~ではない」という条件を作る「== false」の省略形だということです。これは特殊な書き方ではなく、多くのテーマやプラグインでビックリマークを使った書き方になっているはずです。

なぜWordPressテンプレートには省略形のコードが多いのか。それは「プログラムは短い方が良い」という原則によります。テンプレートは学習用の教材ではなく実践的なプログラムだとも言えるでしょう。わかりづらいかもしれませんが、少しずつ慣れるようにしましょう。

まとめ

WordPressのテンプレートでよく見かけるビックリマークの意味はおわかりいただけたでしょうか。単純に「~ではない」(否定)の意味だという理解でも構いませんがif文から「== false」が省略された形だとわかれば、コードの解釈にも役立つと思います。プログラミング未経験の方には難しい話だったかもしれませんが参考にしてください。

「送信されたURLにnoindexタグが追加されています」と表示されるとき

$
0
0

Google Search Consoleからインデックスカバレッジの問題として「送信されたURLにnoindexタグが追加されています」とメッセージが届くことがあります。

「送信されたURLにnoindexタグが追加されています」

「送信されたURLにnoindexタグが追加されています」

インデックス カバレッジは Google 検索結果で悪影響を受ける可能性がございますと書かれているので気になりますよね。

インデックス カバレッジ」は Google 検索結果で悪影響を受ける可能性が

インデックス カバレッジ」は Google 検索結果で悪影響を受ける可能性が

警告ではないので焦る必要はありませんが、対策を紹介します。

noindexとは

noindexとは簡単に言えば「検索結果に出さないで」の指定です。サイト制作者が設定することができます。

SEOで不利になりそうなページや、検索結果に出てほしくないページにnoindexを設定するような用途です。

Google Search Consoleの「送信されたURLにnoindexタグが追加されています」とは、あなたのサイト内で「検索結果に出なくて良い」(noindex)と指定されたページがありますよ、のお知らせです。

警告ではないので、理解してnoindexに設定した記憶があれば放置しておいても構いませんが、うっかり検索結果に出さない設定を解除し忘れていることもあります。

検索結果に出さない設定になっていないかチェック

大丈夫だと思いますが、「設定」‐「表示設定」メニューの「検索エンジンがサイトをインデックスしないようにする」がチェックされていないか確認しましょう。

検索結果に出ない設定

検索結果に出ない設定

チェックされていると基本的には検索結果に出ません。「送信されたURLにnoindexタグが追加されています」のメッセージの原因にもなります。検索結果に表示してほしければチェックを外してください。

個々のページがnoindexになっていないかチェック

All in One SEO Packのようなプラグインを使うと、個々の投稿や固定ページをnoindexに設定できます。

個々の投稿や固定ページのnoindex設定

個々の投稿や固定ページのnoindex設定

理解してnoindexに設定したのであれば問題ありませんが、検索結果に出ないと困る場合はチェックを外しておきましょう。

なぜか「noindexにすればSEOに効果的で検索順位が上がる」のようなテクニックの本質を理解せずに、いろいろなページをnoindexに設定されている方がいるようなので、十分にご注意ください。

sitemap.htmlが作成されていないかチェック

意外なところでGoogle XML Sitemapsプラグインが原因の場合があります。

「設定」‐「XML-Sitemap」メニューの「基本的な設定」で「HTML形式でのサイトマップを含める」がチェックされていると、sitemap.htmlというHTML形式のサイトマップが出力されます。

HTML形式のサイトマップが作成される

HTML形式のサイトマップが作成される

このHTML形式のサイトマップは検索結果に出る必要がないのでnoindex設定になっており、Google Search Consoleで「送信されたURLにnoindexタグが追加されています」になります。

通常はこのsitemap.htmlは不要です。チェックを外しておきましょう。

これでnoindexのメッセージは消えるはずです。

これらのnoindex解除についてはリアルタイムで反映されるわけではないので、検索結果に出てくるまで、しばらく時間が必要なこともあります。

WordPressの「追加CSS」メニューの使い方

$
0
0

WordPressの「追加CSS」メニューとは

「外観」-「カスタマイズ」メニューの「追加CSS」とは文字通り、サイトにCSSを追加するメニューで、用途はデザイン修正です。たとえば、グローバルメニューのフォントサイズを大きくしたい場合など、追加CSSのエディタにCSSを入力して解決することができます。

CSSを入力してデザインをカスタマイズできる「追加CSS」メニュー

CSSを入力してデザインをカスタマイズできる「追加CSS」メニュー

追加CSSが役立つケース

なぜデザイン修正するのに追加CSSが必要なのか、それは親テーマを直接修正しないことが重要だからです。

サイトのデザインをカスタマイズする場合、親テーマを直接修正するのは問題が起きるので子テーマを使うのが一般的です。

ただし、ちょっとした修正のために子テーマを作るのは面倒なこともあります。

WordPressで子テーマを作るメリットとデメリット

そんなときに、わざわざ子テーマを作らなくてもデザインをカスタマイズできる「追加CSS」メニューが役立ちます。

エディタにCSSを入力すればよく、子テーマも作らず親テーマも編集せずにデザインを修正することができます。

追加CSSが不要なケース

すでに子テーマでカスタマイズしている場合や、「CSSカスタマイズ」など同じようなメニューが存在する場合は「追加CSS」メニューを使う必要はありません。

とはいえ子テーマを使っている状況で追加CSSを使っても問題が起きるわけではないので、無理に1つにまとめる必要もありません。

追加CSSの使い方

「追加CSS」メニューの使い方は簡単です。メニューを開いてCSSを入力するだけなので、子テーマのstyle.cssにコードを入力するのと同じイメージです。結果をプレビューすることもできます。

入力したCSSの結果をプレビュー

入力したCSSの結果をプレビュー

「公開」ボタンをクリックすると完了です。サイトを表示して実際の画面を確認しましょう。

入力支援機能の活用

途中までCSSを入力すれば、候補を表示してくれるので便利です。フォントサイズを修正したいときに「fo」と入力すると、候補のCSSプロパティが表示され、リストから選ぶことができます。

入力候補が表示される

入力候補が表示される

入力ミスの指摘

入力したCSSが間違っていると、エラーメッセージが表示されたり、「保存する前に1個のエラーを修正してください」などの警告が表示される場合があります。すべて今すぐ修正する必要はありませんが、追加CSSエラーのアイコンが付いたエラーは明らかな間違いなので保存する前に修正した方が良いでしょう。

追加CSSがエラーで保存できない

CSSの間違いを指摘してくれる

追加CSSの注意レベルのエラーでも文法ミスの場合があるので、可能な範囲で修正しましょう。

よくわからなければWordPressメールサポートにご相談ください。

どのようなCSSを記述すれば良いか

「追加CSS」メニューはエディタなので、どのようなCSSを入力すれば良いかまでは教えてくれません。記述するCSSを組み立てるにはインスペクタのようなツールの使い方も合わせて理解しておいた方がよいでしょう。詳しくは以下のページも参考にしてください。

BizVektorのCSSの直し方(インスペクタの使い方から説明)

追加CSSの注意点

追加CSSを使う際の注意点をいくつか紹介します。

入力したCSSはテーマ依存

入力したCSSは現在のテーマに紐付いています。別のテーマに切り替えるとCSSは空になり、反映されません。

テーマを切り替えると追加CSSが空に

テーマを切り替えると追加CSSが空に

ただし、前のテーマで入力したCSSは消えたわけではなく、元のテーマに戻せば復活します。

入力したCSSの保存場所はデータベース

追加CSSで入力したCSSはデータベースに保存されます。子テーマのstyle.cssのようなファイルは存在しないのでFTPでダウンロードできません。注意してください。

余裕があればWordPressデータベースのwp_postsテーブルを開いてみてください。入力したCSSはcustom_cssというカスタム投稿タイプのデータとして保存されています。

追加CSSはデータベースに保存される

追加CSSはデータベースに保存される

データベースには過去のバージョン(リビジョン)も保存されているので昔のバージョンに戻したいときはデータベース内を探してみると良いかもしれません。

入力したCSSを保存できない

「公開」ボタンをクリックすると保存に失敗する場合はレンタルサーバーのセキュリティ機能のせいかもしれません。たとえば、ロリポップでは全ドメインでWAF(ウェブアプリケーションファイアウォール)が有効になっています。これを無効にしてみてください。

WAFを無効に

WAFを無効に

有効/無効の切り替えが反映されるまで5分くらいかかります。

エディタが使いづらいとき

コードを強調表示(シンタックスハイライト)するエディタが使いづらいときは、シンプルなエディタに切り替えることができます。

「ユーザー」‐「あなたのプロフィール」メニューで「コード編集中のシンタックスハイライトを無効化」をチェックします。

コード編集中のシンタックスハイライトを無効化

コード編集中のシンタックスハイライトを無効化

これにより、コードがハイライトされないシンプルなエディタになります。

追加CSSをシンプルなエディタに

追加CSSをシンプルなエディタに

CSSが反映されない

入力したCSSが反映されないのは追加CSSが原因というより、記述したCSSの問題です。主に文法ミスかCSSセレクタの優先順位の問題です。

詳しくは以下のページも参考にしてください。

WordPressでCSSが反映されないときのチェックポイント

まとめ

子テーマを作らずにデザインをカスタマイズできる「追加CSS」メニューは便利ですね。「テーマに紐付く」とか「ファイルに保存されない」などの特徴をおさえて活用しましょう。

WordPressカスタマイズが劇的に簡単になるAFFINGER5(WING)

$
0
0

一般的にWordPressのカスタマイズは苦労することも少なくないので、カスタマイズしやすいテーマを使うのが理想です。そこで、カスタマイズしやすいテーマとして有名なAFFINGER5(アフィンガー5:WING)を使ってみたのですが、あまりにもカスタマイズ機能が充実しすぎでビックリしました。

「ここまで簡単にカスタマイズできるか!」というほどです。

充実しすぎているので全ては紹介できませんが、AFFINGER5(WING)のカスタマイズメニューを少しだけ紹介してみたいと思います。

見出しのデザインが一瞬で切り替わる

「ブログ記事の見出しデザインを変更したい」は、よくある依頼です。次のように見出しが太字になっているだけのテーマもあるので、「もう少しおしゃれに」とか「もう少し目立つスタイルに」とか思いますよね。

見出しのデザインを変えたいが…

見出しが太字になっているだけのテーマも珍しくない

ここから枠線を付けたり、背景色を付けたり、吹き出しにしたり、慣れていないと難しいかもしれませんが、AFFINGER5(WING)では見出し(h1、h2、h3…)のデザインを選んで変更できます。

見出しのスタイルを選べる

見出しのスタイルを選べる

スタイルを選ぶだけでサイトの雰囲気がガラッと変わります。これには感動です!

たとえば、吹き出しデザインに変更してみます。

見出しデザインの変更例(吹き出し)

見出しデザインの変更例(吹き出し)

「囲み&左ライン」は次のようになります。

見出しデザインの変更例( 囲み&左ライン)

見出しデザインの変更例( 囲み&左ライン)

「囲みドットデザイン」は次のようになります。

見出しデザインの変更例(囲みドットデザイン)

見出しデザインの変更例(囲みドットデザイン)

シンプルな「左ライン」は次のようになります。

見出しデザインの変更例(左ライン)

見出しデザインの変更例(左ライン)

念のため書いておきますがCSSは一切入力していません。メニューをクリックするだけで、こうしたデザインに自由に切り替えられるのです。スゴイですね。

その他、次のようなオプションが用意されています。

見出しに適用できるデザイン
  • ボーダーを上下のみにする
  • ボーダー上を太くする(下をサブカラーに)
  • タイトルの基本スタイル
  • 吹き出しデザインに変更(※要背景色)
  • 囲み&左ラインデザインに変更
  • 2色アンダーラインに変更
  • グラデーションアンダーラインに変更
  • センターラインに変更
  • 囲みドットデザインに変更
  • ストライプデザインに変更
  • 破線アンダーラインに変更
  • 左ラインデザインに変更
  • テキストを中央寄せ
  • デザインを幅一杯に
  • 背景や吹き出しの角を丸くする
  • グラデーションを横向きにする
  • 背景画像
  • 左・左右の余白

グラデーションも一瞬で設定できるなんて…

ここを見ただけでもユーザーのニーズを細かくメニューに反映した、素晴らしいテーマってことがわかります。

h1、h2、h3で別々のデザインにできるのも嬉しいですね。h4、h5は一部のオプションのみです。

見出しのデザインが変わると気分も変わってサイト制作が楽しくなること間違いなしですね。これだけでも購入する価値は十分あると思います。カスタマイズで楽をしたい方は、ぜひ、お試しください。

PCとスマホで違うヘッダー画像/ロゴ画像

PCは横長、スマホは縦長なので、ヘッダー画像やロゴ画像は違う画像にしたいという要望が増えています。言うまでもありませんが、シンプルなテーマではPC・スマホで同じ画像になるのが一般的です。

AFFINGER5(WING)ではPCとスマホで別々の画像を表示することができます。

PCのヘッダー画像・ロゴ画像は次のようなイメージになります。

PCのヘッダー画像・ロゴ画像

PCのヘッダー画像・ロゴ画像

スマホのヘッダー画像・ロゴ画像は次のようなイメージになります。PCとは違う画像です。

スマホのヘッダー画像・ロゴ画像

スマホのヘッダー画像・ロゴ画像

細かい話ですが、この部分についてPCとスマホの切り替えをサーバー側で行っているのでスマホの表示結果を確認するには実際の端末(またはユーザーエージェントスイッチャーなどのツール)が必要です。

PCとスマホで別の画像が使えることがわかれば、あとは、あなたのアイデア次第です。

ヘッダーメニューの色設定・グラデーション

ヘッダーメニューの色を変えるのも通常は面倒ですが、AFFINGER5(WING)では次のようなメニューで変更できます。

ヘッダーメニューの色設定

ヘッダーメニューの色設定

グラデーションをかけることもできます。仕上がりイメージはこんな感じです。あとは、あなたのセンスにお任せします。

ヘッダーメニューのグラデーションも簡単

ヘッダーメニューのグラデーションも簡単

サイトコンテンツの幅を広げられる

サイト全体のコンテンツ幅を広げたいことってありませんか?

たとえば、グローバルメニューが7項目あるのに6項目までしか入らないときとか。

AFFINGER5でも初期設定ではグローバルメニューに6項目しか入りません。サイトコンテンツの幅が1060pxになっているからです。グローバルメニューの1項目の幅は160pxなので7項目だと1120pxが必要です。

グローバルメニューは6項目が限界

グローバルメニューは6項目が限界

「コンテンツ幅を1120pxに広げれば解決!」と思っても普通のテーマでは簡単ではありません。コンテンツ幅を広げるのにアチコチのCSSのカスタマイズが必要になるからです。

慣れていないと非常に難しいですがAFFINGER5(WING)なら大丈夫です。「AFFINGER5管理」‐「デザイン」メニューでサイトの幅を広げることができます

サイトの幅を広げる

サイトの幅を広げる

ここでは1120pxに広げています。これでグローバルメニューに7項目でも入るようになります。

グローバルメニューに7項目表示できるようになる

グローバルメニューに7項目表示できるようになる

ここまでメニューでできると助かりますよね。

header.phpを編集せずに済む場面が増える

WordPressを使っているとGoogleアドセンスやアナリティクスで「このコードを<head>タグの中にはり付けてください」のような指示に出会います。テーマのheader.phpを開いて<head>あたりにコードをコピーペーストすれば良いとわかりますが、PHPを修正するのは不安ですよね。

AFFINGER5(WING)なら、そんな不安も解消されます。

Googleアナリティクス/Search Consoleの設定

Googleアドセンスの申請タグや広告タグ、Googleアナリティクスのトラッキングタグなど、「AFFINGER5 管理」メニューを開いてコピペすれば済みます。AMP用のアドセンスコード(モバイル広告)までコピペで済むのは助かりますね。

AFFINGER5(WING)のGoogle連携に関する設定

AFFINGER5(WING)のGoogle連携に関する設定

見出し前広告・Google自動広告の設定

「見出し2」(h2)などの前に表示する見出し前の広告もよく見かけます。本文の途中に差し込めるので効果的なのですが、自力で設置するのは非常に面倒です。かなり複雑なPHPコードが必要なので。

そんな見出し前の広告やGoogle自動広告についても、タグをはり付けるだけで設定できます。

見出し前の広告・Google自動広告の設定

見出し前の広告・Google自動広告の設定

何番目の見出しの前に表示したいのか設定するだけで広告を表示できるなんて、広告で収益を上げるには最高のツールじゃないでしょうか?

カスタマイズしやすいテーマというのは、こういうことでしょうね。

作業の手間が省ける分、他の作業に時間をかけられるということです。

広告の非表示設定もあるので、「固定ページに広告は表示しない」のような要件も一瞬で完了できます。普通は「if (!is_page())」とか面倒なコードを書く必要があるので、慣れていないと数日かかったりしますが、そんな心配もありません。

広告の非表示設定

広告の非表示設定

不要な項目を非表示にできる

WordPressを使い込んでいくと、細かいレイアウトにこだわりたくなることもあります。たとえば、記事タイトル上のカテゴリーを非表示にしたいとか、著者名や投稿日などを消したいなど、表示/非表示を制御したくなるパーツが出てきます。

これらのパーツもCSSを書いていけば表示/非表示は制御できるのですが、慣れていない方にとって面倒なのは言うまでもありません。そして、ここまでカスタマイズ機能が充実したAFFINGER5(WING)には期待通り、次のような表示/非表示を制御するメニューが組み込まれています。

表示/非表示を制御するメニューの例
  • 記事タイトル上のカテゴリを非表示にする
  • 投稿ページ記事下のタグ・カテゴリリンクを非表示にする
  • 記事一覧・関連記事一覧などにカテゴリを表示する
  • 記事一覧・関連記事一覧の投稿日(更新日)を非表示にする
  • 記事一覧の抜粋を非表示にする
  • ショートコード記事一覧のカテゴリを非表示にする
  • 更新日がある場合も投稿日を表示する
  • 投稿に「投稿日」「更新日」を表示しない
  • 固定ページに「投稿日」「更新日」を表示しない
  • コメント欄を非表示にする
  • パンクズを非表示にする(display:none)
  • 前と次のページリンクを非表示にする(display:none)
  • 著者情報を表示する
  • 固定ページのタイトルを非表示
  • 下層ページにもヘッダー画像を表示する
  • スマホ・タブレットではヘッダー画像を非表示にする
  • 全ページでヘッダー画像を非表示にする
  • PC用メインメニューを表示しない
  • 開閉式のスマホメニューを表示しない
  • ページTOPへのボタンを表示しない

複雑なCSSと格闘することなく、チェックボックスをON/OFFするだけで不要な項目を非表示にできます。これで、細かいコード記述の手間から解放されることでしょう。

まとめ

以上、細かすぎて伝わらないかもしれないAFFINGER5(WING)の魅力を少しだけ紹介してきました。まだまだ実用的な機能が満載なので当サイトでも紹介していきますが、興味を持った方は、ぜひ、AFFINGER5(WING)をお試しください。

Chrome 68に警告表示で待ったなしのSSL化、不安な方はご相談ください

$
0
0

WordPressのSSL化、完了してますか?サイトのURLを「http://」から「https://」に変更する作業ですが、なかなか面倒ですよね。SEO対策にも役立つと聞いて、いつかチャレンジしてみようと思っていても、なんとなく不安ですよね。自分で設定するのは。

SSL対応、終わってますか?

SSL対応、終わってますか?

サイトのSSL対応が後回しになっている方、いよいよ待ったなし!です。

ご存じかもしれませんが、あと数日(2018年7月下旬)でリリースされる予定のGoogle Chrome 68では、SSL化されていないサイトに警告が表示されます。具体的には「https://」じゃないページにはブラウザのアドレスバーに「保護されていません」と表示されるようになります。

SSL化されていないサイトには警告が表示される

SSL化されていないサイトには警告が表示される

動作に問題があるわけではないので「別に?」「問題なし」と思うかもしれませんし、「Google Chromeは使っていないので関係ない」と思うかもしれませんが、SSL対応は、あなたの問題ではなく、あなたのホームページを見てくれたお客様の問題です。

せっかく見てくれたページで「このサイト、危険なのかな?」と勝手に悪い印象を持たれてしまう可能性も、ないわけではありません。

SEO対策を頑張ってアクセスを増やしても、これでは意味がありません。

余計な不安要素、消せるなら消しておいた方が良いですよね。

SSL対応、すべての作業を代行します

このサイトでもSSL化のヒントをいくつか紹介していますが、意外と面倒かもしれません。ざっくりとした手順は次のとおりです。

サイトのSSL化の手順
  • サーバー証明書の取得
  • URL(メニュー/内部コンテンツ)を「http://」から「https://」に
  • 混在コンテンツ(「http://」の素材)の除去
  • レンタルサーバーの個別対応(さくらインターネットなど)
  • 必要に応じてリダイレクト設定

自力で可能な方は取り組んでいただければ大丈夫ですが、自分で設定するのが不安な方、WordPressサイトのSSL化は待ったなしです。よろしければ作業を代行いたしますのでメールサポートをご利用ください。

※サイトのコンテンツや設定によっては早急なSSL化が難しい場合があります。ご了承ください。

Viewing all 415 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>