CPIサーバーでForbiddenが出た場合

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

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

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

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

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

htaccessに「Options +SymLinksIfOwnerMatch」を追記

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

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

グーテンベルグで記事を作成してみた(いまさら)

ただ遊んだだけの記事です。
内容はありません。

見出しブロック

ここから段落ブロック
エンターで改行するとこのブロックが増える。

改行ごとにブロックが追加される仕様は、なんかいかつい・・・

  1. リスト
  2. リスト
  3. リスト
テーブルテーブル
テーブルテーブル
ああああえええええええええ
キャプション

カスタムHTML

テストです。テストです。テストです。テストです。

テストです。テストです。テストです。テストです。

テストです。テストです。テストです。テストです。

HTMLは自動的にばらされるんじゃなくてブロックでまとめられるのか。

クラッシックで制御する方がいいかも

(さらに…)

総合管理者 | 2020年09月04日 | コメント(0) | トラックバック(0) | WEB関連全般

カゴヤの共有サーバーでアップロードファイルの上限を上げる方法

カゴヤでは、専用サーバーの場合、管理画面からアップロードファイルの上限などの設定を行うことができます。

例:

  • memory_limit
  • post_max_size
  • upload_max_filesize

しかし、共有サーバーでは、管理画面においてこれらはロックされており使用することができません。

かといって、

「.httaccess」や「php.ini」ファイルではこれらの設定は変更できません。

しかし、変更自体は実は可能です。

ファイル名が上記と異なるのです。

実際に設定が可能なファイル名は「.user.ini

記述方法は、php.iniと同じです。

例えば、upload_max_filesizeの設定をしたければ下記のように記述します。

upload_max_filesize = 16M

このファイルを、ウェブルートにアップすれば、それ以下のフォルダにおいて上記の設定が反映されます。

しかし、「.user.ini」で設定するというのは、なかなか珍しいですね。

 

参考サイト

PHPバージョンの管理 - KAGOYA Internet Routing

総合管理者 | 2020年09月01日 | コメント(0) | トラックバック(0) | サーバー関連

Thunderbirdで全角の文字変換ができなくなった時の対処法

メールソフトであるThunderbird(サンダーバード)で突然、全角の文字変換ができなくなりました。

下図のように、「かぶしきがいしゃ」を漢字変換したくても、「か」「ぶ」「し」「き」「が」「い」「し」「ゃ」と1文字入力されるたびに確定して変換できない状態に。

このような場合は、下記の手順で直ります。

  1. Thunderbirdがアクティブになっている状態で、Windows右下の「あ」を右クリックします。
  2. 「変換モード」を選択すると「無変換」になっていると思います。
    それを「一般」に選択し直します。

これで、勝手に文字が確定せず、漢字変換できるようになります。

でもなぜか気付くと、「無変換」に切り替わっちゃうんですよね。なんでだろ・・・

ちなみに、この現象はThunderbirdに限らないので、他のアプリでも同様の現象になったら試してみてください。

総合管理者 | 2020年08月06日 | コメント(0) | トラックバック(0) | アプリ関連

WPプラグイン「Category Order and Taxonomy Terms Order」をマルチサイトで使用する場合の注意事項

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

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

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

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

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

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

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

総合管理者 | 2020年08月05日 | コメント(0) | トラックバック(0) | CMS関連

WordPressで入れておきたいプラグイン2

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
    スパム対策用プラグイン。
    全然更新されていないで、引き続き使用するか要検討。

nandani | 2020年08月05日 | コメント(0) | トラックバック(0) | CMS関連

APIを使って自分のInstagram投稿写真を取得する方法【Instagram Basic Display API】

2020/9/30

使えなくなってました・・・
再び仕様が変わった模様。
もーーーー!!!

(ここから本文)

ウィジェット的にInstagramのサムネイルが並んでいるサイト、よくありますよね。

ああいうのはInstagramがウィジェットを提供しているわけではなく、APIを使って自分のInstagramから写真データを取得し、整形して表示する必要があります。(Instagramも共有ウィジェットあるんですけどね。あんまり使い物にならないというか…)

その写真データ取得方法については、以前はInstagramAPIというAPIが使用できていたのですが、もう使用できなくなるということ。

というわけで、別の取得方法をここでは説明します。

使用するのは「Instagram Basic Display」というAPI。

・・・なんですが、これがとにかく面倒くさい。

面倒くさいけどこれでやるしかないので(正確には「Instagram Graph API」もあるけど、さらにめんどくさそう)、これを使って写真データを取得するまでの方法を説明します。

①まずFacebook for Developerへアクセスします。

https://developers.facebook.com/?locale=ja_JP

右上の「マイアプリ」を選択してください。
Facebookにログインしていない場合は、「ログイン」と表示されますので、ここでログインしてください。

②アプリリストが表示されます。

左上の「新しいアプリを追加」を選択してください。

③新しいアプリIDを作成が開きます。

「表示名」に、任意の名前をつけて、「アプリIDを作成してください」ボタンを押してください。
ここでは適当に「Get My SNS」としました。
ちなみに「Instagram」というワードはなぜか使えませんでした。

セキュリティチェックが挟まりますが、Google Recaptchaにチェックしてそのまま「送信」ボタンをしてください。

④製品を追加画面が開きます。

左上に「Instagram」が表示されていると思いますので、それを選択してください。

左メニューのプロダクトにInstagramが追加されます。
この中に「Basic Display」がありますが、ここを開いても、まだ「Instagramアプリを作成する前に、アプリの設定を更新してください。」と注意書きが表示されてしまいます。
この注意書きの中の「設定」リンクをクリックして、設定画面へ移動してください。

⑤設定>ベーシック画面が開きます。

まず下記3つを設定してください。

  • プライバシーポリシーのURL:あらかじめサイトで作成しておき、そのURLを入力してください。
  • 利用規約のURL:上記同様、あらかじめ作成しておき、そのURLを入力してください。
  • カテゴリ:どれかを選択してください(よくわからないの「ビジネス・ページ」としました)

同じ画面のまま、さらに下に行き「プラットフォームを追加」ボタンを押してください。

「プラットフォームを選択」が開きますので、ウェブサイトを選択してください。

「サイトURL」の入力フィールドが開きますので、ここに自分のサイトのURLを入力してください。
この入力ができたら、右下の「変更を保存」ボタンを押してください。

⑥左メニューのプロダクト>Instagram>Basic Displayを選択ください。

先ほどの注意書き(Instagramアプリを作成する前に、アプリの設定を更新してください。)が消えているかと思います。

一番下の「Create New App」ボタンを選択してください。

「Create a New Instagram App ID」が開くので、そのまま「アプリを作成」ボタンを押してください。

下図のような画面に切り替わります。

画面内にある下記3つを設定してください。

  • クライアントOAuthリダイレクトURL:サイトのURL
  • 承認を取り消す:サイトのURL
  • データの削除リクエスト:サイトのURL

設定が完了したら右下の「変更を保存」ボタンを押してください。

同画面のさらに下の方にある「Add or Remove Instagram Testers」ボタンを選択してください。

⑦役割画面が開きます。

一番下の「Instagramテスター」の「Instagramテスターを追加」ボタンを押してください。

「Instagramテスターを追加」ウィンドウが開きます。
自分のInstagram名で検索して選択し、右下の「送信」ボタンを押してください。

「Instagramテスター」も選択された状態となりました。
この段階ではまだ「承認待ち」です。

⑧次にInstagramを開きます。

Instagramにログインし、自分のInstagramホーム画面を開いてください。
画面右上にある「プロフィールを編集」を選択してください。

プロフィールが面が開きます。
左のメニューから「アプリとウェブサイト」を選択し、さらに「テスターへのご招待」を選択します。

先ほど、作ったアプリの招待(ここではGet My SNS)が表示されるかと思いますので「承認する」ボタンを押してください。

これでInstagram側での作業は終わりです。

Facebookに戻ります。

⑨Facebook for Developerに戻り、左メニューのプロダクト>Instagram>Basic Displayを選択ください。

下図のように変わっているかと思います。
「Generate Token」ボタンを押してください。

Instagramのウィンドウが開きます。
「(ユーザー名)としてログイン」ボタンを押してください。

下図のように切り替わります。
内容を確認して「承認」ボタンを押してください。

下図の「I Understand」にチェックを入れて、このトークンをコピーしておいてください。

コピーできたら右下の「Done」ボタンを押してください。

これでようやくInstagramの写真データを取得するためのトークンを取得できました。

長かった・・・

とはいえ、これですら、60日しか持たないらしいので、60日経ったらもう一度トークンを取得し直す必要があるんですけどね・・・

Instagram User Access Tokens

これの「Long-Lived Access Tokens」が今回取得したトークンです。

【記事内容修正 2020/07/02】

プログラム例

写真データを取得するプログラムはこのようになります。


$access_token = "(トークン)";
$url = "https://graph.instagram.com/me/media?fields=id,caption,permalink,media_url&access_token=".$access_token;
$curl = curl_init($url);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($curl);
$photo_datas = curl_close($curl);

これで、写真のURL等がJSON形式で返ってきますので、$photo_datasの中身をjson_decodeして使用すればOKです。

こんな感じのデータが取得できます。

ただし、この写真データを取得する処理には割と時間がかかります。
そのため、キャッシュを保存しておき、それを読み込んで使用するのが良いです。

そして上記の通り、今回取得したトークンは60日しか使用できません。
しかし、このトークンを使うことによって、さらに延命したトークンを取得することが可能ですので、30日経過したら、トークンを取り直す仕組みも取り入れてみます。

プログラム例2

まず、今回取得したトークンを記述した「token.txt」というファイルを作成してください。

このトークンは、30日ごとに再取得して書き換えます。

なお、トークンの内容を直接ブラウザでアクセスできてはまずいので、「token」というフォルダに作り、その中にアクセス拒否を記述した「.htaccess」ファイルと共に入れておきます。
「.htaccess」ファイルの中身は下記のとおりです。

Order deny,allow
Deny from All

次に、「Facebook for Developer」に戻って、左メニュー>プロダクト>Instagramの「Basic Display」を選択し、「Instagram App Secret」の「表示」ボタンを押して、シークレットキーを取得・コピーしておいてください。

そして下記のようなプログラムを用意します。
ファイル名は「get_photo.php」としました。
2行目の(シークレットキー)に上図で取得したキーを入れてください。


<!--?php
$client_secret = "(シークレットキー)";    //シークレットキー

$token_refresh_time = 60*60*24*30;  //トークン再取得の間隔(30日)
$token_file_path = "./token/token.txt";

$photo_data_refresh_time = 60*60*24;  //写真データの再取得の間隔(1日)
$photo_data_file_path = "./instagram_api.json";

//保持しているトークンを取得する
$fl = fopen($token_file_path, "r");
$access_token = fgets($fl);
fclose($fl);

//$token_refresh_timeの期間が過ぎたらトークンを再取得する
$refresh = 0;
if(!file_exists($token_file_path)){
    $refresh = 1;
}else{
    $filemtime = filemtime($token_file_path);
    if((time()-$token_refresh_time) --> $filemtime){
$refresh = 1;
}
}
if($refresh == 1){
$url = 'https://graph.instagram.com/access_token?grant_type=ig_exchange_token&amp;client_secret='.$client_secret.'&amp;access_token='.$access_token;
$curl = curl_init($url);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($curl);
curl_close($curl);

$decode = json_decode($response, true);
$access_token = $decode["access_token"];

$fl = fopen($token_file_path, "w");
fwrite($fl, $access_token);
fclose($fl);
}

//$photo_data_refresh_timeの期間が過ぎたら写真データを再取得する
$refresh = 0;
if(!file_exists($photo_data_file_path)){
$refresh = 1;
}else{
$filemtime = filemtime($photo_data_file_path);
if((time()-$photo_data_refresh_time) &gt; $filemtime){
$refresh = 1;
}
}
if($refresh == 1){
$url = "https://graph.instagram.com/me/media?fields=id,caption,permalink,media_url&amp;access_token=".$access_token;
$curl = curl_init($url);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($curl);
curl_close($curl);

if(!empty($response)){
$fl = fopen($photo_data_file_path, "w");
fwrite($fl, $response);
fclose($fl);
}
}
?&gt;

以上のプログラムファイルの配置はこうなります。

  • get_photo.php
  • instagram_api.json(自動生成)
  • token/token.txt
  • token/.htaccess

「get_photo.php」を定期的にcronでキックするなり、サイトにアクセスがあるたびにAjax Requestでキックするなりすれば、プログラムが実行されて、ひと月ごとにアクセストークンを再取得しつつ、1日おきにキャッシュファイルである「instagram_api.json」を生成してくれます。

あとは、写真データを表示するプログラムで「instagram_api.json」を読み込んで使用すればOK。

終わり!

参考サイト

総合管理者 | 2020年06月19日 | コメント(0) | トラックバック(0) | API関連

Custom Field Suiteを使っている場合の、カスタムフィールドの内容登録の方法

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

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

総合管理者 | 2018年12月19日 | コメント(0) | トラックバック(0) | CMS関連

【EC-CUBE2】複数商品・複数届け先を選ぶと「お支払方法・お届け時間等の指定」画面で、「お届け時間の指定」が空っぽになる不具合について

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

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

 

不具合の内容

例えば、商品A・B・C・D・Eをそれぞれ5個ずつカートに入れます。(合計25個)
ログインして「お届け先の指定」画面で、「複数のお届け先に送る」を選択し、「お届け先の複数指定」画面を開きます。
その画面で、商品ごとに(A・B・C・D・Eごとに)
1個目は届け先a
2個目は届け先b
3個目は届け先c
4個目は届け先d
5個目は届け先e
と指定し、「選択したお届け先に送る」ボタンを押します。

↓こんな感じ

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

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

 

原因と解決方法

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

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

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

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

「dtb_order_temp」テーブル

「dtb_session」テーブル

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

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

 

追記

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

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

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

総合管理者 | 2018年04月19日 | コメント(0) | トラックバック(0) | CMS関連

json_encodeかと思ったらserializeだった話

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

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

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

json_encode→json_decode

serialize→unserialize

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

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

総合管理者 | 2018年04月19日 | コメント(0) | トラックバック(0) | CMS関連

Copyright(c) 2010 - 2020 ダリの雑記