せっかくなのでWordPressのECカートの「woocommerce」にチャレンジしてみる。っていうことにした。

まずは、のーがきから入ると、2011年にリリースされたそうな。
テンプレートテーマもそれなりにあり、プラグインも無料、有料含めてそれなりになるとな…（ウィキペディアより）

「woocommerce（ウーコーマース）」略して、「う○こちゃん」。。。すみませんでした<m(__)m>

 

それでは、プラグインのインストールから準備を始めたいと思いおます。

 

１．WooCommerceのインストール

 

・プラグインから新規追加で「WooCommerce」と検索して、「今すぐインストール」をクリックする。

 

・「有効化」

 

・初期の設定を行っていけるので指示に従います。「はい、お願いします。」をクリックする

 

・・・・チーン。500番エラーだとよ。幸先の悪いスタートとなりました…

 

ログをみると、imagickがunableだと。

PHP Warning:  PHP Startup: imagick: Unable to initialize module

 

あれ、有効なんだけどな

 

あー、WordPressのバージョンが5.2以上だったよ。手抜きしてたからバージョンが古かったよ。

PHPのバージョン7.0→7.2にしてみた。ちと、デフォルトバージョンがWordPressもPHPも古かったよ

 

 

気を取り直して続きのセットアップを…

 

・店舗の地域情報を入力

 

・販売するジャンルを選択

 

・で、次に販売する商品の種類

 

・販売する商品の数や場所など。

 

・次にテーマを決めるんだと。

 

でおちまい。あ、いきおいでjet packを入れてしまった…

 

ストアの設定

 

まずは、税金の設定をしておきます。

「税を設定する」→次へ進めていく。

 

自動って便利～～って思ってたら、、やっぱり、何も入っていない

 

っていうことで手動で税（10%）を設定

CSVにすると↓の感じ。

国コード,都道府県コード,郵便番号,市区町村,率 %,税率名称,優先順位,複合,送料,税区分
JP,,,,10,消費税,1,0,0,

 

 

つぎに送料を設定しておきます。

「設定」＞「送料」から設定ね。

 

通貨オプションを設定します。最初はドルになっているので円に変更

 

 

この後は手動で１つ商品を追加してみます。

 

で、販売サイト上を見ると,..

 

 

こんな感じでできあがりました。

 

 

決済を設定する

 

stripe押しのようですのでstripeを作ってみます。（まずはテスト用で）

 

・アカウントの登録

https://dashboard.stripe.com/register

 

「開発者」＞「APIキー」をクリックします。

公開可能キーとシークレットキーをメモします。

 

 

「設定」＞「決済」＞Stripe（クレジットカード）の右側のボタン（セットアップもしくは管理）をクリックします。

 

Webhookは、Stripe側でキャンセル、返金などを行った情報が、WooCommerceに反映されるとのことなので登録します。

 

 

 

 

・連携した後、テスト注文してみたところ簡単に連携できました。

ひさびさにWordPressでカミングスーンを利用します！

ではさっそくプラグインをどーしようかと…

 

WordPressのプラグインインストール画面で探してみるとカミングスーンいっぱいありますね…

 

今回は、一番最初に表示されたプラグインの「Coming Soon Page, Under Construction & Maintenance Mode by SeedProd」を使ってみたいと思います。

 

それでは、「Coming Soon Page, Under Construction & Maintenance Mode by SeedProd」の横の「今すぐインストール」ボタンをクリックし、有効化します。

 

 

インストールが完了すると設定画面が表示されます。

 

「General」欄で「Enable Coming Soon Mode」を選択する

 

「Page Settings」でロゴや「Headline」や「Message」を入力すればOK.

 

 

あとは、シークレットウィンドウなどで確認すれば

こんな感じで表示されます。

 

 

WordPressは、非常に便利なツールですが、悪意を持った攻撃も非常に多いので、今更ながらですがもう一度セキュリティ対策を見直したいと思います。

 

また、セキュリティ対策は１つで完了というわけではなく、１つ目、2つ目の多段にかけないと今の時代の攻撃は防ぎぎれないのが実情です。

 

 

サーバー側の対策

・WAFの有効化

→それぞれのレンタルサーバー会社が提供しています。

エックスサーバー

https://www.xserver.ne.jp/manual/man_server_waf.php

 

さくらインターネット

https://www.sakura.ne.jp/function/waf/

 

ロリポップ

https://lolipop.jp/manual/user/waf-set/

 

などの参照。WAFはいくつかの機能がありますが、プラグインによってはすべてを有効化できない場合がありますので利用環境に合わせて確認が必要です。

 

個人的には、SiteGuardを利用しているところが細かく調整が可能なので便利です。

 

・そのほかのセキュリティ

ざっくりとくくっていますが、サーバー会社によって用意されている内容がことなるのでそちらを参照してください。

 

例えばエックスサーバーの場合は、

・ダッシュボードアクセス制限

・XML-RPC APIアクセス制限

・REST API アクセス制限

・ログイン試行回数制限設定

https://www.xserver.ne.jp/manual/man_server_wpsecurity.php

があります。

 

ログイン試行回数制限設定は、利用者からログインできないってクレームが多いので有効化は悩みどころです。

 

WordPress側の対策

※DB接頭詞、wp-configの件は触れません。

・わかりやすいユーザー名を作らない。

例：admin、administrator,1234567..

・簡単なパスワードにしない

例：password,test,sample…

 

・不要なプラグイン、テーマは削除する

・XML-RPCを無効化する

スマートフォンやアプリから記事更新をしない場合には無効化をしましょう。

サーバー側でできる場合はサーバー側でブロックがベストです。

 

・REST APIを無効化する

 

・Akismetでスパムコメント対策を行う

コメントを受け付けてなければ導入しなくてもよいような。いちちwordpress.comアカウントが必要なので面倒です。

 

対策方法としては

 

サーバー側対策　≫　WordPress側対策

上記の感じでで設定したほうがWordPress自体に負荷をかけることが少なくなるので、他の閲覧者に影響が少ないです。

 

WordPressのログをみていると「XML-RPC」でログインアタックしてくるのが多いです。

目に見えているログインフォームのセキュリティ強化もありますが、システム的な攻撃をブロックにも注意しましょう！！

現在は、海外からの攻撃が多いので、特に問題がなければ国内限定にするもの一つの手です。

 

WordPressでAdvanced Custom Fields（ACF）を利用するケースはあるかと思いますが今回は、ACFの値を投稿以外のページで値として利用したと思って調べてみました。

 

POST_TYPE

acf-fieldがフィールド

acf-field-groupがフィールドをまとめたグループ

 

post_name

acf-field⇒「field_」

acf-field-group⇒「group_」

という名称で保存されます。

これがKEYになります。

 

post_excerpt

ここに格納されているのがカスタムフィールドとして設定したフィールド名が入っています。

 

通常投稿から利用する場合

get_filed(‘フィールド名’)やget_field_object(‘フィールド名’)で値を取得することが可能

※これにはPOST_IDが必要。

 

 

投稿以外のページからACFのフィールドの情報を取得するには？

Key名って？いうとACFはフィールドを増やす毎にユーザーが指定したフィールド名以外にキーとなる名称を付けています。

ということで、「get_field_object(‘Key名’)」で取得できるようです。

 

じゃあ、フィールド名⇒KEYに変換できるのか？というとfunctionを作ればできる？

※post_excerpt⇒post_nameを取得する

「$wpdb->get_results」を利用してクエリを書いてみた。

function getCustomfieldToFieldKey($column)
{
    if(empty($column))
        return false;

    global $wpdb;
    $query = "
    SELECT post_excerpt, post_name
    FROM $wpdb->posts AS p
    WHERE p.post_type = 'acf-field'
    AND p.post_status = 'publish'
    AND p.post_excerpt = '{$column}'
  ";

    $results = $wpdb->get_results( $query );

    if(!empty($results[0]->post_name))
    {
        return $results[0]->post_name;
    }
    return false;

}

 

これでpost_name（KEY）が取り出せる。

もちろん重複している場合はNGなのでカスタムフィールドを設計する際には気を付けないといけない。

 

あとは「get_field_object」にKEYを入れて内容を取り出す。

 

チェックボックスは検索向きじゃないのでタクソノミーで代用

 

 

リピートフィールドをプログラムでデータを追記する

あんまり使うこと無いかもしれないけど、リピートフィールドをPHPプログラムでデータを追記する場合

ACFのドキュメントに記述された方法だと失敗したのでメモとして残しておく。

・参考記事
https://www.kevinleary.net/update-an-acf-repeater-field-programmatically/

$existing = get_field( '１．リピートフィールド名' ,$post_id);
if ( ! is_array($existing) ) $existing = [];

$additions = [
    [
        '１．リピートフィールド名のリピートで設定しているフィールド名A' => '追加の値',
        '１．リピートフィールド名のリピートで設定しているフィールド名B' => '追加の値',
        '１．リピートフィールド名のリピートで設定しているフィールド名C' => '追加の値',
    ],
    [
        '１．リピートフィールド名のリピートで設定しているフィールド名A' => '追加の値',
        '１．リピートフィールド名のリピートで設定しているフィールド名B' => '追加の値',
        '１．リピートフィールド名のリピートで設定しているフィールド名C' => '追加の値',
    ],
    [
        '１．リピートフィールド名のリピートで設定しているフィールド名A' => '追加の値',
        '１．リピートフィールド名のリピートで設定しているフィールド名B' => '追加の値',
        '１．リピートフィールド名のリピートで設定しているフィールド名C' => '追加の値',
    ],

];

$updated = array_merge ($existing , $additions);//過去のデータと新しいデータを結合
update_field( '１．リピートフィールド名', $updated,$post_id );//そんでもって更新

 

 

 

 

これでなんとか。

WordPressの検索機能をカスタマイズしてみました。

検索プラグインがいくつかあるのですが、「fe-advanced-search」は、アドバンスカスタムフィールドプラグインに対応しておらず、なんだかんだといって、自作することにしました。

 

WordPressカスタムフィールドを検索させるのにちょっとハマったりしましたので基本的なところからメモを残していきたいと思います。

 

カスタムフィールドを検索できるようにするための下準備

まずは、wp_postsだけがSQLの対象となっているのでJOINでpostmetaを結合する関数を追加します。

function posts_join_custom_fields( $join, $query ) {
    if ( $query->is_search() && $query->is_main_query() && ! is_admin() ) {
        global $wpdb;
        $join ="INNER JOIN $wpdb->postmeta ON ($wpdb->posts.ID = $wpdb->postmeta.post_id)";
    }
    return $join;
}
add_filter( 'posts_join', 'posts_join_custom_fields', 10, 2 );

※管理画面以外、接続するようにしています。INNERで結合しているのでpostmetaに値があることが前提です。利用するカスタム投稿等によっては、上記の記述だと問題があると思いますので、どの画面で対象にするのか条件分を記述したほうが良いです。

 

 

次にカスタムフィールド（テキスト）を検索対象にしてみます。

「$search」の最初に「AND」でWHEREの追加をします。

その後、「meta_key＝カスタムフィールド」、「meta_value=検索値」で絞り込んでいます。

function custom_search($orig_search, $query) {
    if ( $query->is_search() && $query->is_main_query() && ! is_admin() ) {
        global $wpdb;

        $search =' AND ';
        $search .="($wpdb->postmeta.meta_value  LIKE '%日本橋%' and $wpdb->postmeta.meta_key = 'カスタムフィールド名')";
        return $search;
    }
    return $orig_search;
}
add_filter('posts_search','custom_search', 10, 2);

 

このあたりを基本系としてあとは、発展していった内容を記述していけばよいかと思います。

 

 

 

 

WordPressの翻訳を修正するときにある程度の知識があると便利なのでまとめてみました。

 

まずは、どんな翻訳システムをWordPressでは利用しているのか？

 

WordPressのユーザーインターフェース翻訳はGUNのgettext翻訳システムを採用している。

このGUNのgettext翻訳システムは複数タイプのファイル（POT、PO、MO）がある。languageファイルを覗くと「PO」「MO」のファイルが入っているかと思います。

 

POT

テキストファイル。基本言語（英語）の文言が入っているが翻訳は空白。

 

PO

テキストファイル。１つの言語に１つのPOファイルが作成される。

 

MO

バイナリファイル。POファイルからコンパイルして生成されたファイル

 

これらのファイルを操作するにはPoeditが必要。

 

作成手順

PoeditでPOTを元に新しいカタログを作成します。

カタログの設定でjaに設定します。

 

あとは、翻訳を作り、保存し、「wp-content/languages/plugins/」にアップロードすれば反映されます。

 

作成するあたって保存するファイル名は重要です。

例えば「<?php _e( ‘ソーステキスト’, ‘ドメイン’ ); ?>」とプログラム本体に記述されています。

この場合にファイル名は「ドメイン-ja」にしないと作成した翻訳ファイルを認識して翻訳してもらえません。

もし、翻訳が適用されないと思ったときにはチェックしてみるとよいかと思います。

 

ホームページ作成しているときに翻訳調整することがあると思いますので知っていると便利です。

WordPressのユーザー情報を変更したときに自動的にメール送信されるのを止めたい！

そんなときは、FUNCTION.PHPに「Filter」を掛けると対応できる。

// 「ユーザー登録時」に「管理メールアドレス宛」のメール送信停止する
add_filter( 'wp_new_user_notification_email_admin', '__return_false' );

// 「ユーザー登録時」に「登録ユーザー宛」にメール送信停止する
add_filter( 'wp_new_user_notification_email', '__return_false' );

// 「メールアドレス変更時」にメール送信停止する
add_filter( 'send_email_change_email', '__return_false' );

// 「パスワード変更時」のメール送信停止する
add_filter( 'send_password_change_email', '__return_false' );

// 「パスワードリセット時」のメール送信停止する
add_filter( 'wp_password_change_notification_email', '__return_false' );

 

とりあえず、function.phpにfilterを記述して動作するか確認しましょう。

WordPressでがりごりがごり、コーディングしてできた～～！っていったら速度がおそ～い。っていうときにちょっと調べた内容をメモ程度に残しておきます。

 

速度測定サイトでもブラウザでも何でもよいのですが検証「F12」を押したときに出てくる「DevTools」の「ネットワーク」を利用します。

 

下記のような読み込み速度が見れるかと思います。スタイル、画像、スクリプトが遅いのかはこれでさくっとわかるかと思います。

 

下記のだと「/」の反応がすでに遅いです。

 

WordPressを分解してみたところ、「index.php」「single.php」「page.php」に入る前の状態が一番上の行に表示されています。

 

このあたりでは何をしているのかというとプラグイン系を読み込んでいると考えてよいです。

 

っていうことで遅そうなプラグインを停止したところ、「3.54s」→「1.77s」まで改善されました。

 

最終的には停止したプラグインのアップデートしたところ、速度の原因をプラグインの開発者の方で修正したみたいです。

 

気を付けるプラグイン

・Acunetix WP Security

設定で「Enable Live Traffic tool.」とすると遅い。そりゃそうだ。

・プラグインのバージョン

まれにプラグインのバージョンで遅いものがある。チェックしてから本番に反映しよう。