まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:wordpress

自分を含め、多くの人に使われているコンテンツ管理システムである WordPress の(プラグインの)日本語翻訳に参加させていただきました。

WordPress は本体だけでなく各種プラグインも含めてオンラインで翻訳に参加する仕組みが整っており、誰でも比較的容易に参加できると感じました。以下で実際の翻訳を行った様子を紹介しますが、ぜひ色んな人に参加していただきたいと思っています。

(1)準備
WordPress の翻訳に参加するために必要なものは WordPress.org アカウントです。こちらからログインして翻訳を開始します。まだアカウントを所有していない場合は新規に作成してからログインして進めてください:
https://login.wordpress.org/

2019081601


(2)翻訳する対象言語と対象プロジェクトの選択
上記アカウントで WordPress.org にログイン後、以下の翻訳サイトへ移動します:
https://translate.wordpress.org/

2019081602
(↑正しくログインしていると、右上に自分のプロフィールが表示されます)


まずは翻訳対象言語を選びます(今回は「日本語」として以下を紹介しますが、他の言語に翻訳する場合はその言語を選んでください)。画面を下の方にスクロールして "Japanese" の "Contribute Translation" ボタンをクリックします:
2019081603


次に選択した言語(日本語)で、何の翻訳に参加するか、を選びます。最初は WordPress 本体の翻訳参加用ページが WordPress のバージョン別に表示されています。が、実際に見ていただくとわかるのですが、WordPress 本体の翻訳は Progress がほぼ 100% となっていて「既に翻訳済み」となっていると思います。なのでこちらへの参加はできません:
2019081604


翻訳は WordPress 本体だけではなく、各種テーマやプラグインに対しても行うことができます。例えば "Plugins" を選択すると選択言語(日本語)で翻訳に参加できるプラグインの一覧が表示されます。こちらは Progress = 100% になっていないプラグインがほとんどで、これらのプラグインの翻訳に参加することができます:
2019081605


適当に1つ選んでもよいのですが、せっかくなので普段自分が使ってお世話になっているものから選びたいと思いました。

というわけで、個人的に最近使い始めた "All in One SEO Pack" プラグインの日本語化に貢献させていただこうと思います。検索バーに "All in One SEO" などと入力して検索し、対象のプラグインを見つけたら "Translate Project" ボタンをクリックします(Progress = 91% なので、まだ未翻訳部分が全体の1割弱残っていることになります):
2019081606


選択したプラグインの翻訳プロジェクト一覧が表示されます。このプラグインでは Development(開発)版と Stable(安定)版の2つのプロジェクトに分かれて開発が進められており、かつそれぞれに本体と README の翻訳が用意されているようです。ここから自分が対象とするサブプロジェクトを選ぶのですが、今回は Untranslated (未翻訳箇所)が 69 個と最も多い Stable 版を選ぶことにしました:
2019081607



(3)翻訳作業
翻訳する対象のプロジェクトを選ぶと、そのプロジェクトの文字リソース一覧が表示されます:
2019081601


最初は翻訳済みのものも全て含めた文字リソース一覧が表示されています。未翻訳のものだけが表示されるよう、"Untranslated" をクリックして、未翻訳文字リソース一覧に切り替えます:
2019081602


ここに表示されているものが「All in One SEO Pack プラグインの中でまだ日本語になっていない文字」の一覧です。翻訳に参加するにはどれか1つを選んで "Double click to add" と書かれている部分をダブルクリックします:
2019081603


すると翻訳編集画面に切り替わります。この例では「Search results for "%s"」という文字リソースの日本語翻訳を(まだ存在していないので)指定します:
2019081604


この日本語訳として「"%s" の検索結果」と入力しました。確定する場合は "Suggest" ボタンをクリックします:
2019081605


すると画面内に先程選んだ「Search results for "%s"」の訳として「"%s" の検索結果」が入力されている状態になります。これで選択した文字リソースの翻訳候補を指定できました。簡単ですね。

同時に次の未翻訳リソースである「F j, Y」が選択され、翻訳の入力を待っている状態に切り替わりました:
2019081606


同様にして翻訳を入力して "Suggest" を繰り返していきます。ある程度翻訳した所で、画面内上部の "Japanese" を選択します:
2019081607


すると画面が切り替わり、"Waiting" の数字が変わっているはずです(もとは 0 だったのが 9 になってます)。これは自分が入力した翻訳候補が9つあり、それらが採用される前の段階として waiting(待ち)の状態になっている、ということを示しています(この画面で黄色の背景になっているものが waiting のリソースです):
2019081608


翻訳の作業はこれだけです。後は対象プロジェクトの管理者さんがこの状態から実際のプロジェクトに翻訳を入れるかどうかを判断して、採用された場合は実プロジェクトに反映される、という手続きが待っています。

実際の翻訳には単なる言語知識だけでなく、PHP の文法や日付フォーマットなどの知識が必要になることもありますが、まあわからないものは飛ばして分かるものだけ翻訳に貢献するのがいいと思います。自分の場合はお世話になっているプラグインへのお礼と、あと今後自分が使う中で自分が翻訳した文字列を目にすることがあれば、それはそれで嬉しいと思ったのでボランティアで参加させていただきました。いつかどなたかの役に立つことを願って。



不定期(要するに「ふと思い立ったタイミング」)で LinuxONE の紹介をしています。LinuxONE はメインフレームのハードウェア上で動く Linux です。そういえば LinuxONE で docker って使えるんだろうか?使えるとしたらどのあたりまで使える?? ということを確認したくなって、久しぶりに LinuxONE コミュニティクラウドの環境構築をしてみました。なお、以下の内容は 2019/05/27 時点の状況を紹介したものです。
2019052700


LinuxONE コミュニティクラウドは最大 120 日間無料で利用可能な LinuxONE の環境です。パブリックな IP アドレスが割り振られるので、インターネットから利用することもできます。FAQ も参照ください:
https://developer.ibm.com/linuxone/resources/faq/


LinuxONE コミュニティクラウドの申し込み方法は以前(2017年)のブログエントリで紹介したものとほとんど変わっていません。こちらを参照してください:
http://dotnsf.blog.jp/archives/1063515821.html

ここで記載されている情報と異なる点として、2019/05/27 現在では OS として RHEL 6.x を選択することはできなくなっています。そのため今回は RHEL 7.x を選択しました(RHEL 7.6 が導入されました)。またサーバーのスペック選択肢が廃止され、常に 2CPU + 4GB メモリ + 50 GB ディスク の環境が提供されるようになっていました。

仮想サーバーができたら IP アドレスとサーバー作成時に作ってダウンロードした鍵ファイル(*.pem)を指定して linux1 ユーザーでログインします:
2019052701


ログインできました。実際に試していただくとわかるのですが「ほぼ x86_64 版の RHEL 7.6」です。明示的にアーキテクチャを確認しないと s390x 版であることに気づかないかもしれません。

そしてこの後の docker 環境構築の手順に備えて root ユーザーに切り替えます:
$ sudo -i
#


さて、docker および docker-compose をこの LinuxONE 環境に導入していきます。手順そのものはこちらで紹介されているものをほぼそのまま使うのですが、2019/05/27 現在の環境では記載そのままの手順では途中でエラーになってしまい、導入できませんでした。エラー回避のため、少し異なる手順で導入します(異なる部分をで記載しています)。
https://github.com/IBM/Cloud-Native-Workloads-on-LinuxONE/blob/master/README-ja.md


【docker の導入】
まずインストールする docker の s390x 向けパッケージファイルをダウンロードします。RHEL 7.3 以上向けに docker 17.05 の CE(Community Edition)版が用意されているのでダウンロードします:
# wget ftp://ftp.unicamp.br/pub/linuxpatch/s390x/redhat/rhel7.3/docker-17.05.0-ce-rhel7.3-20170523.tar.gz

ダウンロードしたアーカイブファイルを展開し、バイナリを /usr/local/bin/ 以下にコピーします:
# tar -xzvf docker-17.05.0-ce-rhel7.3-20170523.tar.gz
# cp docker-17.05.0-ce-rhel7.3-20170523/docker* /usr/local/bin/

2019/05/27 時点では標準状態では /usr/local/bin にパスが通っていませんでした。このままだと docker コマンドがそのまま使えないので、パスを通しておきます:
# export PATH=$PATH:/usr/local/bin

これで docker コマンドが使えるようになったので、docker デーモンを起動します:
# docker daemon -g /local/docker/lib &


【docker-compose の導入】
続いて docker-compose もインストールします。実はこちらがドキュメント通りにいかない部分が多く、少し厄介でした。

手順としては pip を使って docker-compose をインストールします。そのため pip を先にインストールするのですが、pip をインストールするための依存ライブラリを先に導入します:
# yum install -y python-setuptools

そして pip をインストールします:
# easy_install pip

インストールした pip を使って、まず backports.ssl_match_hostname をアップグレードするのですが、このコマンドをドキュメント通りに入力すると既に導入済みの環境とのコンフリクトが起こってエラーになってしまいました。というわけで --ignore-installed オプションを付けて実行します:
# pip install backports.ssl_match_hostname --upgrade --ignore-installed

そして pip で docker-compose をインストール・・・するのですが、ここでもドキュメントのまま実行すると依存関係ライブラリが足りないというエラーになってしまいます。そのためまずは依存ライブラリを導入しておきます:
# yum install python-devel
# yum install gcc libffi-devel openssl-devel
# pip install glob2

改めて pip で docker-compose をインストールします。ここでもドキュメントそのままの指定だとエラーになってしまうので、バージョン 1.13.0 を明示してインストールします:
# pip install docker-compose==1.13.0

これで docker および docker-compose が LinuxONE 環境にインストールできました:
# docker -v
Docker version 17.05.0-ce, build 89658be

# docker-compose -v
docker-compose version 1.13.0, build 1719ceb

2019052702


【WordPress の導入】
では導入した docker と docker-compose を使ってコンテンツ管理システムである WordPress を導入してみます。

テキストエディタ(vi とか)を使うなどして、docker-compose.yml というファイルを以下の内容で作成して保存します:
version: '2'

services:

  wordpress:
    image: s390x/wordpress
    ports:
      - 80:80
    environment:
      WORDPRESS_DB_PASSWORD: example

  mysql:
    image: brunswickheads/mariadb-5.5-s390x
    environment:
      MYSQL_ROOT_PASSWORD: example

このファイルは docker-compose 向けの定義ファイルで wordpress と mysql という2つのコンテナ環境を定義しています。wordpress は PHP, Apache HTTPD, および WordPress が含まれる s390x 向けのイメージで 80 番ポートで HTTP リクエストを待ち受けます。また mysql は MySQL(正確には mariaDB)が含まれる s390x 向けイメージです。これら2つのイメージから2コンテナ環境を作り出して WordPress として挙動するようにしています。

では、docker-compose と、この docker-compose.yml ファイルを使って docker コンテナを起動します:
# docker-compose up -d

(必要に応じて)イメージをダウンロードし、イメージからコンテナが作られて起動します。プロンプトが戻ってきたら、docker ps コマンドを実行して wordpress と mariadb の2つのコンテナが起動していることを確認します:
# docker ps
CONTAINER ID        IMAGE                              COMMAND                  CREATED             STATUS              PORTS                NAMES
65af9dfa6ee9        s390x/wordpress                    "docker-entrypoint..."   3 hours ago         Up 3 hours          0.0.0.0:80->80/tcp   dockers_wordpress_1
3eb78f3ef1c1        brunswickheads/mariadb-5.5-s390x   "/docker-entrypoin..."   3 hours ago         Up 3 hours          3306/tcp             dockers_mysql_1

起動が確認できたらウェブブラウザから(LinuxONE 環境の) IP アドレスを指定してアクセスします(http://xxx.xxx.xxx.xxx/)。以下のような WordPress の環境設定画面になれば成功です:
2019052801


言語やユーザーID、パスワードなどの設定が完了すると管理画面にログインできるようになりました:
2019052802


この時点でユーザーページにもアクセス可能です:
2019052803


とりあえずメインフレーム上の Linux に docker & docker-compose 環境を構築して WordPress を導入することができました!


2018/09/15 に開催された WordCamp Tokyo 2018 にスピーカーとして参加してきました:
WordPress meets IBM Watson ! 〜WordPress のコンテンツデータを IBM Watson に機械学習させてみよう〜

kimura-kei


セッションの中で話せたことだけでなく、その背景にあった部分も含めてブログにまとめました。


【WordPress 歴】
まず私自身の WordPress 歴を話しておきます。利用者という意味では結構早い段階から使っていたつもりでしたが、(WordPress をカスタマイズして使ってサービスを作る、という)開発者としては 2013 年からだと思います。この年に転職を経験しており、その転職先では WordPress を使ったサービス開発案件を何度も経験しました。業務で本格的に PHP を使うようになったのもこの頃からです。自分自身の印象として、WordPress は「サービスを高速開発するフレームワークの1つ」だと思っています。実際、テンプレートやプラグインの充実度が半端なく、ちょっとググればやりたいことを実現するプラグインが見つかるので、完成形に近いサービスをすぐに作ることができて感動しました。同時に WordPress のシステム内部についても興味を持つようになりました。当時はまだ REST API が標準ではなかったため、自分で MySQL テーブルの構造を調べて、データを効率よくインポート/エクスポートするにはどうすればよいか、を調べたり、ツールを作ったりしていました。今回発表させていただいた内容でもこの頃の知識が役立ちました。


【2度目の応募】
WordCamp でスピーカーとして登壇させていただいたのは初めてでしたが、スピーカーとしての応募は初めてではありません。WordCamp の存在を知ったのは 2013 年頃だったと思います。記憶が正しければこの頃(おそらく 2014 年)に一度スピーカーとして応募しています。少しビジネス寄りの利用を想定した内容だったのですが、この時は残念ながら登壇することはありませんでした。そしてこの時から「いつかはこの舞台でスピーチしたいなあ」という目標のようなものができたのでした。

そして今年、今回もどちらかというとビジネス寄りの内容だったと思いますが、よく言えば「流行りに乗っかる」形で人工知能と絡めたセッションのスピーチで応募し、念願だった登壇者に選んでいただきました。


【直前のトラブル】
今回のセッションは 15 分間の中で説明とライブデモを見せる、というものでした。このライブデモで実際に動いている所をお見せすることで理解をより具体的に深めていただく、という目的がありました。

ところがこのデモ環境にトラブルがありました。ちゃんと動く環境を(仮想環境で)用意して、そのイメージのバックアップもとって、何かあってもバックアップからリストアすれば大丈夫、と思っていました。ところがこの環境で使って、セッションが expire するまでは普通に使えるのですが、expire 後に何故かログインできなくなる、という問題が発生してしまいました。要は肝心のデモ環境に管理者権限でログインできなくなってしまう、という症状が出てしまったのでした。プラグインを紹介するデモなので、管理者コンソールに入れないのは致命傷でした。

判明したのがデモ直前だったこともあり、原因は未だによくわかっていないのですが、このトラブルに結構振り回されました。結論としては「セッションの直前にデモ環境をデモデータ含めて新規に構築する」という綱渡り的な対処で乗り切りました。冷や汗モノ・・・ (^^;


【セッションは無事に】
そんな綱渡りをしながらもセッションは無事に(3分オーバーでw)終えることができました。事前の練習では1分余らせて終える練習をしていたつもりが、本番になると調子に乗ってしまったのか、話す時間が多くなってしまったようです。

当日の資料の配布版はこちらで公開しています:


IBM Watson の NLC(Natural Language Classifier) というサービスを使って、WordPress の中に溜まったデータを Watson に学習させて、問い合わせすることに挑戦する、という内容を紹介させていただきました。全セッション中の最終セッションだったにもかかわらず多くの皆様に参加いただき、また終了後も多くの質問や感想をその場でいただくことができて、とても充実したセッションでした。この場をお借りしてお礼申し上げます。

セッション内でも触れましたが、機械学習の現場では「学習データ不足」が解決するべき課題となっています。WordPress のような広く使われている CMS のコンテンツデータを学習データとすることができればどんなに楽か・・・という思いもあってのセッションテーマおよびデモでした。同じような悩みを持っていたり、興味を持って参加いただけた皆さんの参考になれば嬉しいです。

また上述の通り、自分にとってはこの場でセッションすることがここ数年の目標の1つでした。とてもいい形で実現することができたと思っています。参加者の皆様、サポートスタッフの皆様、スポンサーの皆様、貴重な機会を本当にありがとうございました。

uXTscPOQ



データのマイグレーションなどで WordPress を使う場合、元データのユーザーデータごと移行するケースがあると思います。そんなユーザー情報を WordPress の機能で追加するのではなく、外部アプリケーションから直接データベースを操作して追加する方法を紹介します。

なお、今回紹介するケースでは WordPress 4.8.2 を使いました。また WordPress のテーブルプリフィクス値はデフォルトの 'wp_' であると仮定して以下を紹介します。異なる設定で利用している場合は適宜読み替えてください。加えて、今回紹介する PHP ファイルを MySQL サーバーとは異なるホストから実行する場合は、このファイル内で指定したユーザーが MySQL にリモートログインできるような設定があらかじめされている必要がある点をご注意ください。


まず WordPress を普通にセットアップすると、いくつかのテーブルが自動的に生成されます。その中でユーザー情報を管理するのは wp_users と wp_usermeta の2つです:


wp_users はその名の通り WordPress のユーザーテーブルとなっていて、1レコードが1ユーザーの情報を意味します。詳しくは後述しますが、単に「ユーザーを登録する」だけであればこのテーブルに1レコード追加するだけで事は足ります。

一方、wp_usermeta はユーザーの属性に関わる値を管理するテーブルです。例えばユーザーのニックネームや権限といった wp_users だけでは管理できない一部の情報や、システムが内部的に利用するセッション情報、最終アクション日時といった情報を wp_usermeta テーブルで管理します。以下では「管理画面にアクセスできる権限を持ったユーザーを追加する」例を紹介しますが、この場合は wp_usermeta も操作する必要があります。


まず wp_users テーブルの属性を desc コマンドで調べた結果がこちらです:
mysql> desc wp_users;
+---------------------+---------------------+------+-----+---------------------+----------------+
| Field               | Type                | Null | Key | Default             | Extra          |
+---------------------+---------------------+------+-----+---------------------+----------------+
| ID                  | bigint(20) unsigned | NO   | PRI | NULL                | auto_increment |
| user_login          | varchar(60)         | NO   | MUL |                     |                |
| user_pass           | varchar(255)        | NO   |     |                     |                |
| user_nicename       | varchar(50)         | NO   | MUL |                     |                |
| user_email          | varchar(100)        | NO   | MUL |                     |                |
| user_url            | varchar(100)        | NO   |     |                     |                |
| user_registered     | datetime            | NO   |     | 0000-00-00 00:00:00 |                |
| user_activation_key | varchar(255)        | NO   |     |                     |                |
| user_status         | int(11)             | NO   |     | 0                   |                |
| display_name        | varchar(250)        | NO   |     |                     |                |
+---------------------+---------------------+------+-----+---------------------+----------------+
10 rows in set (0.01 sec)

プライマリキーは ID(auto_increment)で、他のフィールドは全て Not Null 属性です。ただ user_registered と user_status にはデフォルト値が設定されています。ということはこれらを除いた user_login, user_pass, user_nicename, user_email, user_url, user_activation_key, display_name を指定すればレコードは作れそうです。

というわけで、とりあえずは以下のような関数(createWpUser)およびファイル(wp-user-import.php(改良前))を PHP で作ってみました:
<?php

$wp_db_name = 'wpdb';            //. WordPress DB
$wp_db_host = 'localhost';       //. WordPress ホスト名
$wp_db_username = 'adminuser';   //. WordPress DB の管理者ユーザー名
$wp_db_password = 'adminpass';   //. WordPress DB の管理者パスワード
$wp_table_prefix = 'wp_';        //. WordPress DB のテーブルプリフィクス


function createWpUser( $u_email, $u_password ){
  global $wp_db_name, $wp_db_host, $wp_db_username, $wp_db_password, $wp_table_prefix;

  $pdo = new PDO( 'mysql:dbname='.$wp_db_name.';host='.$wp_db_host.';charset=utf8', $wp_db_username, $wp_db_password );
  if( $pdo != null ){
     $pdo->query( 'SET NAMES utf8' );

     $sql1 = 'insert into ' . $wp_table_prefix . 'users(user_login,user_pass,user_nicename,user_email,user_url,user_activation_key,display_name) values( :user_login, MD5(:user_pass), :user_nicename, :user_email, "", "", :display_name )';
     $stmt1 = $pdo->prepare( $sql1 );
     $stmt1->bindParam( ':user_login', $u_email );
     $stmt1->bindParam( ':user_pass', $u_password );
     $stmt1->bindParam( ':user_nicename', $u_email );
     $stmt1->bindParam( ':user_email', $u_email );
     $stmt1->bindParam( ':display_name', $u_email );
     $r1 = $stmt1->execute();
  }
}

?>

createWpUser 関数のパラメータはメールアドレスとパスワードの2つだけです。メールアドレスは user_login, user_nicename, user_email, display_name に設定します。パスワードは MySQL の MD5 関数を使ってハッシュ化したものを指定します。また user_url および user_activation_key には '' を指定して insert を実行しています。

このファイルを使って、1ユーザーを作成するサンプルがこちらです(test1.php):
<?php

require_once './wp-user-import.php';

$r1 = createWpUser( 'user1@xxx.com', 'P@ssw0rd' );  //. ID: user1@xxx.com , パスワード: P@ssword のユーザーを新規作成する

?>

試しにこの test1.php を実行すると、WordPress に user1@xxx.com という ID のユーザーが登録されます:
$ php -f test1.php


管理者権限でログインして管理ページを開くと、たしかに指定したユーザーが追加されていることが確認できます(この画面で「権限グループ」が「なし」になっていることがわかります):
2017103001


この時点で作成したユーザーは有効なので、指定した ID とパスワードでログインすることはできます:
2017103002


ただ管理機能については権限を一切持っていないユーザーなので、無理やり URL を指定して管理ページにアクセスしてもエラー画面となります:
2017103003


とりあえずはここまで。wp_users に1レコード追加するだけで(管理や投稿の権限を持たない)ユーザーを作ることができることがわかりました。とりあえずこの状態になれば、後から管理者がこれらのユーザーの権限を(手動で)変える、ということも可能ではあります。


次に管理者や投稿者の権限を持ったユーザーを同様に外部から作成する方法を紹介します。先程と同様に wp_usermeta テーブルの属性を同様に調べた結果がこちらです:
mysql> desc wp_usermeta;
+------------+---------------------+------+-----+---------+----------------+
| Field      | Type                | Null | Key | Default | Extra          |
+------------+---------------------+------+-----+---------+----------------+
| umeta_id   | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| user_id    | bigint(20) unsigned | NO   | MUL | 0       |                |
| meta_key   | varchar(255)        | YES  | MUL | NULL    |                |
| meta_value | longtext            | YES  |     | NULL    |                |
+------------+---------------------+------+-----+---------+----------------+
4 rows in set (0.00 sec)

umeta_id がプライマリキー(auto_increment)で、user_id は wp_users.ID を示す外部キーです。そしてこの user_id で指定したユーザーに対して、meta_key と meta_value で属性を加えることができるようになっています。

ユーザーの権限に関わる設定をするには、meta_key の値が 'wp_user_level' 及び 'wp_capabilities' となる2つのレコードを追加して指定することになります。具体的には対象のユーザーの権限に応じて、以下のような値を設定します:
ユーザー権限wp_user_level の設定値wp_capabilities の設定値
購読者0a:1:{s:10:"subscriber";b:1;}
寄稿者1a:1:{s:11:"contributor";s:1:"1";}
投稿者2~4a:1:{s:6:"author";b:1;}
編集者5~7a:1:{s:6:"editor";b:1;}
管理者8~10a:1:{s:13:"administrator";b:1;}


というわけで wp-user-import.php を少し改良します。createWpUser 関数のパラメータを2つから3つに変更し、3つ目のパラメータで上記の wp_user_level を指定するものとします:
<?php

$wp_db_name = 'wpdb';            //. WordPress DB
$wp_db_host = 'localhost';       //. WordPress ホスト名
$wp_db_username = 'adminuser';   //. WordPress DB の管理者ユーザー名
$wp_db_password = 'adminpass';   //. WordPress DB の管理者パスワード
$wp_table_prefix = 'wp_';        //. WordPress DB のテーブルプリフィクス


function createWpUser( $u_email, $u_password, $wp_user_level = 0 ){
  global $wp_db_name, $wp_db_host, $wp_db_username, $wp_db_password, $wp_table_prefix;

  $pdo = new PDO( 'mysql:dbname='.$wp_db_name.';host='.$wp_db_host.';charset=utf8', $wp_db_username, $wp_db_password );
  if( $pdo != null ){
    $pdo->query( 'SET NAMES utf8' );

    $sql1 = 'insert into ' . $wp_table_prefix . 'users(user_login,user_pass,user_nicename,user_email,user_url,user_activation_key,display_name) values( :user_login, MD5(:user_pass), :user_nicename, :user_email, "", "", :display_name )';
    $stmt1 = $pdo->prepare( $sql1 );
    $stmt1->bindParam( ':user_login', $u_email );
    $stmt1->bindParam( ':user_pass', $u_password );
    $stmt1->bindParam( ':user_nicename', $u_email );
    $stmt1->bindParam( ':user_email', $u_email );
    $stmt1->bindParam( ':display_name', $u_email );
    $r1 = $stmt1->execute();

    $user_id = null;
    $sql2 = 'select last_insert_id() as user_id from ' . $wp_table_prefix . 'users';
    $stmt2 = $pdo->query( $sql2 );
    if( $row = $stmt2->fetch( PDO::FETCH_ASSOC ) ){
      $user_id = $row['user_id'];
    }

    if( $user_id ){
      //. wp_user_level
      $sql3 = 'insert into ' . $wp_table_prefix . 'usermeta(user_id,meta_key,meta_value) values( :user_id, "wp_user_level", :wp_user_level )';
      $stmt3 = $pdo->prepare( $sql3 );
      $stmt3->bindParam( ':user_id', $user_id );
      $stmt3->bindParam( ':wp_user_level', $wp_user_level );
      $r3 = $stmt3->execute();

      //. wp_capabilities
      $wp_capabilities = null;
      if( $wp_user_level == 0 ){
        $wp_capabilities = 'a:1:{s:10:"subscriber";b:1;}';
      }else if( $wp_user_level == 1 ){
        $wp_capabilities = 'a:1:{s:11:"contributor";s:1:"1";}';
      }else if( 2 <= $wp_user_level && $wp_user_level <= 4 ){
        $wp_capabilities = 'a:1:{s:6:"author";b:1;}';
      }else if( 5 <= $wp_user_level && $wp_user_level <= 7 ){
        $wp_capabilities = 'a:1:{s:6:"editor";b:1;}';
      }else if( 8 <= $wp_user_level && $wp_user_level <= 10 ){
        $wp_capabilities = 'a:1:{s:13:"administrator";b:1;}';
      }
      if( $wp_capabilities != null ){
        $sql4 = 'insert into ' . $wp_table_prefix . 'usermeta(user_id,meta_key,meta_value) values( :user_id, "wp_capabilities", :wp_capabilities )';
        $stmt4 = $pdo->prepare( $sql4 );
        $stmt4->bindParam( ':user_id', $user_id );
        $stmt4->bindParam( ':wp_capabilities', $wp_capabilities );
        $r4 = $stmt4->execute();
      }
    }
  }
}
?>

createWpUser の3つ目のパラメータ(無指定時は 0)の値を上記の wp_user_level と見なして、wp_usermeta テーブルにユーザー権限に合わせた値を作成するように変更しました。また wp_usermeta テーブルにレコードを作成する際に wp_users.ID の値が必要になるので、MySQL の last_insert_id() 関数を使って作成したユーザーの ID を取得しています。

そして、例えば管理者権限を持ったユーザーを作成したい場合は以下(test2.php)のようなコードを用意します:
<?php

require_once './wp-user-import.php';

$r2 = createWpUser( 'user2@xxx.com', 'P@ssw0rd', 10 );  //. ID: user2@xxx.com , パスワード: P@ssword のユーザーを管理者権限で新規作成する

?>

試しにこの test2.php を実行すると、WordPress に user2@xxx.com という ID の管理者ユーザーが登録されます:
$ php -f test2.php

2017103004


このユーザーの ID とパスワードでログインすると、管理者ダッシュボードにアクセスして、管理者権限でのオペレーションが可能です:
2017103005



というわけで、PHP から WordPress の MySQL データベースを直接操作してユーザーを登録することができました!


(参考) WordPress Codex 日本語版:ユーザーの種類と権限

ワードプレスのインポートプラグインを使わず、データベース内のテーブル(wp_posts とか、wp_terms とか、・・)に直接 SQL を実行して、記事をインポートする方法を紹介します。単なる記事だと(簡単すぎて)つまらないので、カテゴリ付きの記事の、そのタイトルと本文をインポートすることに挑戦しました。 なお、ワードプレスのデータベーステーブルプリフィックスは設定によって変更可能ですが、以下はデフォルトである 'wp_' に設定されているものとして紹介します。


【記事のインポート】
単純な記事のインポートだけであれば wp_posts テーブルに post_status = 'publish', post_type = 'post' でデータを挿入するだけです(必要に応じて post_date や post_author なども):
insert into wp_posts( post_content, post_title, post_status, post_type ) values( '(本文)', '(タイトル)', 'publish', 'post' );

単純に記事を公開状態でインポートするだけなら、必要な記事のぶん上記コマンドを繰り返して実行するだけです。以下はカテゴリ情報を有効にする場合の追加作業です。


この SQL を実行した結果、auto_increment なプライマリキーである ID 値が確定します。この ID 値は記事のカテゴリーを指定する際に必要になるので取得しておきます。
select last_insert_id() as ID from wp_posts;


【カテゴリーのインポート】
記事にカテゴリを付与する手順は少し複雑です。

まずカテゴリの名称(と slug)を wp_terms テーブルに挿入します:
insert into wp_terms( name, slug ) values( '(カテゴリー名)', '(カテゴリー名を urlencode したもの)' );

この SQL を実行した結果、auto_increment なプライマリキーである term_id 値が確定するので、この値を取得します:
select last_insert_id() as term_id from wp_terms;

この term_id が所得できたら、次は wp_term_taxonomy テーブルにこの term_id と、term_id が示すカテゴリの記事が何件あるのかという情報を taxonomy 情報(='category')と一緒に wp_term_taxonomy テーブルに挿入します:
insert into wp_term_taxonomy( term_id, taxonomy, count ) values( (term_id の値), 'category', (このカテゴリに属する記事数) );

この SQL を実行した結果、auto_increment なプライマリキーである term_taxonomy_id 値が確定するので、この値を取得します:
select last_insert_id() as term_taxonomy_id from wp_term_taxonomy;

term_taxonomy_id が取得できたら、最初に取得した記事の ID 値と、カテゴリを示す term_taxonomy_id 値との組み合わせを wp_term_relationships テーブルに挿入します:
insert into wp_term_relationships( object_id, term_taxonomy_id ) values( (ID の値), (term_taxonomy_id の値) );

ちとややこしいですが、ここまでの作業でカテゴリに紐付いた記事のインポートが実現できます。ワードプレスDBのテーブルスキーマとの関連だとこんな感じになります:
2017072000


まとまったデータコンテンツをワードプレスに移行する、という場合は上記の作業を必要なだけ繰り返し自動的に行うようなツールを(プログラミングで)作ることになります。本文&タイトル&カテゴリ程度が決まっている単純構成であれば、(それらのデータを取り出す部分さえ作れれば)自動化もそんなに難しくないと思ってます。


このページのトップヘ