add_shortcode() の使い方

WordPress で ショートコードを追加するためには、add_shortcode() を使います。
設定は functions.php に書きましょう。

メリット

ショートコードを使えば例えば WordPress のコンテンツ内で PHP のコードを実行させるような動作が容易になります。

記事内の使い方

タグの使い方

タグの記法がいくつかあります。

タグでコンテンツを挟むタイプを基本と考えておくと良いです。

[tag]コンテンツ[/tag]

タグでは属性を扱うことができます。

[tag hoge="属性値"]コンテンツ[/tag]

属性でパラメータを設定することで柔軟な設定が可能です。

functions.php の表記

構文は以下になります。

<?php add_shortcode( $tag , $foo ); ?>

前の引数 $tag とあるものがショートコードになります。

関数側はこんな感じで引数やコンテンツを受け取ることができます。

function foo( $atts, $content = "" ) {
	return 'content = $atts["bar"] . $content';
}
add_shortcode( 'tag', 'foo' );

参考

関数リファレンス/add shortcode – WordPress Codex 日本語版

wp_head() の使い方

スクリプトタグやメタタグを出力するには、wp_head() を使用します。

使い方

スクリプトタグを出力したいテーマないの場所(head タグ内)で、wp_head()をよびます。

<?php wp_head(); ?>

基本的にページで一度だけ呼び出します。WordPress で wp_head() を削除すると動作に支障が場合があります。

また、wp_head() には引数がありません。
従ってカスタマイズしたい場合は、functions.php に記述することになります。

wp_head()に追加

内容を追加する場合は、functions.php で add_actionを使います。

以下の例では、style タグを追加しています。

add_action( 'wp_head', 'add_style_tag' );

function add_style_tag() {
	echo "<style> .wp_head_class { background-color : red; } </style>";
}

出力コードの編集

wp_head() に出力されるコードを編集するには、functions.php に add_filter でスクリプトに追加するコードを書くのがよくあるやり方のようです。

if (!(is_admin())) {
	function add_attr_for_style($url) {
		return 編集処理;
	}
	add_filter('clean_url', 'add_attr_for_style', 10, 1);
}

style タグに属性を追加するようなパターンですね。

参考

関数リファレンス/wp head – WordPress Codex 日本語版

プラグイン API/アクションフック一覧/wp head – WordPress Codex 日本語版

clean_url | Hook | WordPress Developer Resources

dynamic_sidebar() の使い方

ウィジェットエリアを呼び出すために dynamic_sidebar() を使用します。

テーマ作成では頻出の関数でしょうか。

メリット

WordPress を使いこなすにはウィジェットの活用が効果的です。
会社ページによくある「お知らせ」のようなエリアを作るには dynamic_sidebar() が便利です。

sidebar という名前がついていますが、ウィジェットを呼び出せるので直感的にはわかりにくい気がします。

使い方

ウィジェットを表示したい場所で dynamic_sidebar() を呼びます。

<?php dynamic_sidebar(サイドバーの名前かID); ?>

例えば、newsという名前のウィジェットを呼び出したい場合は引数に名前を渡します。

<?php dynamic_sidebar('news'); ?>

参考

https://wpdocs.osdn.jp/%E9%96%A2%E6%95%B0%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9/dynamic_sidebar

get_sidebar()の使い方

テーマディレクトリに置かれた sidebar.php という名前のテンプレートファイルを読み込む関数です。

テーマ作成では良く出ててくる関数なので覚えておくといいでしょう。

メリット

WordPress のテーマを作っていくと、ついテーマが複雑になっていきます。
サイドバーとしての役割は、sidebar.php などのテンプレートファイルに分割し、テーマをシンプルに保つようにしてください。

そのような際に get_sidebar() が役立ちます。

使い方

get_sidebar は呼ぶだけで sidebar.php を呼び出します。

<?php get_sidebar( サイドバー名 ); ?>

サイドバー名を指定しなければ sidebar.phpを呼び出します。
get_sidebar( ‘news’ ); のようにサイドバー名を指定すると、sidebar-news.php を呼び出します。

テンプレートファイルと合わせて get_sidebar による読み込みが必要です。

参考

https://wpdocs.osdn.jp/%E9%96%A2%E6%95%B0%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9/get_sidebar

エスケープをする esc_attr

WordPress でエスケープをする esc_attr() の使用方法です。

echo esc_attr($text);

フォームの値を表示する場合は必ず esc_attr() を使用してエスケープするようです。

参考

https://wpdocs.osdn.jp/%E9%96%A2%E6%95%B0%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9/esc_attr

CSRF対策のwp_nonce_fieldの使い方

CSRF 対策で wp_nonce_field() を利用することができます。

使い方

wp_nonce_field() を呼ぶとhidden要素が生成されます。

wp_nonce_field( $action, $name, $referer, $echo );

form タグ内に wp_nonce_field() を呼んで出力された HTML コードを確認してみるとわかりやすいです。

参考

https://wpdocs.osdn.jp/%E9%96%A2%E6%95%B0%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9/wp_nonce_field

get_stylesheet_directory_uri()の使い方

テーマのパスを取得する関数です。get_template_directory_uri()とほぼ同じです。
違いは「子テーマをの場合、子テーマのディレクトリパスを返す」ここがポイントです。

メリット

get_stylesheet_directory_uri() を使用するとこで、子テーマのパス指定が簡単になります。SSL 対応やドメイン変更など運用にも強いコードになります。

使い方

echo で出力して使います。

<a href="https://camon.tokyo/" ><img src="<?php echo get_stylesheet_directory_uri(); ?>/images/logo.png" /></a>

この辺りもget_template_directory_uri()と基本的には変わらないですね。

参考

https://wpdocs.osdn.jp/%E9%96%A2%E6%95%B0%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9/get_stylesheet_directory_uri

get_template_directory_uri() の使い方

get_template_directory_uri() はテーマのディレクトリパスを取得する関数です。

WordPress のテーマを編集する際、必ず遭遇するのが get_template_directory_uri() と言っても過言ではないでしょう。

メリット

テーマで get_template_directory_uri() を利用しておくことで、SSL 対応やドメイン変更など WordPress の運用に強いコードを作ることができます。

使い方

テーマのディレクトリパスを取得したい場合に利用します。
get_template_directory_uri が意味するテーマとは親テーマのことです。ここがポイントです。

出力は echo で行います。

<a href="/"><img src="<?php echo get_template_directory_uri(); ?>/images/camon_logo.png" /></a>

echo と組み合わせて HTML 内に出力というのが多いですね。

子テーマの場合

子テーマでテーマの パスを取得したい場合は、get_template_directory_uri ではなく、get_stylesheet_directory_uri を使用します。

参考

https://wpdocs.osdn.jp/%E9%96%A2%E6%95%B0%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9/get_template_directory_uri

WordPressの管理画面にメニューを追加するadd_menu_pageの使い方

WordPress 管理画面に独自メニューを追加できる、add_menu_page() をご紹介します。

add_menu_page() は管理画面に独自のメニューを追加できる関数なので、テーマ開発やプラグイン開発で必ず登場する関数とも言えます。

使い方

add_menu_page() ですが引数が多めです。

add_menu_page( string $page_title, string $menu_title, string $capability, string $menu_slug, callable $function = '', string $icon_url = '', int $position = null )

引数はストリング型が多いです。最後のポジションが int 型です。

呼び出し関数の中で、表示したい内容を記述すれば、追加したメニューに反映されます。

呼び出すには

add_menu_page() は add_action のアクションフックを使用します。

//管理画面にメニューを追加
function add_my_menu() {
    add_menu_page( 'page_title', 'menu_title', 'administrator', __FILE__, 'function_name', '', 8);
}
add_action('admin_menu', 'add_my_menu');

上記例の中にある、function_name 部分で HTML 出力コードを記載すると良いでしょう。

position について

パラメータの $position には管理画面での表示位置を数字で指定します。

Default: bottom of menu structure #Default: bottom of menu structure
2 – Dashboard
4 – Separator
5 – Posts
10 – Media
15 – Links
20 – Pages
25 – Comments
59 – Separator
60 – Appearance
65 – Plugins
70 – Users
75 – Tools
80 – Settings
99 – Separator

https://developer.wordpress.org/reference/functions/add_menu_page/#menu-structure

例えば管理画面にある設定項目の下に表示するには80を指定します。
ここは実際にコードを書いて試してみるとわかりやすいです。

参考

translate() または、__()、_e()で翻訳のための関数について

国際化、翻訳のための関数です。
__() は translate() のエイリアスとのことですが、translate()は直接しようしないようにせよとありました。

使い方

使い方
<?php translate( $text, $domain ) ?>
パラメータ
$text
string) (必須) 翻訳するテキスト。初期値: なし
$domain
string) (optional) 翻訳テキストを取得するドメイン。初期値: ‘default’
戻り値
(string) 
翻訳されたテキスト。

https://wpdocs.osdn.jp/%E9%96%A2%E6%95%B0%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9/translate

公式ディレクトリに公開するようなプラグインやテーマなどは__()を利用しておいて、基本的には多くの言語に対応したほうがいいですね。

日本人のみを対象とした有料プラグインなどでは不要かもしれません。

参考