テーマのスタイルシート（style.css）の代わりとなるファイルで、フロントエンドとブロック内の両方にスタイルを適用できるようにしています。

また、フロントエンドと管理画面にそれぞれ適用できるよう、以下のファイルを予め用意しており、混乱することなくコードの追加・編集ができるようにしています。

• custom-style.css・・・フロントエンドとブロックへ作用するスタイルコード用のファイル
• custom-admin-style.css・・・管理画面へ作用するスタイルコード用のファイル

以下のスクリプトファイルを用意しています。

• custom-js.js・・・フロントエンドへ適用するスクリプトの記述用
• custom-admin-ja.js・・・管理画面へ適用するスクリプトの記述用

どちらもWordPress標準のjQueryの読み込み後に適用されるようにしていますので、JavaScript、jQueryのどちらを記述してもきちんと適用されるようにしています。

また、読み込みを遅延（defer）読み込みさせ、フッターへ出力することで、ページ表示に悪影響がないよう配慮しています。

以下の例ようにPHPコード中の文字列に国際化関数を使った場合に翻訳候補として認識されるようにしています。

__('文字列','ha-my-functions');

Loco Translateのようなプラグインを使えば簡単に国際化対応ができるようにしています。

翻訳ファイルはファイルの消失防止と確実な適用を行うため、「プラグインディレクトリ」→「languages」の中にあるものを画面を開くたびにWordPress本体のプラグイン翻訳ディレクトリへ上書きするようにしています。Loco Translateなどを使用する場合はそちらのディレクトリのファイルを操作ように指定してください

テーマでは「ツール」→「テーマファイルエディター」から有効化しているテーマのstyle.css他のファイルがすぐに開けるようになっていますが、プラグインの場合は「ツール」→「プラグインファイルエディター」を選択後、プラグイン名をプルダウンから開いて適用させないと編集画面が開けず、プラグインをたくさん使っているサイトでは目的のプラグインを探すのに手間がかかります。

そこで本プラグインでは、管理画面の左メニュー内に「HA My Functions」というメニューを設け、一発でこのプラグインの編集画面を開けるようにしています。

WordPressにはテーマファイルエディター、プラグインファイルエディターという、コードを編集するツールがあります。

このツールに関しては、パソコン上で編集した後でファイルをアップロードしたほうがいいという意見がありますが、特にPHPの編集に関しては、無碍に更新してサイトにエラーが発生してサイトがストップすることが極力ないようにチェックが走るようになっており、エラーが見つかった場合には未保存の状態に戻るようになっています。

特別な理由がなければこのチェックを利用しない手はないと思いますので、ぜひWordPress標準のエディターを活用ください。

WordPressでは同一サイト内で同一のユーザー定義関数は使用できません。これはサイトへの適用の流れが「ユーザー定義関数で記述したプログラム」を「WordPress側やテーマ・プラグイン側で用意されているフックに引っ掛けて流し込む」ようになっていて、同じユーザー定義関数を許容してしまうとフックさせる際にどれが正しいプログラムかを判別できなくなるからです（と書いていますがWordPressに限らずプログラムでは当たり前の話）。

テーマに記述しているプログラムを本プラグインのカスタムファイルに移行する場合は以下のようにすると重複が避けられます。

1. テーマに記述しているプログラムコードで「ユーザー定義関数」と「アクションフックやフィルターフック」がセットになっているものは、テーマ側から切り取ってパソコンのメモ帳などへ貼り付けてから保存し、保存したコードを本プラグインの適切な場所に貼り付けて保存する
2. テーマに追加しているファイルやディレクトリ内のプログラムを呼び出している場合には、テーマ側の呼び出しコードをコメントアウトして機能を一時停止し、ファイルやディレクトリを移行後、適切な呼び出しコードで呼び出す

なお、他のテーマやプラグインと関数名が重複してしまうのを避けるため、コード基準では、そのテーマやプラグインのディレクトリ名に関連する文字列（本プラグインなら「ha_my_functions」など）を関数名の先頭に付けることが推奨されていますので、移行した関数名も変更することが望ましいですが、コードによっては関数内で他の関数を呼び出して処理をするというケースも多々あるため、何の気なしに変更するとトラブルになる可能性がありますから、現在問題なく稼働しているのであれば無理に変更しないのも手かと思います。

ファイルのパスやURLの指定

テーマの中のファイルの場所（パス）やURLを参照する場合には以下のように記述することが多いです。

get_theme_file_path( '/ファイルまでのディレクトリとファイル名.拡張子' ); //パス
get_theme_file_uri( "ファイルまでのディレクトリとファイル名.拡張子" ); //URL

前者は有効化しているテーマの．．という前提の関数で、そのまま移行するとファイルが見つからなくなりますので以下のように書き換えます。

プラグインのパス

plugin_dir_path( __FILE__ ) .'ファイルまでのディレクトリとファイル名.拡張子'

プラグインのURL

plugin_dir_url( __FILE__ ) .'ファイルまでのディレクトリとファイル名.拡張子'

ディレクトリ（パス）についてはPHPの__DIR__ というマジック関数を使うという方法もありますが、この関数は「現在いるパスと同じレベルのパス」を指定するもので、使い方によっては間違いの元になる可能性がありますので注意しましょう。

プログラムの呼び出し

他のファイルにあるプログラムを呼び出す（動作させる）時、テーマでは以下のようにPHP関数の「include」を使用することが多いです。

include get_theme_file_path( '/ファイルまでのディレクトリとファイル名.拡張子' );

この関数はプラグインで使用するとエラーになるので、以下のように「require_once」というPHP関数を使用したコードに書き換え、ファイルへの参照もプラグインのパスへ変更します。

require_once (plugin_dir_path( __FILE__ ) .'ファイルまでのディレクトリとファイル名.拡張子');

WordPressは「本体の読み込み」→「プラグインの読み込み」→「テーマの読み込み」の順で処理が行われ、プログラムもそれに従って処理されていきます。

ほぼ問題なく動作するとは思いますが、テーマに追加していたプログラムを本プラグインへ移行した場合動作に不具合や不都合が発生することがあります（特にテーマ特有の関数を使う場合には注意）。

また、スタイルコードについても、HTML上での出力順を何も指定しなければ上記の逆順で優先度が高まる（次々に上書きされていく）ため、テーマに書いていたスタイルコードをそのまま移行すると適用されないという場合が発生することがあります。

プログラムの場合は確実に動作しているかのチェックを行うこと、スタイルコードの場合は末尾に「!important」を付けて優先度を上げるといったチェックや工夫が必要になるケースがありますので注意してください。