PageSpeed InsightsのCLS改善（可変画像の幅指定）
PageSpeed InsightsにWebページ診断を行った際に、CLSの問題点として
- レイアウトシフトが起きている
- 画像のwidthとheightが指定されていない
などと指摘される場合がある。
サイズ指定は「width:100%」「height:auto」としているのだが、それではだめらしい。
しかし、画面いっぱいに画像を表示したい+レスポンシブ対応もさせたい。
元画像の縦横サイズが分かっていれば大丈夫
width:100%の場合、高さの指定は以下で可能。
height:calc(100vw * (画像の縦サイズ / 画像の横サイズ))
上記で算出することで、autoという曖昧なものではなく縦サイズをしっかり指定したことになる。
こちらにより、可変サイズ画像の部分のCLSが改善された。
フォルダ内の一括検索（grep検索）
テキスト内の検索などはCtrl+Fを使っていることと思うが、フォルダ内のどこかにあるのは分かるけど、どのファイルなのかを知りたい時がある。
つまり、フォルダ内を全部検索したい場合だ。
テキストファイルは秀丸を使用しているが、「grep検索」という機能がその役割を果たしてくれる。
（他のテキストファイルにも搭載されていそうではある）
秀丸でのgrep検索の方法
- メニューの検索→grep検索
- 検索したい文字、検索対象のファイル名や拡張子、検索対象のフォルダを指定
- 大文字・小文字の区別や、サブフォルダも検索対象とするかなどを指定
- 実行
検索するファイルはワイルドカード「*」も使える。
また、一括検索だけでなくて一括置換も可能。
実行すると、新たなテキストファイルが開かれて、検索結果がずらりと表示される。
対象ファイル名と何行目か、そしてヒットした行の一部が表示されている。
確認したい行でF10を押すと、そのファイルにジャンプできるのが便利。
Wordpress：ページ判定（アーカイブページ、カテゴリページ、カスタム投稿など）
Wordpressにおいて、特定のアーカイブページなど、特定ページのときだけなんらかの動作をさせたい場合の判定について。
通常の投稿の場合とカスタム投稿の場合とで判定関数が違っていたりして、少々ややこしい。
以下などは、直近でよく使用したページ判定関数だ。
固定ページ
is_page('記事IDやスラッグなど')
シングルページ（通常）
is_single('記事IDやスラッグなど')
シングルページ（カスタム投稿（通常・固定ページも可））
is_singular('記事IDやスラッグなど')
アーカイブページかどうか
is_archive()
アーカイブページ（カスタム投稿）
is_post_type_archive('投稿スラッグ')
タクソノミーアーカイブページ
is_tax('スラッグ')
基本的にカスタム投稿を使用しているサイトが多そうなので、ここらあたりはよく使いそうだ。
これら以外にもページ判定関数はたくさんあるが、覚えきれる量ではないので都度調べることにする。
GitHubリポジトリとサーバーの連携
GitHubリポジトリを用意し、クライアントソフト「SourceTree」で複数人管理できるようになった。
だが現時点では、最新ソースをGitHubからサーバーへと都度手動で移動させる必要がある。
今回は、それを自動でサーバーに反映させるようにしたい。
FTPサーバー情報をGitHubリポジトリに設定（アカウント、PWなど）
GitHubリポジトリの「Settings」→「Secrets and variables」のActionsにて、サーバー情報を他者に見えない状態で安全に登録できる。
以下例のように設定名をつけ、実際のFTPサーバー名などを保存する。
・FTP_SERVER
・FTP_PASSWORD
・FTP_USERNAME
※上記は量産可能な個別FTPアカウントではなく、大元のFTPアカウントが必要のため、サーバーの種類に応じて調べる必要あり。
GitHubのAction機能でサーバー自動反映のプログラムを設定
GitHubリポジトリの「Action」→「New Workflow」の「set up a workflow yourself」にてAction機能用のワークフローを新規作成する。
このGitHub付属のAction機能にて、様々な外部連携やスケジュールを組むなどのカスタマイズができるらしい。
ワークフロー新規作成画面でコードが書けるようになるので、そこにサーバー連携用のコードを記載する。
コードは以下サイトを参考にさせていただいた。
がしかし、サーバーやバージョン違いからか、丸ままコピペでは動かなかったので、自分用に以下を編集した。
・SamKirkland/FTP-Deploy-Action@2.0.0 の末尾を4.1.0に変更
・「env」を「with」に変更し、with以下をこちらの別サイトを参考にして書き換え
・local-dir行を削除
・server-dirは、/xxx.co.jp/public_html/～～ （※エックスサーバーの場合）
そしてコードを保存。プッシュ時にサーバーへのソース反映が行われるようになる。
うまく反映されないなどのエラーが起きている場合は、GitHubのActionメニューで実行状態を確認し、コードを修正する必要あり。
Sourcetree（GitHubクライアントソフト）の使い方
GitHubに関してこれまでに、以下を行ってきた。
・GitHubアカウントを作成
・GitHubリポジトリの取得・更新を行うために、クライアントソフト「Sourcetree」をインストール
以後まず最初は、GitHubにソースをアップロードすることだが、それはGitHubで作成したリポジトリの「Code」メニューへ単にドラッグ＆ドロップすることで可能だ。
Sourcetreeでは以下のような操作を行って、GitHubからのソース取得やソース更新を行っていく。
１．初回：GitHubリポジトリからソースを新規取得（クローン）
クローン（Clone）メニューにて、GitHubリポジトリからソースをローカルフォルダに取得する。
クローン設定項目の「元のパス」には、GitHubリポジトリのurlを貼り付ける。
取得先フォルダを指定してから取得。
こうしてローカルへと取得したソースをまとめたフォルダが「ローカルリポジトリ」となる。（GitHubリポジトリは、Sourcetreeから見るとリモートリポジトリと呼ばれる）
２．2回目以降：GitHubリポジトリから最新ソースを取得（プル）
一度GitHubからソースを取得できたらローカルリポジトリが作られるので、クローンは基本的に不要になる。
次回以降はプル（Pull）で、GitHubリポジトリから、更新された分だけの差分ソースをローカルリポジトリに取得する。
複数人管理の場合は、自分の作業前のプルは不可欠だ。
３．更新したソースをGitHubリポジトリに反映させる（コミット→プッシュ）
ローカルでソースを追加や編集したら、それをリモートリポジトリへ反映させる必要がある。
まずはコミットで反映対象のソースを選択状態にし、プッシュでそれを実際にリモートリポジトリに反映させる。
また、コミットとプッシュをひとまとめに行いたい場合は、コミット時に「変更をすぐにプッシュする」にチェックを入れると良い。
ちなみに、複数人で同じ箇所を編集していてプッシュし、衝突が起こったときにはその箇所を教えてくれる。
そこを手直ししてからプッシュしなおせるので安心。
