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

ウィジェット的に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&client_secret='.$client_secret.'&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) > $filemtime){
        $refresh = 1;
    }
}
if($refresh == 1){
    $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);
    curl_close($curl);

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

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

  • 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関連

スラッグ名の重複対策 改

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

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

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

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

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

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私的マニュアル

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

iOSアプリの審査に落ちたこと

Androidアプリは拍子抜けするぐらい簡単にリリースできるんですが、やはりiOSアプリのリリースは難しいです。

審査に落ちた事項について、メモっておきたいと思います。(まあガイドライン読めって話なんですが・・・・)

1.起動に時間かかりすぎ

Guideline 4.0 - Design

サーバーで更新した内容をアプリにも反映させるという仕組みだったため、初回起動時に更新したファイルをすべてアプリ側に落とす仕組みにしてたんですが、さすがに画像ファイルなどまで落とすとなると数分かかってしまうため、ここで却下されてしまいました。

画像はWEBに取りに行く仕組みに変更し、初回起動は30秒内でできるようになったため、これはクリア

 

2.位置情報取得する理由をちゃんと書け

Guideline 5.1.5 - Legal - Privacy - Location Services

位置情報を取得する仕組みがあるんですが、アプリに限らずブラウザとかで初回取得時って

「”(アプリ名)”の使用中に位置情報の利用を許可しますか?」

ってメッセージが出ますよね。↓こんなやつ

デフォルトのメッセージがだけが表示されるようになっていたのですが、それに加えて説明文もいるようです。

参考サイト:iOS 8 以降のプライバシーと位置情報サービスについて - Apple サポート

今回はmonacaで開発していたので、config.xmlファイルに下記の記述を追記しました。


<platform name="ios">
・・・
<config-file platform="ios" target="*-Info.plist" parent="NSLocationWhenInUseUsageDescription">
<string>コースのどの場所にいるのかを確認するために位置情報を取得します。</string>
</config-file>
・・・
</platform>

これで、メッセージ表示時にも上記のメッセージが表示されるようになりましたし、このアプリの位置情報設定画面でも表示されるようになりました。

アプリ使用中のみ許可なら、parentは「NSLocationWhenInUseUsageDescription」、常に許可の場合は「NSLocationAlwaysUsageDescription」となります。

参考サイト:

 

次こそは頼む=人=

【追記】

上記修正後、2日後に無事審査通りました。ε-(´∀`*)

総合管理者 | 2018年01月31日 | コメント(0) | トラックバック(0) | WEB関連全般 | アプリ関連

EC-CUBE2系でドメイン変更するとログインできなくなる

EC-CUBE2系を、テスト環境URLで構築して、本番環境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を変更していると、上記の3つを実行しても、「ログインIDとパスワードが間違っています」というエラーになりログインできなくなります。
元に戻したら、ログインできるようになりました。

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

タイトル・内容のフック場所【WordPress】

タイトル・内容のフック場所は、フロントエンド、管理画面で異なるので注意が必要です。

フロントエンドの場合


//タイトルにフックをかける(the_titleをフック)
add_filter('the_title', hoge_the_title, 1);

//内容にフックをかける(the_contentをフック)
add_filter('the_content', hoge_the_content, 1);

バックエンドの場合


//投稿一覧のタイトル表示にフックをかける(the_postをフックし、内部で処理)
add_filter('the_post', hoge_the_post, 100);
function hoge_the_post($post){
//$post->post_titleを編集する 例:$post->post_title = htmlspecialchars($post->post_title);
return $post;
}

//編集画面のタイトル入力フィールドにフックをかける(title_edit_pre'をフック)
add_filter('title_edit_pre', hoge_the_title, 1);

//編集画面の内容フィールドにフックをかける(the_editor_contentをフック)
add_filter('the_editor_content', hoge_the_content, 1);

 

単純に、the_titleやthe_contentにフックするだけでは、管理画面の方で反映してくれないので注意。

特に投稿一覧では、表示だけならthe_titleのフックで行けますが、クイック編集の方にも反映させる場合は、the_postにフックし、$post->post_titleに処理を加える必要があります。

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

イベントトラッキングがリアルタイムに反映されない?

リンクをクリックした回数を計測するため、色々なサイトを参考に、リンクタグに下記を追記しました。

onclick="ga('send', 'event', '(イベントカテゴリ名)', '(アクション)', '(イベントラベル)');"

しかし、アナリティクスのリアルタイム>イベントを見ながらクリックしても全然反映されない・・・

タイムラグが有るのかな~、でも秒って書かれるくらいにはリアルタイムなのでは?と思い、他にも検索していると、このような記事が

イベントトラッキングで数字が上がってこない。 - Google 広告主コミュニティ

どうやら書き方が異なるようだ

onclick="gtag('event', '(アクション)', {'event_category': '(イベントカテゴリ名)','event_label': '(イベントラベル)'});"

アナリティクスのコードを埋め込む際、コードがかなり変わってるな~とは思っていたのですが、こちらの記述もかなり変わったみたい。

これに変えてクリックしたところ、リアルタイムにも反映されるようになりました。

総合管理者 | 2017年12月29日 | コメント(0) | トラックバック(0) | JavaScript関連 | SEO関連

cakephpでエラー表示

cakephpでバリデーションチェックにひっかかりエラーになった場合、ほっておいても入力フィールドの下にエラーが表示されます。

ただし、inputのtypeがtextの場合は、そのまま表示されるのですが、textareaの場合は、エラーになってもエラーが表示されません。

その場合は、任意に入力フィールドの直後に下記を追記します。

echo $this->Form->error('モデル名.フィールド名');

例:

echo $this->Form->error('User.name');

これでtextareaなどエラーが表示されないタイプのものでも表示されるようになります。

総合管理者 | 2017年12月18日 | コメント(0) | トラックバック(0) | PHP関連

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