Web サービス（競技会採点システム COMPE-Scoring）上で、パスワードレスログインのために、Passwordless Login というプラグインを使用していました。ログイン時にメールアドレスを入力し、返信されてきたメールのマジックリンクをクリックするとログインできるというものです。ユーザーは２アクション必須なのですが、ログインしているユーザーの管理画面上から複数のユーザー宛てにマジックリンク付きのメールを送信する必要があり、Magic Login Mail を作成しました。以下の動作の、最初～15秒までが、２アクションのもの、22秒～最後までが１アクションのものです。

Passwordless Login を改変したものです。コードを見て、ん？と思うところを修正・削除し、上記の１アクションの機能をアクションフックとして追加しました。

compe-scoring.com

https://compe-scoring.com/ja/

Passwordless Login

1,000以上サイトで有効化中

2026-03-31 09:29 時点の統計

Magic Login Mail or QR Code

100以上サイトで有効化中

2026-03-31 09:29 時点の統計

動作

使い方

• 固定ページに、[magic_login]というショートコードを設置するだけです。そのページがログインの為のページになります。

• ユーザーとして登録されたメールアドレスが入力されると、ログインリンクを含むメールが送信されたというメッセージが出力され、メールにログインリンクが届き、リンクをクリックするとログインします。

• ユーザーとして登録されていないメールアドレスを入力するとエラーが出ます。デフォルトでは１０分以内に、リンクをクリックしないと期限切れのエラーが出ます。

カスタマイズ

管理画面はありません。カスタマイズは、フィルターフックとアクションフックで行います。上記のリンク先に、サンプルコードが書いてありますので、それを見て行ってください。

セキュリティ対策

このプラグインと併せて以下の様なセキュリティ対策を行う事もできると思います。

wp-login.php にアクセスしてきたら、ホームページへリダイレクトする

/** ==================================================
 * Redirect to home if the URI is wp-login.php
 *
 * @since 1.00
 */
function redirect_login() {
	if ( ! is_user_logged_in() && isset( $_SERVER['REQUEST_URI'] ) && ! empty( $_SERVER['REQUEST_URI'] ) ) {
		$request_uri = esc_url_raw( wp_unslash( $_SERVER['REQUEST_URI'] ) );
		if ( 'wp-login.php' === wp_basename( parse_url( $request_uri, PHP_URL_PATH ) ) ) {
			wp_safe_redirect( home_url(), 302 );
			exit();
		}
	}
}
add_action( 'init', 'redirect_login' );

Simple License Key for WooCommerce

ウェブサービス用の WooCommerce 商品のライセンスキーを生成します。

作者: Katsushi Kawamori

(0) 最終更新: 2日 前

3,292ダウンロード 検証済み: 7.0

ダウンロード: リリース: 2021-09-23

2026-03-31 09:30 時点の統計

プラグイン自体は可能な限りシンプルにしていて、以下の機能に絞っています。

• 購入されたライセンスキーを暗号化して Rest API で出力
• 商品にライセンスキーを付与するかのチェック
• ライセンスキーの有効期日の指定

後は、購入したユーザーが、Web サービス上でメールで届いたライセンスキーを入力すると、それを復号化して検証するという仕組みです。それについては、Web サービス上でコードを書く必要があります。暗号化は、OpenSSL の共通パスフレーズを用いています。コードに関しては、WordPress の管理画面上での PHP と、React で以下に記していきますが、Rest API と、OpenSSL を利用しているので、他の言語やシステムでも別のコードを書けば使えると思います。その辺りに詳しい方は、チャレンジしてみてください。

動作

ライセンスキー販売サイトの商品の設定

ライセンスキーを発行にチェックし、有効期限を決めます。有効期限を過ぎると、REST API への暗号化されたライセンスキーの出力は無くなります。商品は、バーチャルにチェックを入れます。

ライセンスキー販売サイトのプラグイン側の設定

共通パスフレーズを決めます。これは流出しないように大切に保管してください。また、プラグインの設定画面上で、REST API の URL を知る事ができます。この２点は、後で PHP と React 上に書き込みます。

Web サービス側の PHP コード

子テーマの、functions.php に書く前提で記していきます。

ライセンスキーを入力するためのメニューページを作成するコード

• 管理画面に、Test License というページを作成
• ページには、React を利用するので、id 属性を指定して、echo するのみ

/** ==================================================
 * Add Menu for Test license
 *
 * @since 1.00
 */
function add_pages() {
	add_menu_page(
		'Test License',
		'Test License',
		'edit_posts',
		'TestLicense',
		'credit_page'
	);
}
add_action( 'admin_menu', 'add_pages' );

/** ==================================================
 * Credit
 *
 * @since 1.00
 */
function credit_page() {

	echo '<div id="test-license-page"></div>';

}

メニューページに読み込むスクリプト用のコード

• 子テーマ内に、test-license というフォルダを作成し、その下の dist フォルダ内に、React の build ファイルを置くためのコード

/** ==================================================
 * License Page Scripts
 *
 * @param string $hook_suffix  hook_suffix.
 * @since 1.00
 */
function license_page_scripts( $hook_suffix ) {

	if ( 'toplevel_page_TestLicense' !== $hook_suffix ) {
		return;
	}

	$asset_file = include( get_stylesheet_directory() . '/test-license/dist/test-license.asset.php' );

	wp_enqueue_style(
		'test-license-style',
		get_stylesheet_directory_uri() . '/test-license/dist/test-license.css',
		array( 'wp-components' ),
		'1.0.0'
	);

	wp_enqueue_script(
		'test-license',
		get_stylesheet_directory_uri() . '/test-license/dist/test-license.js',
		$asset_file['dependencies'],
		$asset_file['version'],
		true
	);

}
add_action( 'admin_enqueue_scripts', 'license_page_scripts', 10, 1 );

REST API を出力し、入力されたライセンスキーを検証するコード

• 権限は以下の場合は編集者権限
• license_api_verify 内の検証コード内に、復号化のための共通パスフレーズを記す
• 検証して、入力されたライセンスキーと、プラグインの入っているライセンスキー販売サイトの REST API を復号化したものが一致していれば、ユーザーオプションテーブルの test_licensed を true にする

/** ==================================================
 * Register Rest API
 *
 * @since 1.00
 */
function register_rest() {

	register_rest_route(
		'test/license_api',
		'/token',
		array(
			'methods' => 'POST',
			'callback' => 'license_api_verify',
			'permission_callback' => 'editor_rest_permission',
		)
	);

}
add_action( 'rest_api_init', 'register_rest' );

/** ==================================================
 * Rest Permission for editor
 *
 * @since 1.00
 */
function editor_rest_permission() {

	return current_user_can( 'edit_posts' );

}

/** ==================================================
 * License Rest API verify
 *
 * @param object $request  changed data.
 * @since 1.00
 */
function license_api_verify( $request ) {

	$args = json_decode( $request->get_body(), true );

	$input_license_key = $args['license_key'];
	$get_license_api_arr = $args['license_api'];
	foreach ( $get_license_api_arr as $key => $value ) {
		/* 共通パスフレーズは、プラグイン側で指定したもの。以下の場合は、'm#xs@%5NhZlR' */
		$get_license_key = openssl_decrypt( $value['open_key'], 'aes-256-cfb', 'm#xs@%5NhZlR', 0, openssl_cipher_iv_length( 'aes-256-cfb' ) );
		if ( $get_license_key === $input_license_key ) {
			/* ライセンスが一致した時の処理 */
			update_user_option( get_current_user_id(), 'test_licensed', true );
		}
	}
	$args['licensed'] = get_user_option( 'test_licensed', get_current_user_id() );

	return new WP_REST_Response( $args, 200 );

}

Web サービス側の React コード

LicenseCheck コンポーネント

• Fetch で販売サイトの REST API を取得
• apiFetch で Web サービス側で、ライセンスキーを入力したものと、Fetch で取得した暗号化されたライセンスキーを php 側と通信

import './license-check.css';

import apiFetch from '@wordpress/api-fetch';

import { Button, TextControl } from '@wordpress/components';

import {
	useState,
	useEffect
} from '@wordpress/element';

const LicenseCheck = ( props ) => {

	const [ paidFlag, updatePaidFlag ] = useState( false );
	const [ paidText, updatePaidText ] = useState( '' );

	const [ currentLicense, updateCurrentLicense ] = useState( '' );
	const [ licenseApi, updateLicenseApi ] = useState( {} );

	const items_licensed = [];
	if ( ! paidFlag ) {
		items_licensed.push(
			<div>
				<hr />
				<h3>{ props.license_text }</h3>
				<p className="description">{ props.purchase_description }</p>
				<div>
					<Button
						className="button button-large"
						href={ props.purchase_site }
						target="_blank"
					>
					{ props.purchase_text }
					</Button>
				</div>
				<div className="license_key_input_line">
					{ props.license_text_input }
					<TextControl
						className = "license_key_input"
						value = { currentLicense }
						onChange = { ( value ) => updateCurrentLicense( value ) }
					/>
				</div>
			</div>
		);
	}

	useEffect( () => {

		fetch( props.url )
		.then( response => response.json() )
		.then( data => {
			//console.log( data );
			updateLicenseApi( data );
		} );

		apiFetch( {
			path: props.path,
			method: 'POST',
			data: {
				license_key: currentLicense,
				license_api: licenseApi,
			}
		} ).then( ( response ) => {
			//console.log( response );
			if ( response['licensed'] ) {
				updatePaidFlag( true );
				updatePaidText( props.paid_text );
			} else {
				updatePaidFlag( false );
				updatePaidText( props.no_paid_text );
			}
		} );

	}, [ currentLicense ] );

	return (
		<div className="wrap">
			<h2>{ props.title }</h2>
			<h3>{ paidText }</h3>
			{ items_licensed }
		</div>
	);

};

export default LicenseCheck;

コンポーネント用の CSS

.license_key_input {
	width: 200px;
}
.license_key_input_line {
	display: inline-flex;
}

メインのコード

• コンポーネントを読み込む。コンポーネントの属性に各種値を入力。
• 属性
  • title : タイトル
  • license_text : タイトル２
  • purchase_description : 購入の説明
  • purchase_text : 購入ボタンの文字
  • purchase_site : ライセンスキー商品販売ページの URL
  • license_text_input : ライセンスキー入力フォームの左側のテキスト
  • paid_text : ライセンスされている事を示すテキスト
  • no_paid_text : ライセンスされていない事を示すテキスト
  • url : ライセンス販売サイトの REST API の URL（プラグインの設定画面に記してあるもの）
  • path : Web サービス側の REST API のパス（PHP に記したパス）

import './test-license.scss';

import { render } from '@wordpress/element';

import LicenseCheck from './components/license-check';

const TestLicenseView = () => {

	return (
		<div className="wrap">
			<LicenseCheck
				title = { 'ライセンスチェックテスト' }
				license_text = { 'ライセンスキー' }
				purchase_description = { '以下のショップで購入したライセンスキーを入力すると制限が解除されます。' }
				purchase_site = 'https://shop-jp.riverforest.test/product/license'
				purchase_text = { '購入' }
				license_text_input = { 'ライセンスキー入力' }
				paid_text = { 'ライセンス済み' }
				no_paid_text = { '未ライセンス' }
				/* REST API by Simple License Key for WooCommerce */
				url = 'https://shop-jp.riverforest.test/wp-json/rf/slk-woo-open-key_api/token'
				/* Web service REST API */
				path = 'test/license_api/token'
			/>
		</div>
	);

};

render(
	<TestLicenseView />,
	document.getElementById( 'test-license-page' )
);

メインの CSS

#test-license-page {
}

ダウンロード

コードを子テーマ毎一式以下に置きました。

WordPress の公式プラグインを作成し始めてから６年、いつの間にか多数のプラグインを作成しました。それに機能を付与するアドオンの販売状況と、無料でプラグインを作成する意味を考えてみました。

profiles.wordpress.org

Katsushi Kawamori (@katsushi-kawamori) – WordPress user profile | WordPress.org

公式プラグイン一覧

2012年～2013年

• Perl で作成したプログラムを PHP に移植、それをプラグイン化した。
• 純粋に職場のサイト更新の手間を省くためのものでした。

2013年～2016年

• 必要があって、いろいろ作成していく。
• プラグイン Media from FTP がヒットし、世界中で使われるようになる。
• サポートフォーラムで様々な要望に応える。
• ますますヒットする。
• 無料で作り続けるのが馬鹿馬鹿しくなる。

2016年～2018年

• プラグインのアドオンやテーマを個人で販売している人が存在するのを知る。
• WordCamp で情報収集しプラグインのアドオン販売を考える。
• プラグインのアドオン販売開始。
• 初期の頃は、売り切り60ドルで販売。少し売れる。
• 周囲から安いのではと言われ、120ドルにしたら売れなくなる。
• 売り切り100ドルにし、サブスクリプション年額60ドルも開始。
• サブスクリプションが売れないのとサブスクリプションソフトウェアの有償化でサブスクリプションを辞める。
• 初期の値段60ドルの売り切りに戻す。売れ行きが戻る。
• Webサービスボールルームダンス競技会採点システムを開始。

現在

• 2019年初頭から、アドオン販売を大幅値下げ、60ドルを30ドルにする。
• 半額に値下げしたにもかかわらず、1.5倍の売上増。実質3倍の伸び。
• アドオンの適正価格は、30ドル以下であると知る。
• アドオンは下手なアルバイトよりも儲からないと実感する。
• ボールルームダンス競技会採点システムからいくつかの機能を分離し公式プラグインとする。
• Webサービス競技会採点システムを開始。
• 競技会採点システムが１団体に導入されて報酬を得る。

雑感

まず最初に思うのは、ソフトウェアの為のソフトウェア（この記事ではアドオン）よりも、サービス（この記事ではWebサービス）の方が報酬になるという事です。

それを理解した時から、無料で公式プラグインを作成する事が苦で無くなり、むしろ積極的に行うようになりました。自分のプラグインだけでは無く、人の作成したプラグインの力も借りて、Webサービス競技会採点システムで報酬を得たからです。

世の中ではソフトウェアの為のソフトウェアを買う人よりもサービスを買う人の方が多いのではないかと思います。それならば、皆で無償で知恵を出し合いソフトウェア(この記事ではWordPress)をより良いものにしてどのようなサービスにでも変幻自在に対応できるようにすべきだというのが今の心境です。

それがいつか報酬となって返ってくるはずだと思います。

昨年１１月に「ボールルームダンス競技会採点システム」、今年４月に、「競技会採点システム」を開発しましたが、未だに契約者が一団体にとどまっています。宣伝のために、最初に WordCamp Tokyo 2019 でのブース出展を思い立ちました。

設営

写真( GOUTEN さんが私のスマホで撮影 )の様なブースです。PC１台と、iPad３台を設置しました。一人なので、セキュリティーワイヤーを設置しています。 タッチ用にタッチペンを準備しました。 また、チラシを２００部刷りました。

※GOUTEN さん、撮影ありがとうございました。

ブースにて

ほぼ、ブースに張り付いていました。キタジマタカシさん言うところ「なかなか尖ったシステム」だという事を実感しました。デモを観て、「おお！」と感動してくださるのですが、それをどう自身の仕事に生かせるのかというとクエスチョンマークのようです。WordPress を利用して仕事をしている方向けでは無く、採点の現場にいる方向けのシステムだと感じました。

そんな中、御自身の仕事と採点システムがつながりそうな方が４名いました。その中の２名は、実際に採点システムの運用を考えてくださりそうでありがたいです。また１名は通信業者 X-mobile の方で、以前から採点システムの現場での WiFi 接続に関して頭を悩ましていましたが、それが X-mobile さんと提携することで解消しそうです。最後の１名は、北海道から参加された藤田辰也さんです。昨年の WordCamp Osaka 2018 以来で、今回も素晴らしい成果品を見せていただきました。

ブースツアーが午前と午後の２回ありました。午前の部では、まだ説明に不慣れで上手く説明できませんでしたが、午後の部では上手く説明できたと思います。ツアーを盛り上げてくださった谷合美香さん、ありがとうございました。

会場について

今回、スポンサーが例年になく多い４０社との事で、配置に苦労したとの事です。スポンサー担当の中谷智美さん、初期段階から 大変お世話になりました。また、ありがとうございました。

スポンサーの中で、フリーランスはキタジマタカシさんと私だけだったようです。

SNOW MONKEY BRAND BOOK

ほぼ自分のブースに張り付いていましたが、このブログのテーマでもある Snow Monkey のブースに行き、冊子をいただきました。凄く綺麗な冊子で冒頭にはキタジマタカシさんの熱い文章が書かれていました。巻末の奥様の漫画上手すぎです！

snow-monkey.2inc.org

Snow Monkey – どんな味付けにも染まる。高級お出汁のような WordPress テーマ、Snow Monkey

どんな味付けにも染まる。高級お出汁のような WordPress テーマ、Snow Monkey

お弁当、カフェラテ

美味しいお弁当が出ました。また会場にバリスターコーナーが設けられ、お洒落で美味しいカフェラテをいただきました。

アフターパーティー

場所を移動して、クラブでのアフターパーティーに参加しました。なるべく、大勢の方とお話ししようとしてあちこち動き回りました。私に応じてくださった皆様、ありがとうございました。

最後に

実行委員長はじめ、実行委員、当日スタッフの皆様、本当にお疲れ様でした。そして、ありがとうございました。

２０１９年１１月１日、１１月２日に開催される、WordCamp Tokyo 2019 で Bronze スポンサーとしてブース出展します。ブース出展は、１１月２日です。

内容

昨年より始めたWebサービスのボールルームダンス競技会採点システム、競技会採点システムのデモンストレーションを行います。PC１台とタブレット３台で行います。お気軽にお立ち寄りください。

４月２０日（土）のセッションデイのみ参加し登壇しました。昨年の WordCamp Osaka 2018 以来の方、ネットでの知り合いでしたが初見の方、人から紹介された方、こちらから話しかけた方等、複数の方と知り合いになり、いろいろとお話しし有意義な１日を過ごしました。

登壇ですが、今回スライド内のコードをポインターで指しながら発表しました。以下にスライドを共有しますが、スライド内に説明がほとんど書いてなく、また、発表の動画を見てもわかりづらいかもしれないと思いました。補足説明の必要性を感じましたので、以下で説明させていただきます。

補足説明

１２ページ　予選

実際の画面です。この例ですと１ヒートに１２～１３組踊ります。画面の下に６ヒートがあります。審査員が、通過者をチェックしていきます。出場７４組中４８組をピックアップします。注意すべきは、ヒート毎に選ぶのではなく全体で選ぶというのが公式のルールです。最後のヒートが終わった後に、アップ数があっていなければならないので、審査員が数合わせができるように、気になった選手の印し用にタップすると黄色になるようにしました。もし数が合わなければ黄色のところにチェックをするという仕組みです。赤文字のカウントは現在チェックしている数です。アップ数の４８以外は赤になり、また４８にならなければ送信ボタンが現れない仕組みにしました。

１５ページ　決勝

上段番号が背番号、下段が順位です。下段をスワイプして順位を確定します。重複状況が赤で表示されます。重複が無くなると送信ボダンが表示され送信できます。

２１ページ　登録直後の通知メール

実際にプラグインを動作させて、登録するとこの様なメールが届くしくみです。「複数のユーザーが以下の様に追加されました。」というメッセージ以降にユーザー名とパスワードリセットリンクが複数追加されます。

２２ページ　管理画面とデーターベースの確認

実際に管理画面と、データーベースを確認してみると、メールアドレスが全て同じになっているのがわかります。

２３ページ　プラグインの管理画面

親ユーザーと子ユーザーという概念を導入しました。登録する親ユーザーには、採点システムを管理する独自の権限グループを与え、審査員端末のユーザーには購読者の権限グループを与えました。新規ユーザーのデフォルト権限グループは親ユーザーの権限と合わせなければなりません。また、子ユーザーの追加数を課金システムと連動させるために２種類用意しました。

２４ページ　採点システム側の登録時

action_add_user 関数を、user_register にフックしています。親ユーザーの登録があったら、登録を締め切ります。また６日間でアカウントを削除する BdcScoringAcountHook にフックしています。

２５ページ　Add Multiple User 側の登録時

登録時のフックに対応する関数です。親ユーザーのデフォルト権限で登録した場合に、auto_insert_users 関数を実行します。

２６ページ　複数ユーザーの登録とメール通知

パラメータとして、親ユーザーのメールアドレス、ユーザー追加カウント最小数、ユーザー追加カウント最大数、ユーザー名の接頭辞、子ユーザーの権限を持ちます。まずユーザー数だけループさせて、wp_insert_user 関数で登録します。その登録 ID を配列に入れておきます。次に、登録 ID の配列をループさせて、wpdb でそれぞれの子ユーザーの users テーブルのメールアドレス欄に親ユーザーのメールアドレスを書き込みます。

２７ページ　審査員端末のパスワードリセットを試す

実際にうまく動作するか、ログイン画面の「パスワードをお忘れですか？」リンクから、子ユーザーである審査員端末のパスワードリセットを試しました。無事に親ユーザーであるオペレーターアカウントのメールアドレスにパスワードリセットリンクの入ったメールが配信されました。

２９ページ　課金による端末（ユーザー）追加

実際の画面です。上部は、５端末で無料の画面で Stripe で課金します。下部は、課金後の画面です。課金用の画面が無くなり、２２端末まで利用可能になっているのがわかります。

３０ページ　課金による端末（ユーザー）追加の通知

実際のメール通知はこのようになります。この場合は、以前の５ユーザーに１７ユーザー追加され合計２２ユーザーまで拡張されます。

３１ページ　採点システム側の課金時

simple_stripe_payment_charge、 simple_pyapal_payment_charge というフィルターをプラグイン側で用意しました。このフィルターは課金が成功した場合に動作します。また、Stripe, PayPal ボタンのショートコードをプラグイン側で用意しました。このボタンを押すと課金画面が現れます。フィルターを、paypal_charge、 stripe_charge という関数にフックさせます。それらの関数の中で、Add Multiple User で用意したアクションフック amu_paid_add_user を呼び出します。アクションフックが呼び出されると、設定しておいた子ユーザーの課金済みの追加数を追加する仕組みです。

３３ページ　採点システム側の削除時

親ユーザー登録時に６日で登録しておいたフック、BdcScoringAcountHook が動作した時に、delete_data_account 関数が呼び出され、親ユーザーのアカウントが削除されます。ここには書いてありませんが、親ユーザーを削除すると子ユーザーも一括削除される仕組みになっています。 action_delete_user 関数は、delete_user にフックしていて親ユーザーが削除された時に動作します。users_can_register オプションを TRUE に戻し外部から登録できるようにします。 念のために BdcScoringAcountHook をクリアしています。

３４ページ　その他の Web サービスとしての機能

同じ審査員のアカウントで採点はできないので、重複ログインの禁止は必須です。Ban Double Login は、Facebook で流れていたのを思い出して、使用してみたところ、用途にピタリとあったので採用しました。

Locale Auto Switch は、ブラウザの言語設定で WordPress の言語を切り替えます。

セキュリティ対策は、Loginizer の他にファイルのパーミッションや.htaccessファイルなどに施しています。

パスワードリセット対策は、パスワードの入力の間違いを軽減させるものです。オペレーターアカウントのPCのブラウザと審査員端末のブラウザの同期ができれば問題ないのですが、そうで無い場合の方が多いです。その際にパスワードを直接入力する事になります。たいていのユーザーは推奨されたパスワードを使用するはずです。その際にエルの小文字とアイの大文字とか、オーの大文字とゼロとかを間違えて何度もパスワードリセットを繰り返すというヒューマンエラーが起こりやすく非常なストレスになります。それらの間違えやすい文字をパスワードリセット画面から除外するプラグインです。

終わりに

セッションを聴きに来てくださった方々ありがとうございました。また実行委員長の又川さん他、実行委員、当日スタッフの皆様、本当にお疲れ様でした。そして、ありがとうございました。

昨年１１月から競技会採点システムを始めました。複数のタブレットで採点し、PC 側で集計するものです。その Web サービス部分の機能を、5個の公式プラグインとして公開しました。そのプラグインをどのように採点システムと関連させて使用しているかを一部コードを混ぜてお話しさせていただきます。

• メールアドレスのみの登録
  • 一般的ですが、Web サービスとして重要な機能を付加しています。User Mail Only Register
• １つのメールアドレスで複数アカウント登録
  • これがメインの内容となります。Add Multiple User
• 課金方法
  • PayPal, Stripe による課金方法。Simple PayPal Payment・Simple Stripe Payment
• 多国語、セキュリティ対策、パスワードリセット
  • その他のプラグインについてです。