ダリの雑記：WEBプログラム版

下記のエラーが出て、ファイルのアップロードに失敗した原因がしょうもなかったので、記録しておく。

サーバーの負荷が高いか十分なリソースがないため画像の後処理に失敗しました。もっと小さな画像をアップロードしてみてください。推奨する最大サイズは2500ピクセルです。

サーバーから予期しないレスポンスがありました。ファイルは正しくアップロードされているかもしれません。メディアライブラリもしくはページをリロードして確認してください。

これが特に何もしてないのに、なぜか上のエラーだったり下のエラーに代わったりで、わけわからなかった。

エラーメッセージでググってみるとブラウザを変えたり、Wordpressにログインし直したりしたら直るという記事をよく見たのですが、それではいっこうに治らない。

WordPressをインストールしてプレーンな状態で試してみたら、さすがにうまくいったので、ApacheやPHPの設定のせいではなさそう。

で、いろいろと試しまくった結果、原因がこういうことであることが分かった。

今回のWordpressでは「wp-content」フォルダを「contents」というフォルダ名に変えていたのですが、こうすると、wp-config.phpで下記の設定を行わないといけない。

define('WP_CONTENT_DIR', ABSPATH . 'contents');
define('WP_CONTENT_URL', '（WPのURL）/contents');

結論を言うと、この（WPのURL）がhttpsではなくhttpで設定されていた。（「WordPress アドレス (URL)」の設定は、httpsで設定されていたのに、「contents」フォルダへのフルパス設定がhttpだった）

さらに、これだけなら実は問題にならないのだが、ベーシック認証をサイト全体にかけていた。

管理画面に入る際に、httpsの方はベーシック認証は解除されるわけだが、httpの方は解除されていないため、アップロード時のプログラムが、httpの方でつなぎに行って弾かれてしまい、エラーになったものと思われる。

原因特定まで時間かかった・・・が、やはり１からやり直してみるというのは有効だ。

Contact form 7をインストールする際は、言語ファイルを忘れずに入れる必要があります。

言語ファイルのダウンロードはこちら

Translating WordPress

このページにある「Japanese」のzipファイルをダウンロードして解凍、pluginsフォルダにアップロードした「contact-form-7」フォルダの中にある「languages」フォルダに、解凍した「contact-form-7-ja.mo」「contact-form-7-ja.po」ファイルを入れます。

これで、プラグインを有効化すれば、Contact from 7が日本語モードで使えるはず・・・・なんですが、メニューも中身も英語のまま。

いろいろ調べてみたのですが、サイトの言語は日本語だし、言語ファイルも入ってるし、プログラムを無理やり書き換えれば日本語になりますが、あんまりやりたくはない・・・

で、このサイトを見つけました。

WordPressの更新マークがなぜか消えないときは「翻訳」を最新にすれば解決 | おもキャン

なるほど、確かに更新のところに行くと、「新しい翻訳が利用可能です」となっている。

この更新ボタンを押して更新したところ、無事Contact from 7が日本語モードになりました。

これまでこうした現象になったことが無かったので、手間取った～

テスト環境で構築したWordpressを、CPIサーバーへ移行してきたとき、なぜかForbiddenが発生してサイトが見れなくなりました。

htaccessが原因らしく、削除すると一応見れるんですが、htaccessがないわけにはいきません。

普通にWordpressとしての記述が原因らしいのですが、それも普通だしなぜ？と思って調べたら、こちらのサイトを見つけました。

CPIサーバーで「403 Forbidden」エラーが出た時の対処法

この中で、1つ目だけ試してみたところ、うまく表示されるようになりました。

htaccessに「Options +SymLinksIfOwnerMatch」を追記

シンボリックリンクについての記述みたいですが、シンボリックリンクなんて使ってないのになぜ？

とりあえず、また起こりえるのでメモ書き。

WPデフォルトのカテゴリーやカスタムタクソノミーの並び替えを行うことができるプラグイン「Category Order and Taxonomy Terms Order」

マルチサイトでは使用するのに注意が必要です。

このプラグインを「サイトネットワークで有効化」で有効化してしまうと、

並び替えができないどころか、カテゴリー自体が表示されなくなります

理由までは調査していないですが、外観＞メニューで保存すらできなくなってしまうので注意です。

対応方法は、「サイトネットワークで有効化」ではなく、サイトごとにプラグインを有効化すればＯＫ

カテゴリーも表示されるようになりますし、メニューの動作も正常になりますし、並び替えもできるようになります。

2020年8月5日更新

最近カスタムポストを使用するようになり、いろいろと変化したのでメモ。

• Classic Editor
  Gutenbergは使いづらい！という場合は、こちら。
  元々のTinyMCEに戻せるプラグインです。
• Custom Post Type UI
  カスタムポスト・カスタムタクソノミーを簡単に追加・設定できるプラグイン。
• PS Taxonomy Expander
  カテゴリーだけでなく、カスタムタクソノミーの並び替えも行えるプラグイン。
  並び替えだけでなく、カスタムポストの一覧画面でカスタムタクソノミーを表示する設定ができたりと非常に便利！
• Category Order and Taxonomy Terms Order
  カテゴリーだけでなく、カスタムタクソノミーの並び替えも行えるプラグイン。
  「PS Taxonomy Expander」が長らく更新されておらず、インストールするとクイック編集ができなくなるバグがあるので、こちらに乗り換え。
• Advanced Custom Fields
  カスタムフィールドを簡単に追加・設定できるプラグイン。
  基本はフリーですがループなどが必要な場合は、有料版（ACF Pro）を使用する必要があります。
  有料版は、以前は買い切りだったのですが、現在はサブスクになってしまいました。
  1サイト/年で49$程度ですので、この費用が出せるか、フリー版で十分な場合は、こちらの導入をお勧めいたします。
  というもの、「Advanced Custom Fields」はプレビューに対応しているんです。下の「Custom Field Suite」もとても優れたブラグインなのですが、プレビューに対応していないのがネックですね。
• Custom Field Suite
  カスタムフィールドを簡単に追加・設定できるプラグイン。
  フリーでループにも対応。
  プレビューには非対応。
• TinyMCE Advanced
  WordpressのリッチテキストエディタをTinyMCEにできるプラグイン。
  正確にはWordpressはもともとTinyMCEですが、さらにカスタマイズできるものです。
• Contact Form 7
  メールフォームを簡単に設置できるプラグイン。
  インストールと同時に、日本語化も行ってください。
  日本語化ファイルはこちら
• Google XML Sitemaps
  Google サイトマップ用プラグイン。
  公開してから有効にしよう。
• Limit Login Attempts
  ログインのチャレンジ？回数を設定できるプラグイン。
• Yoast Duplicate Post
  記事の複製を簡単に行うことができるプラグイン。
• EWWW Image Optimizer
  画像圧縮プラグイン。
  通常のレンタルサーバーなら大丈夫だと思いますが、AWS等の場合、いろいろとモジュールが足りない可能性がるので注意。
• Custom Post Type Permalinks
  （必要なら）カスタムポストのパーマリンクを設定できるプラグイン。
• Search Regex
  （必要なら）サイト内検索＆置換を行えるプラグイン。
• WP Fastest Cache
  キャッシュプラグイン。
  使いやすくて、ソースコードの圧縮もしてくれるなどなかなか便利。
• DB Cache Reloaded Fix
  データベースのやり取りをキャッシュしてくれるプラグイン。
  管理画面まで軽くなるという便利なプラグインですが、動的なプラグインとは相性が悪かったりするので注意が必要です。
• spam-byebye
  スパム対策用プラグイン。
  全然更新されていないで、引き続き使用するか要検討。

カスタムフィールドを簡単に設定できる便利なプラグイン

Custom Field Suite（カスタムフィールドスイーツ）

これでカスタムフィールドを設定している場合、普通に編集画面から内容を登録するときはもちろん問題ないのですが、独自プログラムからカスタムフィールドの内容を新規登録する場合は注意が必要です。

通常、カスタムフィールドにデータを登録する場合

add_post_meta()
update_post_meta()

を使用します。

これを使うと、確かにデータベースのwp_post_metaテーブルにデータが入るのですが、管理画面で該当記事の編集画面を開くと、データが入っていません。

かなり詰まったのですが、データベースをよくよく見てみると、「wp_cfs_values」といういかにもCustom Field Suite用のテーブルがあるじゃないですか。

要するに、これでキーとデータを紐づけているわけですね。
力技でここに紐づけ用のデータをINSERTする方法もありますが、そんなことをしなくても、ちゃんとCustom Field Suiteが関数を用意してくれています。

$post_id = （該当記事のID）;
$post_meta_datas = （登録したいカスタムフィールドの情報）;
CFS()->save( $post_meta_datas, array("ID" => $post_id) );

という形で登録する必要があります。

以下例

$post_id = 1234;
$post_meta_datas = array(
"nickname"=>"ダリ",
"mail" => "xxxxx@xxxxxx.xxx",
"url" => "https://nandani.sakura.ne.jp/"
);
CFS()->save( $post_meta_datas, array("ID" => $post_id) );

参考サイト

save - Custom Field Suite

EC-CUBEのコミュニティーでも質問させてもらったのですが、自己解決したので、ここにもメモ書き。

なお、この不具合はMySQLを使っている場合に起こります（PostgreSQLなら起こりません）

不具合の内容

例えば、商品Ａ・Ｂ・Ｃ・Ｄ・Ｅをそれぞれ５個ずつカートに入れます。（合計２５個）
ログインして「お届け先の指定」画面で、「複数のお届け先に送る」を選択し、「お届け先の複数指定」画面を開きます。
その画面で、商品ごとに（Ａ・Ｂ・Ｃ・Ｄ・Ｅごとに）
１個目は届け先a
２個目は届け先b
３個目は届け先c
４個目は届け先d
５個目は届け先e
と指定し、「選択したお届け先に送る」ボタンを押します。

↓こんな感じ

そうすると、なぜか次の画面で「お届け時間の指定」が空っぽになります。

本来であれば、↓こんな風にお届け先ごとに時間帯を選択できるプルダウンが表示されます。

原因と解決方法

原因はセッションを保存するカラムのデータ型でした。

購入フローのセッションデータは、
「dtb_order_temp」テーブルの「session」カラム
「dtb_session」テーブルの「sess_data」カラム
の２つに保存されるようなのですが、ここのカラムのデータ型は、「text」になっていました。

「text」型だと、65,535バイトまでしか保存できませんが、上記の例のような届け先を設定をすると、65,535バイトを超えます。
そのため、データが不十分な状態で保存されてしまい、届先データが消えてしまうという問題が起きていました。（実際確認すると中途半端な状態でデータが入っていました）

ここのカラムのデータ型を「longtext」型に変えることによってこの現象は起こらなくなりました。

「dtb_order_temp」テーブル

「dtb_session」テーブル

ちなみにPostgreSQLでもこのカラムはtext型ですが、PostgreSQLの場合は、text型は「制限無し可変長文字列」みたいですね。
だからPostgreSQLでは正常なのに、MySQLだと不具合が起きてしまっていたようです。

もしMySQLを使っている方がいらっしゃいましたらご注意を。

追記

改めて、「EC-CUBE2 session long text型」でググったら、該当記事がいっぱい出てきた^^;

修正方法についてはやっぱりこれで問題ないみたい。

結構昔からある不具合なのに、直さないんだなぁ・・・

json_encodeされたデータとserializeされたデータはパッと見似ています。

なので、json_encodeでエンコードされたデータだと思って、json_decodeでデコードしようとしても、serializeでエンコードされたデータだったら、デコードされません（当然）

serializeでエンコードされたデータは、unserializeでデコードしましょう。

json_encode→json_decode

serialize→unserialize

どっちか試してみて、だめなら片方でやればＯＫ

EC-CUBEやWordpressのデータは、serializeでエンコードされていることが多いです。

そもそもの原因についてはこちら

【WordPress】スラッグ名が重複すると、公開中の投稿ページが４０４になる

上記の対策方法を、こちらの記事「スラッグ名の重複対策」で書かせてもらいましたが、よくよく考えてみたら、こんなに複雑に考える必要はありませんでした。

つまり、下書きだろうが、スラッグ名を確定させてしまえばよい！（というか、なぜそうなってないのか）

プログラム修正版はこちらです。

function change_post_name($post_id){
	if(!wp_is_post_revision($post_id)){
		$get_post = get_post($post_id);
		if(!empty($get_post->post_name)){
			remove_action('save_post', 'change_post_name', 13, 2 );
			if($get_post->post_status == "draft" || $get_post->post_status == "pending"){
				$post_name = wp_unique_post_slug($get_post->post_name, $post_id, "publish", $get_post->post_type, $get_post->post_parent);
				wp_update_post( array( 'ID' => $post_id, 'post_name' => $post_name) );
			}
			add_action('save_post', 'change_post_name', 13, 2 );
		}
	}
}
add_action('save_post', 'change_post_name', 13, 2 );

7行目のwp_unique_post_slugは、wp_insert_post関数内で使用されてる、ユニークなスラッグ名を付けてくれる関数です。

この関数の第3引数が、下書きの場合は、ユニークにしてくれません（第1引数のスラッグ名をそのまま返します）

ということであれば、第3引数だけ「publish」にして、ユニークなスラッグ名を取得し、保存し直せばよい！

ということで、作ってみたのですが、とりあえず大丈夫っぽい。

※このプログラムについて責任はとれませんので、自己責任でお願いします。

参考サイト

wp_unique_post_slug – WordPress私的マニュアル

EC-CUBE2系を、テスト環境URLで構築して、本番環境URLに変更すると、サイト自体は表示されますが、ログインできなくなることがあります。

ＵＲＬを変更する際は、まず「/data/config/config.php」の下記の部分を変更します。

define('HTTP_URL', 'http://xxxxxxxx/');
define('HTTPS_URL', 'https://xxxxxxxx/');

しかしこれだけ変更しても、管理画面にログインしようとするとシステムエラーとなってしまいました。

同じく、config.phpのAUTH_MAGICを変更するとよいという情報を得たので変更してみたのですがうまくいかず。（最終的にはこれは変更しないほうがよかったです※）

ということで、追加で下記を実行

• データベースの、dtb_sessionテーブルを空にする
• 「data/Smarty/templates_c」の「admin」フォルダとサイトテンプレート用フォルダを空にする。
• ブラウザを立ち上げ直す（orブラウザを変えてみる）

これで正常にログインできるようになりました！

※AUTH_MAGICを変更していると、上記の３つを実行しても、「ログインIDとパスワードが間違っています」というエラーになりログインできなくなります。
元に戻したら、ログインできるようになりました。