作成者別アーカイブ: Web制作 システム

目次の表示・非表示を切り替えボタンが表示されないTable of Contents Plus

WordPressプラグインでページ内のhタグから自動的に目次リストを生成してくれるプラグインに、

Table of Contents Plus (TOC+)があります。

Table of Contents Plus

 

TOC+は各ページ内のhタグの構造から、ページ内のサイトマップをセマンティックにページ内アンカーリンク付きの目次リスト生成してくれるので、SEO対策などでもよく使用されているようです。

 

ショートコード[toc]を配置するだけで、設定した固定ページや記事ページ、CPT UIなどで個別の投稿タイプを追加した場合も表示できるので、とても便利です。

 

長いページが多い最近のWebコンテンツでは、この目次一覧がとても長くなることもありますが、一覧をクリック一つで表示したり非表示にしたりするリンクボタンもプラグインの設定ですぐに表示できます。

 

先日、運営するランディングページを見ていると、目次の近くに表示されていた「表示/非表示」のリンクボタンが消えていました。

TOC+の設定画面から、[ユーザーによる目次の表示・非表示を切り替えを許可]のチェックを入れなおしても表示されず、CSSを調べて見ました。

どこをどう調整しても表示されないので、JavaScriptやfunction.phpの影響を調べましたが、どこをどう制御しても表示されませんでした。

 

おそらく原因は以前GooglePagespeedインサイトでサイト速度を調整した際に、いろいろとカスタマイズしたのでその影響だろうと予想はしたのですが、あまりこの表示、非表示のボタンリンクが表示されない件についての記事が見つからず(設定方法は鬼のように見つかります)途方にくれてheader.phpを眺めていると、どうも怪しい記述が。

 

<?php wp_deregister_script(‘jquery’); ?><!–jqueryを除外–>

あ、これだ。

 

カスタマイズされた配布型のWordPressテーマを使用した場合、wp_headで実にたくさんの余分なファイルが読み込まれてしまい、ページ速度がとても遅くなることがあります。

そのため、wp_deregister_script(‘jquery’);で余分なjqueryを読み込まないようにしていたためです。要はこの記述でwp_headで読み込まれるWordPress本体やプラグインのjqueryを読み込まないように指定して、個別にファイルを読み込んだりするわけですね。

 

結果としてページスピードを調整しすぎると、Webコンテンツ本来の表示や運用中に問題が発生しやすくなるため、pagespeedインサイトに合わせすぎて特殊なカスタマイズをしすぎると、今度は逆にメンテナンス毎に対応内容が煩雑になったり時間がかかったりすので、悩みどころです。

 

例えば、CSSやjqueryをすべてインラインで短縮記述にするとファイルサイズが軽くなったり読み込みが早くなったりするということなんですが、光回線の時代に数キロから数十キロバイト軽くしたところで、いったいどういうメリットがあるのか?という疑問がずーっとあります。

 

カスタマイズされてページソースを見ると延々とスクリプト記述やスタイルシート記述が続くページを見ると、すこしゾッとします。(例えば、セレクタを追加するときは一瞬でできるとはいえ、毎回生成しなおすのだろうか?と。)

 

 

話はそれましたが、プラグインはcssだけでなくjqueryも独自に読み込みを行うものが大半なため、jqueryが重複したり、古いバージョンを読み込んだりして、結構衝突を起こしやすい傾向があります。

 

この記述を削除すると、目次の脇に「表示/非表示」のアコーディオン機能のリンクボタンが無事表示されました。考えてみるとアコーディオンボタンは基本的にjqueryが使用されることが多いので、勘のいいひとだと3秒ぐらいで気づくのだろうと感じました。

 

Table of Contents Plusに限らず、動作していたプラグインやアニメーション的な視覚効果などが動かなくなった場合は、結構jquery関係の影響が多いので、これからはそこから疑うようにしようと再認識しました。

 

ただ、Table of Contents Plusは最終更新が「Released: 5 January 2016」と大分前になるので、将来的には警告やエラーが出始めるかもしません。

個人的にはあまり更新されないほうが安定しているので良いのですが、似た機能の新しいプラグインを導入するのも良いかもしれません。

 

Easy Table of Contentsというプラグインがあり、こちらが良いようです。

Easy Table of Contents

 

 

プラグインの公式ページには、「目次を投稿や固定ページ、カスタム投稿タイプに挿入することが出来ます。使いやすく、機能に特化したプラグインです。」と説明があるので、おおむねTOC+と同じ使い方が可能だし、評価も高いようなので、このタイミングで変更してもよかったのですが、別のWordPressサイトで試してからにしてみます。

 

 

この手のプラグインは、便利だと思って導入しても使い方がわからなかったり、特定のバグやほかのプラグインとの衝突が発生したりするリスクがあるので、事前に一度、あまり負担がないワードプレスサイトで試してから導入することにしています。

 

ただ、この手の機能はシンプルな構造なので、会員管理プラグインなどのようにあまり問題が発生しにくいので、すぐに導入しても問題が起きにくいプラグインになるでしょう。

 

 

掲載情報につきましては、当サイトが独自に調査、検証および収集した情報です。

情報の妥当性や確実性を一切保証するものでなく、情報や内容が訂正や修正、変更されている場合があります。 よって、当サイトの利用により生じたいかなる損害等についても運営側にて一切の責任を負いません。

掲載情報の修正・変更等をご希望の場合はお知らせください。

InstagramのAPIでアクセストークンとユーザーIDを取得

画像を読み込んでホームページ内に一覧表示させるために、InstagramからAPIでアクセストークンとユーザIDを取得してみる。(2019年5月 現在)

 

1:インスタグラムにログインする

画像を読み込むインスタグラムのアカウントにログインします。

 

 

2:アプリケーション登録

ログインしたら一番下のフッターメニューの「API」をクリック。

画面がかわるので、Developer Signupで対象サイトURLなどを入力。初回は電話番号が必須らしい。

 

登録申請すると、管理画面から[Resister Your Aplication]でアカウント作成して、Register new Client IDで新しいアカウントを作成します。

基本項目はなんでもよいのですが、Valid redirect URIs:(基本的に読み込ませたいサイトURL)は覚えておきます。

 

3:アカウント作成

アカウントを作成すると[Manage Clients]にinsta_appが追加されるので、Client ID xxxxxxxxxxxを確認。

以下のアドレスにアクセスして、CLIENT-ID(取得したクライアントID)とREDIRECT-URI(登録時のValid redirect URIs)の部分を作成したアカウント情報でアクセス。

 

https://www.instagram.com/oauth/authorize/?client_id=CLIENT-ID(取得したクライアントID)&redirect_uri=REDIRECT-URI(登録時のValid redirect URIs)&response_type=token

 

このとき、エラーメッセージなどが表示される場合は、引数が間違っているので正確にコピペしてつなげる必要がある。

 

 

例)リダイレクトURLが登録したものと違っている。

error_message “Redirect URI does not match registered redirect URI”

 

 

4:API認証

情報が正しいと、This app is in sandbox mode and can only be authorized by sandbox users.という認証画面に遷移するので、承認ボタンをクリックで完了。

 

そうするとリダイレクトサイトURLに移動するので、アドレスバーにアクセストークンが表示される。

 

https://リダイレクトURL/#access_token=xxxxxxxxx.xxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxx(アクセストークン)

 

これでアクセストークンは取得できる。

 

 

 

5:ユーザーIDの取得

以前はユーザーIDは登録時に生成されていたが、APIが終了してしまったというこで、アクセストークンで取得しなければならない。

 

以下のようにアクセスすることで、APIから情報が取得できるので、一番上のID情報がユーザーIDになる

 

https://api.instagram.com/v1/users/self/?access_token=xxxxxxxxx.xxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxx(アクセストークン)

 

 

 

ホームページ内にインスタグラムの画像を表示させるために必要なアクセストークンとユーザーIDは以上の手順で取得できました。

 

 

 

 

 

掲載情報につきましては、当サイトが独自に調査、検証および収集した情報です。

情報の妥当性や確実性を一切保証するものでなく、情報や内容が訂正や修正、変更されている場合があります。 よって、当サイトの利用により生じたいかなる損害等についても運営側にて一切の責任を負いません。

掲載情報の修正・変更等をご希望の場合はお知らせください。

WordPressテーマファイルの編集が更新できない場合-ベーシック認証編

”致命的なエラーをチェックするためにサイトと通信できないため、PHP の変更は取り消されました。SFTP を使うなど、他の手段で PHP ファイルの変更をアップロードする必要があります。”

テスト環境でWordPressサイトをベーシック認証をかけてWordPressのテーマファイルを編集しようとするとできなくなる。

本番環境では更新が可能なのだけど、なぜか確認環境では更新ができなくなる。

 

この場合の原因のひとつは、ベーシック認証の影響によるもので、認証を無効にすることで更新が可能になる。難しい場合は、FTPでローカル反映した内容でアップする方法になると思う。

 

わりと原因がわかるとどーってことがない一例だった。

 

 

掲載情報につきましては、当サイトが独自に調査、検証および収集した情報です。

情報の妥当性や確実性を一切保証するものでなく、情報や内容が訂正や修正、変更されている場合があります。 よって、当サイトの利用により生じたいかなる損害等についても運営側にて一切の責任を負いません。

掲載情報の修正・変更等をご希望の場合はお知らせください。