t_hazawaの日記

株式投資とWebエンジニアリングのブログです。株式投資の目次は→です。 https://t-hazawa.hatenablog.com/entry/2021/02/12/220933

業務のEC2をCloudFormationにするぞ3:私物AWSで練習適用編

経緯・あらすじ

  • 前回までで、業務のAWS(踏み台サーバ周りのNW)を cFnのテンプレにした
  • その後、チームメンバーに説明してレビューしてもらった
  • それを適用すべく、まず私物AWSに同じ構成+ nginx EC2 を立てて、インポート練習をした
  • すると、作ったテンプレでは通らなかったので、足りないところを足していく
  • 結果、最終的に、私物AWSを cFn管理にすることができた。

作ったcFnテンプレについて

  • 詳しくは 前回の 「15日め」に書きましたが、 CloudFormationの実践ベストプラクティス - Qiita のベストプラクティス構成を踏襲しています。
  • 思いっきり「CDKを使いましょう」と書かれてますが、一旦 cFnをマスターしたかったので、このSSHサーバ周りのNWだけ、cFnだけでやってみています
    • それをしてよかったか, 悪かったかは 後日 CDKを学んだ時にこのブログに記します。

インポート検証環境つくり

方針

  • 本稼働環境を稼働させたままcFn管理にできると思うけれど、それを実証したい
  • ので、nginxをec2で動かして、ブラウザで1秒毎にアクセスしてやってみた
    • インターネット経由のアクセスだし、(あまり頻繁にしてブロックされると嫌なので)1秒毎で良いと思う(アドオン利用)

やったこと

私物AWSでインポート練習してみたら問題が何個も発生した

  • 練習したら、問題が何個も見つかった

問題1: ネストしたテンプレでは、実際にインポートしたいリソースをインポートできない

  • 一番上の stacks/master.yml を「既存のリソースを使用する」で読み込んでも、その .yml で読み込んでる、 cFnのNetwork Stack の Stack IDを入力する画面にしかならなかった
  • インポート機能自体が 2019/11 にできたものなので、ネスト先で使ってるリソースのインポートにはまだ対応して無くても仕方ないなと諦めた (2021/08/23)
  • 仕方ないので、 templatex/VPN.yml とかで1つずつ インポートして、それらを読み込む stacks/network/master.yml や stacks/master.yml もインポート作成操作をしようと考えた
  • CDKでこのあたり(インポート周り)も楽になるか要チェックポイント

問題2: 個別にインポートしてると Outputs を吐けない

  • templates/network/VPC.yml を使ってインポートしようとしたら↓を言われた
    • As part of the import operation, you cannot modify or add [Outputs]
  • 一旦消して先に進めた
    • でもインポートじゃない時だけ Outputs する、でいい気もする (この後やってみたい)
      • 多分 UPDATEの時( UPDATE_COMPLETE にする時) には必要そう

問題3: インポートできないリソースがある

  • AWS::EC2::Route や AWS::EC2::VPCGatewayAttachment は、インポートに非対応、と実行して初めてわかった
    • もちろん、「どれがインポートに対応してるよ」表はAWSのドキュメントにあるんだけど
    • 「次のリソースタイプは、リソースのインポートではサポートされていません: AWS::EC2::VPCGatewayAttachment 」
    • 「次のリソースタイプは、リソースのインポートではサポートされていません: AWS::EC2::Route」
    • 「次のリソースタイプは、リソースのインポートではサポートされていません: AWS::EC2::SubnetRouteTableAssociation」
  • 一旦、対応してないリソースは消して、(練習用私物AWSで)インポートしてみた
    • だが、後にそういう対処は誤りだと思った (既にある場合はリソースを作成しない、にテンプレをConditionalにするのがよさそう、と思っている 2021/08/23 23:35)

(自分の過ち: インポートするcFn Stackにも DeletionPolicy と UpdateReplacePolicy が必要)

  • The following resources to import [PubSubAPne1d, VPC, IGW, RouteTableToIGW] must have DeletionPolicy attribute specified in the template.
  • cfn-lint でも怒られてたっぽい

問題4: IMPORT_COMPLETE のステータスのスタックを親スタックはインポートできない (のでUPDATE_COMPLETEにしておく必要がある)

  • 4つを一旦インポートしてみたので、その4つをインポートして stacks/network/master.yml を作ろうと思った。
  • しかし、 ↓のように言われた
    • Stack arn:aws:cloudformation:ap-northeast-1:1728XXXXXXXX:stack/igw-20210821/ed4a66a0-0253-11ec-b20d-XXXXXXXX5d45 is not in an importable status, current stack status is IMPORT_COMPLETE.
      
  • IMPORT_COMPLETE では importable ではないらしい
  • ダメといわれた stack で、 変更セットを作成して、適用すると、 UPDATE_COMPLETE になった。そうすると、 stacks/network/master.yml でインポートしたところ、そのエラーは言われなくなった。

問題5: 0.0.0.0/0 のRoute が既にあるから追加できない と言われる

  • PubSubを一度、Route 抜きで既存リソースをインポートして作ったあとに、 Routeありにテンプレを戻して更新セット作ろうとしたら、「0.0.0.0/0 のルートはあるから」作れないよ、と言われた
  • ので、 テンプレをConditionalにしてやり直そうと考えているところである 2021/08/23 23:42

リソースが無い時だけRouteとかのリソースを作る編 2021/08/24 0:03 32min

  • あまり役立たなかった AWSドキュメント
  • 少し役立った AWSドキュメント
  • ☆ドンピシャなAWSドキュメント
  • なんか、 渡したParameterでの分岐しかできないようだった
    • 既にリソースがあるかをcFnに調べてもらって分岐はできなさそうだった
    • まだcFnは発展途上だから仕方ないかな
    • CDKでできるかは要チェックポイント
  • 途中で出てきた noecho のマスク助かる (パスワードとかを非表示にできる)
  • 「テンプレートに認証情報を埋め込まない」
  • aws::novalue擬似パラメーターは、戻り値として使用された場合、対応するリソースプロパティを削除します。

  • cFnでソフトウェアインストールとかする時は、cFnのヘルパースクリプトというのを使うらしい

その方針でやった結果

  • 概ねうまく行った
    • 最終的に、nginxを止めないまま、CloudFormation管理下に置くことに成功した

問題6: 子を持つCloudFormation stackはインポートできない

  • 一番上のmaster.yml は無くして、networkスタックとかを5つ管理しようと思った

結局インポートする時にやったこと

  • ↓のテンプレを使ってインポートするには…

    1. ↓のテンプレの templates/ の各ファイルを使って、4つのスタック(VPC, IGW, PublicSubnetRouteTable, Subnet) をインポート作成していく
    2. その際、 Outputs と importに対応してないリソース(Conditionalなリソース)の部分は手元で消して、その手元のテンプレをcFnのマネジネントコンソールでアップロードしてインポートしていく (IMPORT_COMPLETEになる)
    3. インポートしたら、Outputsと 消したリソースを戻した元の状態のテンプレをcFnマネジネントコンソールでアップロードして変更セットをつくり、反映し、 IMPORT_COMPLETE を UPDATE_COMPLETEにしておく
    1. 4つの templates のリソースをインポートできたら、network スタックを作る
    2. S3に下のテンプレを全部アップロードして、 cFnマネジネントコンソールで S3上の stacks/network/master.yml を選んでインポートする
    3. インポートできたら、 変更セットを現在のテンプレートを使用する で作って、反映し、 IMPORT_COMPLETE状態からUPDATE_COMPLETE にしておく

できたcFnのテンプレート (197行)

stacks/network/master.yml (48行)

AWSTemplateFormatVersion: "2010-09-09"
Description: MyService Network Stack

Resources:
  VPC:
    Type: AWS::CloudFormation::Stack
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      Parameters:
        VpcCidrBlock: 172.31.0.0/16
      TemplateURL: 'https://myservice-cfn.s3.ap-northeast-1.amazonaws.com/templates/network/VPC.yml'

  IGW:
    Type: AWS::CloudFormation::Stack
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      Parameters:
        VpcId: !GetAtt VPC.Outputs.VpcId
        CreateOrImport: "import"
      TemplateURL: 'https://myservice-cfn.s3.ap-northeast-1.amazonaws.com/templates/network/IGW.yml'

  RouteTableToIGW:
    Type: AWS::CloudFormation::Stack
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      Parameters:
        VpcId: !GetAtt VPC.Outputs.VpcId
        IgwId: !GetAtt IGW.Outputs.IgwId
        CreateOrImport: "import"
      TemplateURL: 'https://myservice-cfn.s3.ap-northeast-1.amazonaws.com/templates/network/PublicSubnetRouteTable.yml'

  # Subnets
  PubSubAPne1d:
    Type: AWS::CloudFormation::Stack
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      Parameters:
        VpcId: !GetAtt VPC.Outputs.VpcId
        VpcCidrBlock: 172.31.32.0/20
        AvailabilityZone: "ap-northeast-1d"
        RouteTableId: !GetAtt RouteTableToIGW.Outputs.RouteTableId
        InternetAccessibility: "public"
        CreateOrImport: "import"
      TemplateURL: 'https://myservice-cfn.s3.ap-northeast-1.amazonaws.com/templates/network/Subnet.yml'

templates/network/

VPC.yml (22行)

AWSTemplateFormatVersion: "2010-09-09"

Parameters:
  VpcCidrBlock:
    Type: String
    AllowedPattern: (\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})/(\d{1,2})
    Description: IP address class used for VPC.

Resources:
  VPC:
    Type: AWS::EC2::VPC
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      CidrBlock: !Ref VpcCidrBlock
      Tags:
        - Key: Name
          Value: vpc-cfn

Outputs:
  VpcId:
    Value: !Ref VPC

IGW.yml (34行)

AWSTemplateFormatVersion: "2010-09-09"

Parameters:
  VpcId:
    Type: String
  CreateOrImport:
    Type: String
    AllowedValues: ["newly create", "import"]

Conditions: 
  CreateNewAttachment: !Equals [!Ref CreateOrImport, "newly create"]

Resources:
  IGW:
    Type: AWS::EC2::InternetGateway
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      Tags:
        - Key: Name
          Value: igw-cfn

  AttachGateway:
    Type: AWS::EC2::VPCGatewayAttachment
    Condition: CreateNewAttachment
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      VpcId: !Ref VpcId
      InternetGatewayId: !Ref IGW

Outputs:
  IgwId:
    Value: !Ref IGW

PublicSubnetRouteTable.yml (41行)

AWSTemplateFormatVersion: "2010-09-09"

Parameters:
  VpcId:
    Type: String
  IgwId:
    Type: String
  CreateOrImport:
    Type: String
    AllowedValues: ["newly create", "import"]

Conditions: 
  CreateRoute: !Equals [!Ref CreateOrImport, "newly create"]
    
Resources:
  RouteTable:
    Type: AWS::EC2::RouteTable
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      VpcId: !Ref VpcId
      Tags:
        - Key: Name
          Value: public-subnet-routetable-cfn

  # Routing
  # (Route for local will be created automatically as 1st priority routing)
  # PubSub-Internet Routing
  RouteToIGW:
    Type: AWS::EC2::Route
    Condition: CreateRoute
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      RouteTableId: !Ref RouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref IgwId

Outputs:
  RouteTableId:
    Value: !Ref RouteTable

Subnet.yml (52行)

AWSTemplateFormatVersion: "2010-09-09"

Parameters:
  VpcId:
    Type: String
  VpcCidrBlock:
    Type: String
    AllowedPattern: (\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})/(\d{1,2})
  AvailabilityZone:
    Type: String
    AllowedValues:
      - "ap-northeast-1a"
      - "ap-northeast-1c"
      - "ap-northeast-1d"
  RouteTableId:
    Type: String
  InternetAccessibility:
    # This Parameter is used only in Name tag
    Type: String
    AllowedValues:
      - "public"
      - "private"
  CreateOrImport:
    Type: String
    AllowedValues: ["newly create", "import"]

Conditions: 
  CreateRouteTableAssociation: !Equals [!Ref CreateOrImport, "newly create"]

Resources:
  Subnet:
    Type: AWS::EC2::Subnet
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      AvailabilityZone: !Ref AvailabilityZone
      VpcId: !Ref VpcId
      CidrBlock: !Ref VpcCidrBlock
      Tags:
        - Key: Name
          Value: !Join 
            ["-", [!Ref InternetAccessibility, "subnet", !Ref AvailabilityZone, "cfn"]]

  # Associate Route Table To Subnet
  AssoRouteTable:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Condition: CreateRouteTableAssociation
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      SubnetId: !Ref Subnet
      RouteTableId: !Ref RouteTableId

感想

  • 慣れたらスムーズかも
  • でも全然ワンタッチではないので、CDKに期待
  • メキメキとCloudFormation力がついていってるのが分かるのはいいね (AWS NW知識もついた)
    • CloudFormation力は CDKでも要るはずなのでいいんじゃないかなと思う

時間管理

  • 前回まで(0からcFnを学んで、cFnテンプレにして、チームメンバーに共有するまで)で 23.5時間かかっていたらしい
    • ~ 2021/7/28
  • 今回は、そのテンプレを使って私物AWSでcFn管理下にするまでで、9時間かかった

エンジニアのためのWordPress開発入門を読む

経緯

凡例

  • 文末や文頭の数字はページ番号

本の概要

  • gihyo.jp
  •  発行: 2017.01.26 使用されている WordPress Version: 4.6 (2016/8/16)

  • と古いけれど、(最新は WordPress 5.8 2021/7/20)
  • 目次の内容的には、WordPressのコア部分の仕組みでドンピシャだし、コア部分は4.6から変わってないようだし、Amazonのレビューにも 2020/11とかでも絶賛している人が複数いる
  • (416ページ)

所要時間予想

  • 前のDocker実践ガイド(496ページ)は12時間で読めたので、これもそれくらいか、ページ数が少ないので 10時間くらいで読めるだろう

書評(全部読んだ感想)

  • WPはそんなに複雑ではなかったが、学ばないとわからない箇所も何箇所かはあるので、読んでわかったのは良かったと思う
  • テーマいじりやプラグイン作りは問題なく、十分に理解してできるようになるんじゃないかなと思う
    • ので、最初の目的を達成できたかと思う
  • 後半は自分の求める以上に詳しかった (ので素早く読み飛ばしていった感じ)
  • 10.5時間かかってるけど、妥当そうな感じ。ペイしそうな気もする (大損という感じはしない)
    • 自分の中になかった概念は殆どなかったので、その点では物足りないかも。 (でもWPをいじるのなら読んで良かったと思う)

章ごとの詳細・要点など

はじめに

  • iii 27min 読み始め
  • iv 31min
    • WordPress語(独自DSL)はなく、全部PHP関数だよ
    • いろんな事が既存プラグインだけでできるよ
    • 既製品を使い回せると同じものを開発しなくていいね
  • v 34min 目次

第一章 WPとは

1.1 できること

  • 2 36min (ここがpdfの20ページ目)
  • 3 38min
    • 実はWPもモバイルアプリケーションのバックエンドデータサーバーになるのかも。
    • 商品の在庫管理システムにもなる…らしい(?)
    • 実はWPもこういうデータの抽象化をできて、5章(基本アーキテクチャ)にそのことが書いてあるらしい
    • WPのテーブルは12個、主要なエンティティはたったの4個
      • wp_posts, wp_users, wp_comments, wp_term_taxonomy(カテゴリやタグ)
  • 4 41min
    • この制限でWebアプリケーションを作るのがちょうどいい湯加減とのこと
    • 画像もwp_postsテーブルに格納
    • サイトのメニューデータもwp_postsに格納 (なかなか頭痛くなってきた)
    • 編集履歴も wp_posts (これは知ってた)
    • APIでカバー
    • ブログ記事以外のデータも表現できる!(とのこと)
    • 「抽象度の高いスキーマ
    • まぁ、たしかに crud, 権限、検索とかの機能は備わってるね
      • (gemでいい気がする)

1.2 ライセンス

  • 5 46min
    • サービス提供だけならソフトの配布じゃないから GPLに従ってのコード公開はしなくていいよ とのこと

1.3 魅力

  • 6 48min
  • 7 48min
  • 8 48min
    • プラグインはほんといいよね
    • 試してみるのも楽ちん
      • 実際にmaintenance 用のを 3つ入れみて試すのもかんたんにできた
    • プラグインのコード編集もできるのだ 実装の参考にもなるね
      • まぁ配布元がバージョンアップするので、普通は自分で改造はしないね
  • 9 50min

1.4 エコシステム

  • 10 52min
  • 11 52min
    • 公式ドキュメントは Codex という (Mediawiki風見た目)
      • Codexの中で検索するのがおすすめとのこと
  • 13 53min
    • WordBench というコミュニティもある。神戸にもある (勉強会)

1.5 心構え

  • 14 54min
    • 外部設計
    • 最初に「どれはプラグインでできるか」を考えるのが大事とのこと
  • 15 56min
    • 詳細設計・プログラミング
    • ディレクション
      • 頑張って、クライアントの要求をプラグインでできることに落とし込もう!(とのことらしい)
  • 16 2min 2021/08/07 19:56
    • HTMLコーディング
    • HTMLコーディングがあるらしい (意識したことなかった)
    • デザイン・HTMLコーディング担当者にもWP知識が必要
    • WP独自のコーディング規約があるよ (PSRではない)
      • WordPRESS CODING STANDARDS (入力ソフトが大文字固定になった)
      • タブインデントはうーん
  • 17 5min

第二章 環境の準備

2-1 Wpの準備

  • 20 7min
    • 少なくとも当時は Imagick や GDが必要だったらしい というか今でも必要そう
  • 21 8min
    • 他のテーブルがあるデータベースにもtukureるのはPHPUJ HD UJ HD 特有の融通の効く感じがあある
  • 22 10min
    • Docker実践ガイドでもよくみたWPセットアップ画面
  • 23 10min
  • 24 11min

2.2 開発環境整備

  • 24
    • WordPressにはデバッグや テストのための気の利いた仕組み、コンビニエンスなメソッドなどがほとんど 準備されていません。 - 清々しい

    • でもデバッグモードはあるとのこと PHPエラーのNoticeとかが画面表示されるとのこと
      • 結構基本的な記録はできそう データベースクエリとか
    • /wp-includes/default-constants.php に色々なデフォルト値がアルらしい
  • 26 15min
  • 28 17mon

2.3 WP-CLI

2.4 VCCW (Vagrantで開発環境)

  • 31 21min
  • 32 23min

第三章 基本機能

3.1 表示オプション

  • 34 23min
    • そう、最初は非表示になってるものが多いよね
    • 管理画面の色々なところで右上の「表示オプション」を確認しよう

3.2 投稿と固定ページ

  • 34
    • 固定ページは、各ページに親子関 係を持つことができ、例えば「トップ > 会社情報 > 沿革」といった階層のあるサ イトのページ構造を簡単に表現できます。 - ◎知らなかった

    • スラッグ: 多分パーマネントリンクになる文字列
    • カスタムフィールドに商品の値段などを保存できる (大事な機能とのこと)
  • 36 27min
    • 開発者が独自の投稿タイプを作ることもできる
      • この機能を使って色々な種類のデータを表現できるとのこと
      • TODO 投稿タイプをつくって投稿ステータスとして 大事、どうでもいい みたいな とのこと

3.3 メディア

  • 36
    • メディアのメタデータも wp_posts に保存される (PHP感ある)
    • 他の投稿タイプと同様にタイトルやファイルの説明(本文)を保存できます

    • なるほど、たしかに posts っぽいかも
    • フロントサイトにファイルそれぞれ固有の公開ページを持つこともでき(テーマの対応は必要)

    • ちょっとなるほど感かも
      • でもやっぱ分けた方がデータの作りとしてきれいな気がするが 時限公開とか周辺機能も含めると posts なのかな
    • テーマを作ると、作るサムネイル画像サイズをいろいろ用意させられるよ

3.4 カテゴリーとタグ (タクソノミー)

  • 37 32min
    • タクソノミー: 分類
    • カテゴリーは親子関係OK
    • やはり開発者が新たなタクソノミーを作れる
    • 例えば、商品という投稿タイプに色、サイズ、形状といった分類も簡単に追 加できます

3.5 投稿フォーマット

  • 38 34min
    • 投稿フォーマットは、投稿データの表示方法の指定を標準化する目的で導入 された機能です。aside、gallery、imageなど、標準も含め10個のフォーマッ トの種類が規定されています

    • チャット履歴もある 外部リンクも status(twitterみたいな) ポッドキャストにも使える audio
    • テーマは投稿フォーマットに応じてビューを変更できる
    • フォーマットは開発者が追加できないらしい (当時は?)
      • 投稿フォーマットという機能自体が、投稿の種類を標準化し、テーマ間での互換性や、外部ブログツールとの連携などの目的として導入されたものですので、いたしかたないところではあります

3.6 テーマのカスタマイズ

  • 39 36min
    • テーマは見た目だけでなく機能も含むよ
    • 開発者はテーマを実装コンテナにするよ
    • ヘッダに画像をフクませられたりする

3.7 うぃじェット

- 最近の投稿とかもウィジェット
- フロントサイトの構成要素に使う

3.8 カスタムメニュー

  • 41 39min
    • 階層化もサポート
    • なお、カスタムメニューの管理画面(図3.6)では、表示オプションで隠れて いる機能が多いです。

    • わかりみ (リンクを新しいタブで開く、とか)

3.9 ユーザと権限

  • 42 41min
    • Role もあるよ
    • 標準の権限グループは管理者、編集者、投稿者、寄稿者、購読者と5 種類

    • 設定 > 一般メンバーシップ で訪問者がユーザ登録申請できるようにできる

3.10 サイト設定

  • 43 43min
    • メール投稿機能もある さすがWPなんでもある
    • 更新情報サービスXML-RPCによるping送信オプション

    • フロントページの表示」で、トップページで何を出すかを設定できる
  • 45 46min,
    • 素手にアルものは既製品を使おう

第4章プラグインで機能拡張

4.1 Toolset Types エンティティの追加と構成

  • 48 47min
    • WordPress では、カスタムフィールド、カスタム投稿タイプ、カスタムタクソノミーと呼ばれる、いろいろなデータ表現を構成するための3つの重要な 機能があります

    • これらを利用することで、例えば商品といったデータ型を作成し、価格などの属性、またその色、サイズといった分類を扱うことができま す。また、この価格、色、サイズなどをエンティティと呼びます。

    • プログラマブルなアプローチについては、「第8章 投稿データと関連エンティティ」を参照してください。

    • Toolset Typesプラグイン
    • カスタムフィールド、カスタム投稿タイプ、カスタムタクソノミーの3つの機能を管理画面から制御できる
    • 管理画面の←絡むに「商品一覧」とか商品カテゴリ一覧とかを追加できるようになるプラグイン
    • カスタムフィールドのみ管理する場合は、Advanced Custom Fieldsプラグイン注2 が有名で、とても多くのフィールドモジュールが提供されています また、カスタム投稿タイプとカスタムタクソノミーのみ管理する場合は、Custom Post Type UIプラグイン注3 が有名です。

    • ここでは Toolset types プラグインの説明
    • 投稿タイプのリレーション…?
    • 投稿フィールド/ タームフィールド / ユーザーフィールド …?
    • フィールドとは、例えば商品というデータについて、価格や商品画像といった属性を追加したい場合に利用するAPIのことです

    • なるほど
    • Toolset Types プラグインでは、これの編集がかんたんにデキる
  • 50 52min,
    • データに audio とか日付をつけられるっぽい
    • みんな大好き WYSIWYG エディタ
    • 作成したフィールドは、ビジュアルエディターにショートコードを利用することで、情報を表示することが可能です

  • 53 54min
    • 編集画面に Types ボタンができる
    • 投稿タイプのリレーション
    • post_type = user が post_type = booking を作ると post_type = room が確保される とのこと
      • すべてがpost_typeになる世界観
    • 部屋予約システムもWPでできる (と書かれている)
    • これも Toolset Types プラグインで操作可能にできるから、プラグイン導入ュだけで部屋予約しすてむがつくれますよ
      • まぁ、開発いらないなら、たしかに意味はありそう。 ☆ノーコードの先駆け!?

4.2 Contact Form 7 (お問い合わせフォームプラグイン)

  • 54 1min pdfやブログ開くのに1minかかってる2021/08/08 12:22
  • 56 2min
  • 60 3min
    • 送信後の遷移は on_sent_ok: に location javascript を書くとのこと
    • Flamingo プラグイン - 問い合わせメールを、WP管理画面でメッセージを確認できるようになる
  • 62 4min
  • 63 
    • フックを使ってcontact form 7を改造しよう

4.3 WP super cache

  • 64
    • WordPress.com を 運 営 し て い るAutomattic注9が開発しているページキャッシュプラグイン

    •  ページ圧縮機能やCDN(Content Delivery Network)との連携が可能 ・mod_rewriteキャッシング・PHPキャッシング・全ページキャッシュ

    • すごそう
  • 65
    • PHPを介さずにmod_rewriteを利用してキャッシュファイルを提供するため、非常に速くページが表示される。Apachemod_rewriteが必要となる

  • 67

4.4 BackWPup

  • WordPressのファイル一式、データベースのバックアップを行えます注11。ropbox、Amazon S3などの外部ファイルストレージへのバックアップをすることが可能です。

4.5 user role editor

  • 73 少なくとも当時はこれが無いと管理画面で操作出来なかったらしい

4.6 Adminimize

  • 76 管理画面でできることを制限
    • 管理画面の表示の仕方も調整できるらしい(かなり細かく)

4.7 Really Simple CSV Importer

  • 87 wpプラグインの直接的なネーミングセンス好き
    • ・フックを使ってインポートデータを加工できる

4.8 Super Socializer ──SNS連携──

4.9 WP-Polls ──アンケート──

  • 94

4.10 WP Total Hacks ──WordPressでよく行うカスタマイズ──

  • 97 色んなカスタマイズができる
    • Appleアイコンを入れるとか

4.11 その他便利なプラグイン

  • 101 2min
    • 色々なものがある
    • Duplicate Post で複製ができる
    • Head Cleaner で CSS圧縮やJavaScript をフッターにもっていける
    • Simple Page Ordering や PS Taxonomy Expander でページやタクソノミーの並び順を変更できるらしい
    • リダイレクトを設定するプラグインもある
    • 既製品で使えるものは使おう

5 WPの基本アーキテクチャ

5.1 ファイル構成

  • 106 4min
    • コアファイルは /wp-includes/ にある
    • 普通は /wp-content/ だけをいじる (確かに自分もそこしかいじってない)
    • テーマやプラグインとして開発・実装をするよ
  • 107 7min
    • テーマとプラグインは、ざっくり見た目/機能という感じだけど、実際は保存するディレクトリが違うくらいの違いしかない
    • style.css と index.php がテーマの最小構成
  • 108 9min
    • style.css の先頭にコメントでメタ情報を書くことでWPにテーマとして認識されるのだ (豪快)
      • PHPファイルだと、リクエストによって読み込むPHPファイルが違うから仕方ないね
      • テンプレートがなにかは 5.9 に書かれてるらしい
    • みんな大好き functions.php。 テーマディレクションの直下にあるよ
      • ぼくも require で functions.php から特定の領域のPHP処理を切り出してるよ(RSS用に記事を取得する処理とか)
  • 109 13min
    • これくらいしか制限・規約がないから学習コストが低いね (共通性は低くなるけど、WPのテーマは小さいから別にいいね)
      • 一応標準テーマをお手本にすると共通的になるかもね

5.2 データ構成

  • 109
  • 110 15min
    • データベースの概略図がここにある
    • 確かにシンプル 13テーブル
    • posts, users, comments がメイン
    • term_taxonomy で 投稿を分類するよ
  • 111 18min
    • wp_posts.post_type で中身がなにか示してるよ
    • post_status も大事らしい 拡張できるらしい
    • wp_postmeta に保存するデータをカスタムフィールドというらしい.
    • トラックバックやピンバックも comments
    • ユーザ情報の多くは usermeta に保存されてる
    • カスタムタクソノミーもあるよ
  • 112 21min
    • 投稿タイプ
    • 画像やファイルは wp_posts.post_typeは attahment だよ
    • nav_menuもここ
    • カスタム投稿タイプ
  • 113 23min
    • register_post_type( 'goods', array( 'label' => '商品', 'public' => true, 'show_ui' => true, ) );

    • ↑を書くだけで 商品投稿タイプが追加されるし、管理画面の←カラムに編集ヨウメニューができる
  • 114 25min
    • ありとあらゆるデータを wp_posts に保存できるのだ
    • 組み込みの wp_posts には ブログ記事用カラムしかないので、カスタムフィールドを追加してそこに価格とかを保存できるようにする,
    • update_post_meta(74, 'price', 1000); $price = get_post_meta(74, 'price', true); $price = $post->price;

    • キーとバリューを指定して保存できるのかな?
    • カスタムフィールドの特徴として、スキーマを持たないことが挙げられます。データは任意の投稿に紐づけて、任意のキーで、いつでも簡単に保存できます

    • わかりやすいしくみ
    • NoSQLの先駆け!?
    • 管理画面で操作できるようにするには Advanced Custom Fields プラグインとかを使うといいとのこと
  • 116 28min
    • タクソノミー (カスタムタクソノミー)
    • register_taxonomy( 'goods_category', 'goods', array( 'label' => 'カテゴリー', 'show_ui' => true, 'hierarchical' => true, ) );

    • やっぱりコードはかんたん
    • やはりこれだけで goods の管理画面に追加される (カテゴリーとして)
    • タグと カテゴリーは特別なタクソノミーで、WPの組み込みで 追加実装が色々とあるよ
    • コメント
    • コメントには承認や特化したUIとかの特別な事項があったりするよ
  • 118 31min
    • 口コミ情報風に見せることもできるとのこと
    • wp_postsをpost_typeを変えていろんなデータに適用させるのは、 Railsの単一テーブル継承と似ているとのこと
      • 管理画面とかを使い回せるのがよいとのこと
    • カスタムフィールドはあまり検索に向いてないとのこと,
      • 価格を価格帯で検索するには 別に価格帯のタクソノミーをつけるといい、みたいな

5.3 基本的な処理の流れ

  • 119 35min
    • 待ってました
    • WordPressには、いわゆるMVCのWebアプリケーションフレームワークにあるコントローラーやアクションといったものは存在しません

    • 力強い
    • データの抽出も、テンプレートの選択も、リクエストされたパラメーターに基づいて自動的に決定し、処理されます

    • これを使いこなすのが大事とのこと
    • フックがいろんなところにあるので使いこなそう (これはいいね)
    • MVCとのわかりやすい比較の図,
    • ぼく(羽沢)は functions で呼ぶ処理を model に切り出して requireした
  • 121 40min
    • リクエストパラメータで、どの処理に分岐されるか把握するのが大事
    • p=1111 は post 表示だし、 cat=4 はカテゴリー一覧表示なのだ
      • 何のデータを取得するかも、振り分け時に決まる (メインクエリ) (クエリフラグ)
      • この種類はたくさんあるとのこと
    • データを出力するための処理をループというよ メインクエリだとメインループ
    • 処理のコンテキストが重要
  • 123 44minj
    • テンプレートファイルにphp処理を書きすぎるのはよくないよ、フックでやるとよいとのこと
    • 例えば、リクエスト解析直後の処理にフックして、リクエストパラメーターを変更して既定の処理を変えたり、データが検索される直前にフックして検索パラメーターを変更して検索結果をコントロールしたり、特定のページへのリクエストのときだけ、HTML側からロードするJavaScriptファイルを追加したりすることができます

    • add_action( $tag, $function_to_add, $priority, $accepted_args );

    • でフック登録できるとのこと (ほしい 場所にフックがないことも結構あるとのこと)

5.4 プラグインAPI

  • 124 47min
    • テーマ開発時にも使うとのこと
    • フックにはアクションとフィルターがあるよ
      • アクションは処理追加、フィルターはデータや処理の変更(値を返す)
      • add_action(), add_filter()
    • priority は小さいほど先に実行される int
  • 126 50min
    • save_post にフックすると、 2つの引数で呼ばれる、みたいなのがある
      • 投稿データID, 投稿データオブジェクト
    • add_filter( 'the_content', function(){ return str_replace( '。', ' (´Д`)。', $content ); } );

    • のように、第一引数のフックに、第2引数の 関数を追加する
      • フックごとに引数の名前が決まってるのかな?
    • フックの例の表,
  • 128 53min
  • 130 17min 2021/08/10 21:40 今日は 17分かけて、勉強の進捗などをまとめていた
    • 実は /wp-includes/pluggable.php にある関数は開発者がオーバーライドできるよ
      • 別のシステムとの連携とかもできるね

5.5 ページの種類

  • 131 20min
    • 投稿データの一覧のことをアーカイブというらしい
    • 一覧と投稿詳細とフロントページ、検索結果、エラー、コメントポップアップ くらい
    • このどれかに割り振られます
    • サイトフロントページとブログメインページのち外
      • ブログメインページは、投稿データの一覧ページのことです

      • サイトフロントとして、一覧以外も出せるので違うということらしい
    • 特定の固定ページをブログメインページの内容(記事一覧)で上書く設定もあるよ 管理画面に

5.6 リクエストパラメータ

  • 134 25min
    • ここから処理の流れ
    • パラメータを解析して $wp->query_vars に入れる
    • $wp WPオブジェクトについての説明が書かれてる
    • 実行環境の構築→メイン処理→表示 の三段階とのこと
      • $wp は メイン処理の要とのこと,
    • $wp->main() がそのメイン処理らしい
    • かなり早期に http レスポンスヘッダを送信してるみたいだ(?)
  • 135 29min
    • wp-load.php を require すると、普通のPHPからWPの一部をつかえるらしい
  • 137 33min
    • このあたりで、クエリパラメータをどう処理して $wp->query_vars に保存するか詳しく書いてある
    • 管理画面の[設定]>[パーマリンク設定]でリライ ト機能をONにすると、例えばhttp://mydomain.jp/2016/09/post-slug/ とい った形式のURLを利用できます

    • リライトされたパラメータは、 $wp->perma_query_vars や $wp->extra_query_vars に入った後、結局 $wp->query_varsに入るとのこと
    • ここでのポイントは、入力値はフィルタリングされ、許可されたキーのみが、 $wp->query_vars 変数に保存されるということです。$wp->public_query_varsと$wp->private_query_varsは、それぞれ外部入力 と内部入力(プログラムからの指定値)をフィルタリングするためのホワイトリ ストです。ここに登録されているキーだけが受け付けられます

    • 大事そう
    • 新しいパラメータを追加したら、これらにも追加してね
      • register_post_type(), register_taxonomy(), $wp->add_query_var() , query_varsフィルターで追加できる
    • query_varsフィルターの例
    • add_filter( 'query_vars', function( $public_query_vars ) { $public_query_vars[] = 'my_search_option'; return $public_query_vars; } );

    • add_action( 'init', function() { global $wp; $wp->add_query_var('my_search_option'); } );

    • こんなふうに、init にフックして、 入れたい処理を入れる
  • 139 40min
    • $wp->parse_query() 関連の変数の表がここにある
    • デフォルトのリクエストパラメータの表がある
    • p が投稿ID みたいな
    • name が 投稿スラッグ 投稿に与えられた名前、みたいな
    • author で 作者の記事の一覧も出せるね
    • m で年月とか
    • 分別・アーカイブ、秒別アーカイブすらあるよ(すごい)
    • post_type 別もあるよ
    • s が検索キーワードみたいな
  • 141 44min
    • exact=1 で完全一致
    • sentence=1 で スペースを区切り文字にしない
    • orderby=author, order=ASC
    • cpage コメント一覧ページ番号
    • error は主に 404, 403, 500に対応
    • tb トラックバックリクエストフラグ
    • goods 投稿タイプを追加すると good=記事のスラッグ で詳細ページがでるよ

5.7 メインクエリ

  • 142 47min
    • メインとなるもののデータをDBから取得するぞ
    • 個々の処理は短いWP
    • WP_Query クラスをインスタンスにしたグローバル変数である $wp_the_query (開発者は使わない) と $wp_query がある
    • WPはリクエストから自動で主要なデータを取得するのだった
    • WP_Queryクラス
    • 特徴的なのは、検索条件を解析した結果がクエリフラグとして保持されるこ とです

    • このクエリフラグを調べることでいまのリクエストッどんな種類のページへのリクエストか判定するらしい
    • サブ情報の取得には get_posts() を使おうね (僕もつかってます)
  • 144 53min
    • メインクエリを中心としたWPのアーキテクチャを大事にしてプラグインを作ってね(メインクエリを無視してプラグインを作れもするけどやめてね)
    • $wp_query グローバル変数をみて、開発者はメインクエリを参照しましょう
    • $wp_the_query は $wp_query のバックアップみたいなもの。$wp_queryが変更されたら、これを使って元に戻すとのこと
    • query_posts('cat=5&order=DESC'); すると $wp_query は変更されるが wp_reset_query();で元通りになる、みたいな
  • 146 10min 2021/08/11 21:35
    • 今日は、10分間 JavaScriptの export の default って何なのか調べていた
    • WPはノンプログラマ向けに設計されたので(PHPっぽい) データや変数をなるべく隠蔽して、関数を露出しているとのこと
    • メインクエリを変更する色々な方法の表
    • メインクエリを変更できるフックが4つくらいあるんだね
    • クエリフラグを改変するフックやしないフックがある
  • 148 15min
    • WPにはRewriteAPIもあるよ (サーバソフトでやらなくてOK)
    • pre_get_posts アクション(フック)をつかったりすると、特定のクエリで 'author', '-4' にして4番ハブったりできるね -WP_Query クラスはメインクエリ以外でも使われるから $query->is_main_query() して判別
    • 管理画面かを返す is_admin() も大事とのこと
    • $query->is_category('cat-a') みたいなのもある
  • 150 20min
    • query_posts() は二回DB問い合わせすることになるから使わないようにしようね
      • メインクエリを書き換える動作も問題だぞ
    • get_posts() がナウい

5.8 クエリフラグ

  • 150 22min
    • いろんなクエリフラグがある
    • そのリクエストがどんなのか判別できる
    • front_pageと home (メインページ)は別なのだ (管理画面の設定でそれぞれ指定可能)
    • is_paged() 2ページめ以降かチェック関数
  • 152 24min

5.9 テンプレートの選択

  • 153 25min
    • テンプレートは詳細な順に存在確認され、 最初に見つかったものが利用される

    • カテゴリーのアーカイブページ(一覧ページの例)
    • category-{$slug}.php -> category-{$term_id}.php -> category.php -> archive.php -> index.php
      • これをWPでは テンプレート階層と呼ぶらしい
    • これにあった名前の.php をおけば、それが読み込まれるということね
    • うまく利用することで、ページの種類ごとのレ イアウト(HTML)を簡単に変更できます

    • なるほどね、最初は全部を index.php で処理してるけど、 category.php を作ると、カテゴリー一覧向けの専用処理をかけるのね
      • archive-goods.php を作ると、そのカスタム投稿タイプだけを出すページがかんたんに作れるとのこと,
    • body タグに、ページの種類を表すクラスがあるのでCSS適用も楽とのこと
  • 155 30min
    • なぜかコメントポップアップページだけは最終的に index.php が参照されることなく、必ず comment-popup.php が参照される(とのこと)
    • WPには テーマを継承してつくる 子テーマがある
      • やっぱブログシステムには色いろあるなぁ
    • 子テーマのファイルの方が親より優先して読み込まれるよ,
    • 3つのフックで、別のテンプレートを読ませることもできるよ
    • exitしたら、元々の表示をさせなくすんだりするよ

5.10 テンプレートタグとループ

  • 157 33min
    • そう、このメインループってのが謎の存在だったんだなぁ
    • get_header() ヘッダーテンプレートをロードする
    • おなじみの while ( have_posts() ) :
    • the_post(); で次の投稿になる
      • すると、 the_ID() でその投稿のIDを取れるようになったりする post_class() とか the_title() とか the_content() とか
    • うーん、独特の世界観なのだ
      • これがデータや変数を隠蔽して、全てが関数になった世界
    • get_template_part( 'content', 'none' ); // 部分テンプレートのロード - 地味に大事そう

  • 159 39 min
    • 単なるPHP関数であるので、理解しやすいと書かれてる テンプレートタグの概要
    • the_title() がテンプレートタグとのこと
    • よく見ると、全部 <?php the_title() ?> と php タグで囲んでるね
    • データ出力関数に the_ がつく世界観、 取得は get_the_title() みたいな感じ
      • 例外があるのがPHPらしい
      • 引数が基本無くて動くのがノンプログラマに優しいかも (と羽沢は思った)
    • is_archive() とかは 条件分岐タグとして使えるよ
    • has_tag() や in_cagtegory() もヨロシくね
    • インクルードタグ
    • 初見な概念
    • 他のテンプレをロードできるよ いいね
    • get_header() とかのことです
    • get_template_part() で任意のを読めるよ
    • get_template_part('content', get_post_format() ) とすることで、 content-image.php をロードできるとのこと,
  • 161 46min
    • みんな大好き get_posts() でのサブループ
    • $new_arrivals = get_posts( array( // ❶データの検索 'posts_per_page' => 10, 'post_type' => 'goods', ) );

    • わかりみが深い
    • setup_postdata ($post) でメインクエリのデータが入ってるのをウワ学のだと思う
    • wp_reset_postdata() でメインクエリのデータに復帰
  • 163 49min
    • WPはコンテキスト重視というか大事なのだ
    • WP_Query でもループできるよ
    • $result = new WP_Query( array( // ❶データの検索 'posts_per_page' => 10, 'post_type' => 'goods', ) );

    • みたいにやる
    • $result->the_post(); でコンテキストセットできる
    • the_post() も内部的に global $wp_query; をつかって、 $wp_query->the_post(); してるだけ
    • メインクエリ担当の $wp_query がある
  • 165 53min
    • setup_postdata() で 投稿データ一覧 get_posts() の結果をコンテキストにできるよ
    • echo esc_html($post->post_title) . '
      '; // 直接フィールドを参照する みたいな、直接フィーるどを参照する方法もある
    • フックとかサニタイズとかしてるので基本は the_title() を使おうね
    • ショートコードの処理を挟んだり。するよ

5.11 WPのソースコード

  • 166 57min -> 1min 2021/08/12 20:30
    • WordPressで本格的な開発を行うようになると、どうしてもコアのコード を読む必要に迫られることになると思います

    • WPのコードは汚いとのこと (グローバル変数たくさん)
    • API命名もわかりにくいとのこと 似たメソッド名も多いとのこと
    • 覚悟が必要とのこと
    • グローバル変数の表がある
    • 先に別の関数がコールされてからじゃないと正しく返さない関数があるらしい(うーんグローバル)
  • 168 6min
    • $is_iphone とかで デバイス判定できるよ
    • $posts もグローバル変数
    • すべてのフックが入ってる $wp_filter
    • グローバルだからといって、自分でも global $posts とかで呼び出さず、 フックを使おうね
      • 将来コア実装が変わった時に特に困るからね とのこと

第六章 テーマ作成、カスタマイズ

6.1 テーマの作成

  • 170 10min
    • 最小構成の例が書かれてる
    • テーマには index.php と style.css が最低要るぞ
    • style.css の先頭にテーマのメタ情報を書く (index.php はリクエストによっては通らないことがある)
    • WordPressのテーマを作成する際は、ライセンスに必ずGPLバージョン2 以上を適用してください。

    • 大したことをメタ情報に書いてないので、なくても動きそうな気がする。(テーマ名は要るかも)
    • index.php というファイル名だけど、実は HTML なので、 Hello World とかけばそう出力される
  • 172 15min
    • style.css 以外のファイルに cssを書いてもいいよ
    • コメントに何も書かなくてもstyle.css が存在するだけでテーマとして認識 されますが、Theme Name はテーマ名として管理画面に表示されますので、記述 するようにしましょう。

    • 疑問点に答えてくれる本
    • みんな大好き functions.php
    • 開発者がWordPressの挙動を変更したり、アプリケーションのための機能 を実装する際、必要なコードを記述できる唯一の場所がfunctions.php です

    • そんな唯一無二の存在だったのか…
  • 174 18min
    • テーマのルートディレクトリを表す定数は STYLESHEETPATH
      • 歴史的経緯を感じられていいね
    • ぜひとも処理を別 .php に書いて、 require_once しましょうとのこと (ぼくもしてます)
    • require_once get_template_directory() . '/inc/api-utils.php';

    • get_template_directory() するといけてる
    • require_once は if 分岐の中とか add_action に渡す無名関数の中でも使える

6.2 ビューの構成

  • 174
    • コントローラーがないWP (ビューだけっぽい)
    • 命名規則でどの種類のページか分けよう! ( category.php みたいな)
    • http://yourdomain/?cat=2 は category-2.php とか category.php に割り振られるよ なかったら結局はindex.php になるけどね
  • 176 24min
    • いろんなWPサイトに ?cat=2 でアクセスしてみよう!
    • 結構いい感じの get_template_part() 関数
    • get_header('hoge') は
    • ①header-hoge.php ②上記ファイルがなければ、header.php ③上記ファイルがなければ、wp-includes/theme-compat/header.php

    • を読むとのこと
    • こういう .php をテンプレートファイルと読んでいるみたい
    • the_post() で、メインループで取得したデータを取れるよ
    • ?m=201610 とかいいね
  • 178 29min
    • the_post()はイテレーター的に動く
    • テンプレートタグ(PHP関数)は4種類 インクルード系、コンテンツ系、タグ出力系、条件分岐タグ系
    • the_title() とかは the_post() を呼んだ後じゃないと呼べないよ
    • the_title() とかは出力までやるからecho はいらないとのこと

6.3 テーマに関連したAPI

  • 179 32min
    • ウィジェットやメニューとして作ったり、管理画面からテーマの調整をできるようにしたかったら、ウィジェットAPIやメニューAPI、テーマカスタマイズAPIを使おうね
    • ウィジェットは 外観 > ウィジェットにある (設定画面)
    • メニューは運営担当の人に操作してもらうのにとても便利(羽沢にも実績あり)
  • 181 35min
    • テーマの見た目カスタマイズは 外観>カスタマイズに設定画面がある

6.4 テーマ作成のアプローチ

  • 181
    • クラッチは最後の手段とのこと
    • 既存テーマのカスタマイズ(子テーマ作成)がオススメとのこと
    • クラッチも _s(アンダースコアズ)利用がいいとのこと
    • 子テーマだと、変えたいところだけオーバーライドできるよ
    • クラッチだと、大量にある機能に対応しないといけないのでよくないとのこと
      • クラッチと自作CMS作りは同じくらいの労力とのこと (自作CMSではWP知識がいらない)
    • 公式ディレクトリのテーマも直接はカスタマイズしないとよいとのこと
      • アップデートされるたびに変更箇所が消えるからとのこと
  • 183 40min
    • 直接でなく、子テーマとして、オーバーライドして使っていこう,
    • 親テーマの作者がセキュリティアップデートやバグ修正してくれるのでらくちん
    • Webサービスも子テーマとして作れちゃうかもね (とのこと)
    • 親テーマは保守が続きそうなものを選ぼう
      • デフォルトテーマだと安心そう(羽沢)
    • WP4.2 のデフォルトテーマは Twenty Fifteen
    • wp-ontent/themes に style.css をつくって コメントで Template: twentyfifteen と書けば子テーマができる
    • @import url(../twentyfifteen/style.css) とかけば 親のcssを引き継げる
  • 185 45min
    • 親が functions.php で if ( ! function_exists( 'function_name' ) ) と書いてくれてたらオーバーライドできる
    • フックは、priority を大きくしないと、親の後に実行されない(上書けない)
  • 187 48min
    • クラッチフレームワーク _s
    • WordPress.comを運営するAutomatticが提供し ているテーマ開発のためのフレームワーク

    • http://underscores.me/ でテーマひながたをgenerateしてくれる
    • _sを利用してテ ーマを作成した際にわかったと思いますが、単純なブログサイトを作成するだ けで合計16個のテンプレートファイルを作成する必要がありますので、多く の工数が必要になります。

6.5 テンプレートに利用する関数

  • 188 50min
    • タグはCodexでこのように分類されてるらしい
    • ・一般タグ ・投稿者タグ ・ブックマークタグ ・カテゴリータグ ・コメントタグ ・リンクタグ ・投稿タグ ・アイキャッチ画像タグ ・ナビゲーションメニュータグ ・リソース

  • 190 52min
    • comment_form() みたいな、comment_form用のhtmlタグを出力するタグ(php関数)もある
  • 192 54min,

6.6 作成したテーマのチェック

第七章プラグインを作って公開する

7.1 プラグイン作成

  • 196 2min
    • functions.php はテーマのものだよ
    • /wp-content/plugins/ に置かれた、例のヘッダーコメントが書かれたPHPプラグイン
    • 名前がかぶると、勝手にアップデートされたりするとのこと
    • プラグイン名だけでなく、関数名やクラス名もプレフィックスをつけたりしてユニークにしなかん
    • /wp-content/plugins/ には プラグイン名のディレクトリをつくるとのこと
    • プラグイン例「ぷんぷん嫁」(愛子ちゃん)
    • /wp-content/plugins/punpun-yome/punpun-yome.php 名前が異なると、国際化の処理などで少し面倒なことになります

  • 198 7min
    • 嫁が怒るらしい
    • Plugin Name は要るとのこと(例のヘッダーコメント)
    • このファイルは <?php で始まってるし、 PHPコメントで例のヘッダーコメントは書かれてる
    • 普通に add_filter とかしていくだけ
  • 200 9min
    • プラグインディレクトリに style.css を用意すると読み込んでくれるよ
    • ↓のようなコードがPHPの方にいる
    • add_action( 'wp_enqueue_scripts', function() { if ( is_admin() ) { return; } $cssurl = plugins_url('style.css', _ FILE _); wp_enqueue_style( 'punpun-yome', $cssurl ); } );

  • 202 11min
    • プラグインが有効化されたときや無効化された時の処理をかけるよ
    • register_activation_hook, register_deactivation_hook, register_uninstall_hook
    • 第一引数はそのファイル自身のフルパスなので FILE が便利
    • これでプラグイン作成のすべてです (かんたん)
    • プラグインAPIも使うといいとのこと

7.2 公式ディレクトリに登録

  • 203 15min
  • 205 19min
    • バナー画像は必須じゃないとのこと
    • 登録申請は zip にするよ そのzipをインターネットからアクセスデキンところに置く(自前みたい)
  • 207 20min
    • 審査があります
      • どのくらい難しいんだろう (問題がなければ通る?)
      • 一度チャレンジして、ダメだったらまぁいいかな感 (身内だけで使えばいいかな感)
      • というかテーマに含めてもいいしね
    • svn は最新が trunk だったなぁ
    • 最低、trunk にさえいれてればいいらしい で、 tag を 1.0.0で着ればいい
  • 209 24min

大八章 投稿データと関連エンティティ

8.1 データ構成の概要,

  • 212 26min
    • wp_postsテーブルのでーーたと関連データ
    • WordPressをプラットフォームとしてWeb サービスやWebアプリケーションの開発を行う際

    • WordPressAPIを通じて投稿データの一種として管理保存しよう!とのこと,
    • wp_posts テーブルの組み込みデータ型をショうかい
    • post, page, attachment, nav_menu_item, revision
    • wp_posts テーブルには、メディアファイルのメタ情報ならまだしも、メニュ ーの設定情報や編集履歴までもが保存されています

  • 213 30min
    • 投稿タイプとカスタムフィールドとたくそノミー(分類)が大事

8.2 投稿タイプ

  • 213 30min
    • 左カラムにカスタム投稿タイプが出ますね 管理保存の
    • 投稿タイプの主なAPI をご紹介
  • 215 32min
    • なんか register_post_type みたいなAPIだけど、どこで使うノカがきになる
    • 機能で投稿タイプをサポートするかAPIもある
    • 新しい投稿タイプを追加するには、プラグインAPI のアクションフックと register_post_type() 関数を使用して投稿タイプを登録します

    • そうか、初期化用PHPファイルとかはなくて、 すべてが functions.php なのだった
    • すべてをフックでやる世界観
    • add_action( 'init', function (){ register_post_type( 'products', array( 'labels' => array( 'name' => '商品',...

    • register_post_type() 関数は、init アクションで呼び出す必要があり、投稿 タイプを追加したあとに必ずパーマリンクを更新する必要がある点に注意して ください。

    • パーマネントリンクを更新…?
  • 217 35min
    • register_post_type() の引数を詳しく説明されてる
  • 219 36min
    •  投稿タイプ自体はとても単純な概念ですが、登録時のオプションの指定によ って、さまざまな性質を与えられます。これにより、少ない工数で幅広い用途 を実現する基礎となっています。

    • 'supports' => array( 'title', 'editor', 'thumbnail' )

8.3 カスタムフィールド

  • 220 36min
    • 値段を登録できるようになるもの
    • wp_postmeta テーブルに保存される
    • wp_postmeta.post_id
    • .key .value
    • key はぶつからないようにプレフィックスつけるといいとのこと
    • やはり register_meta を init フックで呼ぶ
    • add_meta_box() が管理保存でフォームを作るのに大事らしい
    • update_post_meta ($postmid, $meta_key, $meta_value, $prev_value) が大事そう
    • get_post_meta(996, 'product_price', true ) で価格が取れる感じ 最後のは $single 先頭のを返す
    • false だっっら 配列になる
  • 222 42min
    • 逆に、商品コードのように、1つのキーに対して複数の値を持つ場合(初回限 定版商品と通常版商品など)は、$unique をfalse にします。$unique の初期値は false ですので、$unique は指定しないようにします

    • add_post_meta() の説明
    • update_post_meta() では、 $prev_value を指定して、どの値っ上書きするか指定する
    • 複数あった場合は全部上書きするっぽい
  • 224 45min
    • なんとグローバル変数 $post にも入ってます
    • echo (int)$post->product_price . '円';
    • register_meta() 関数を使用し、キーをあらかじめ登録することで、保存時の 値のサニタイズや、権限のチェックをわかりやすくできます アクションフックのsave_post で、 値のサニタイズと保存を行う例が多いです egister_meta() 関数でカスタム フィールドを登録した場合、サニタイズと保存の処理を分けることができるため、ソースコードのメンテナンス性が向上します

    • register_meta() で、 その値が0以下だったら 0にするみたいな無名関数を登録できる
    • 11章で 管理画面で カスタムフィールドっ追加できるようにすんとのこと

8.4 タクソノミー

  • 225 49min
    • カスタムフィールドは検索、イチラン表示には不向きっぽい
    • わずか数行書くだけで管理画面含めた機能が作れるのは確かによい (ノーコードのはしり)
    • タクソノミーは投稿タイプに関連つける
  • 227 51mmn
    • 階層構造もあるよ
    • 組み込みタクソノミーでは、カテゴリーが階層型だよ
    • wp_terms(用語正規化), wp_term_taxonomy(分類項目), wp_term_reltionships(投稿データと分類項目の関連付け) でできているタクソノミー
    • 投稿データ向け外部キーは object_id だけど、これはwp_links テーブルへの関連付けもサポートしていたからとのこと
  • 229 56min
    • いつもどおり init フックに対して add_action で register_taxonomy する
  • 230 58min
  • 231 2021/08/14 23:58 1min

8.5 コメント

  • 232 2min
    • wp_comments テーブル
    • コメント機能 は、個々の投稿データに関連した、別の小さなデータの集合を扱うのに便利で す

    • コメントの承認や、特定ユーザのみコメント可能とかあるとのこと ブラックリストととかも
    • モデレーション=事前検閲 (他者からの評価という意味も言葉自体にはある)
    • アバター機能もるよ 連続投稿規制用APIあり
    • SPAM対策プラグインもあるぜよ
    • check_comment() WPの内部チェックをしてもらえる
    • ここにあるコメントAPIを使ったら、自動で返信したりもできるね (羽沢)
    • ピンバック リンク先に貼られたことを通知する
  • 235 7min
    • WP_Comment_Query クラスが活躍しているとのこと
    • ここで色々いじっても、コメントを色々首都くしたりできる
  • 237 9min
    • コメント版カスタムフィールド
    • wp_commentmeta テーブル
    • やはりkeyvalueストア
    • ユーザからの商品レビュー機能とかが作れるよ
    • インターフェイスは 投稿向けカスタムフィールドと同じ
    • comment_form_default_fields フックに レーティングを選択するためのhtmlを出力する無名関数をかいてる
  • 240 12min
    • comment_post フックに、レーティング情報が送られてきた時の処理を追加しましょょね
    • add_comment_meta() している
  • 242 14min

第九章 投稿データの検索と取得

9.1 WP_Query (心臓部)

  • 244 14min
    • サブループでは get_posts() (僕にもおなじみ)の方がナウいし安全
    • でもコアな開発者にはWP_Queryが大事とのこと
    • WP_Query は 4000ギょウ
    • くえりフラグも保持します
    • そこら中にある global $wp_query; が肝
  • 246 17min
    • クエリビルダがWP_Query の中心的機能とのこと
    •  WP_Query クラスは、一般的なフレームワークにおけるクエリビルダとは異な り、クエリビルディングのためのメソッドを特に持ち合わせていません。SQL 文の組み立ては、WP_Query::get_posts() メソッドの中で、条件分岐でがんば って行われています どうしてもSQL文を直接改変したい場 合は、WP_Query::get_posts() メソッドの途中でフックを使って介入すること が可能です

    • WP_Query 頑張ってる
    • 現在はSQLでは投稿IDのみ取得 し、投稿IDをWP_Post オブジェクトにマッピングするようになりました (省略可能)

    • キャッシュがあるのでリソース節約になってるとのこと
    • WordPressでは、アクティブレコードやDAOのような仕組みを持ち合わせて いないため、投稿データの保存や更新の際は依然として、配列を関数に渡すと いうスタイルを採用しています。

    • WP4.4 くらいから 全部 stdClass ではなく、WP_Term クラスとかにオブジェクトマッピングされるようになった とのこと
  • 248 22min
    • 、次の投稿を取得 するのみでグローバル変数を変更しないWP_Query::next_post() カレント をリセットするWP_Query::rewind_posts() メソッド

    • $query = new WP_Query( array( 'ignore_sticky_posts' => 1 ) ); で、先頭固定投稿(スティッキー)の取得をスキップできるとのこと

9.2 基本的な使い方

  • 248 24min
    • $the_query = new WP_Query( $args ); newスル時に、どんな投稿を取るのか $args で渡される WP_Query さん
  • 250 25min

9.3 パラメーター

  • 251 26min
    • Codex (公式ドキュメント)はいいぞ
    • 'author__in' => [1,2] とかで複数のin できる, (IDだけっぽい。 name には 少なくともこの時点ではなさそう)
  • 253 28min
    • tagand とか tagin とかある tagnot_in とか tag_slugand/in なぜかtagには name 相当のものがあるな…
    • タクソノミーようには Wp_Tax_Query がある
    • リスト9.16 は、Jason Statham(ジェイソン・ステイサム)が出演している2016年または2015年の 映画の情報を取得している例です。

    • うーん、たしかにこういう引き方ができるなら、Webサービスとして使えるかも
  • 255 32min
    • WP_Query ではいろんなパラメータで検索できるのだ の表
    • 投稿をパスワードで保護することもできる
  • 258 33mmn
  • 261 33min
  • 264 34min
    • 検索に使えるパラメータをとても詳しく説明されてる
  • 267 35min
  • 270 35min
    • WP_Meta_Query とか、データごとにこういうクラスがあって、配列で引く条件を指定できるよ
    • ページングに関する検索オプションもあります
  • 273 36min
    • fields に 'id=>parent' を指定すると、 投稿idをキーにして、中身を 親投稿IDをとれる
    • WP_Query より かんたんな get_posts() の説明
    • 使えるパラメータは WP_Query と同じ
    • suppress_filters をtrue にすると、中のフックが発動しなくなる
    • no_found_rows(ページングには使う。すべて件数)をtrueにするとはやい
  • 276 40min
    • get_posts() には setup_postdata() を使おうね そのままこの関数を呼べばいい(何かのオブジェクトのメソッドではない)
    • 一部テンプレートタグが globalの $poot を参照している。このため、著者さんはget_posts() は使わない方がよい と思っておられる

9.4 その他のプロパティとメソッド

  • 277 43min
    • global $query_vars にすべてのクエリ変数が入ってる
    • $query->get('post_status') みたいな
    • is_archive() みたいな関数の説明の表
  • 280 45min
    • is_page() 固定ページかどうか判定
    • the_posts_pagination() でかんたんにページ送りナビゲーションを追加できる
    • pagenate_links () かも
    • ページ送りの例がココニアる
  • 282 47min
    • クエリ文脈に応じたオブジェクトをエられる get_queried_object() がある とのこと
    • カテゴリの一覧ページだったら WP_Term オブジェクトがエられる
    • 引数がいらないので使いこなせば楽かも (便利関数) (羽沢の感想)

9.5 メインクエリ中のWP_Query に対して行える操作

  • 285 49min
    • pre_get_posts アクションとかで、メインクエリがDB操作(取得)する前に介入ュ仕様
    • 特定のカテゴリを抜くとか
    • アーカイブの種類によって、表示数を返るコードもここにある(管理画面では全アーカイブで今日買うの件数になってしまうらしい)

9.6 クエリビルディングへの介入

  • 287 52min
    • フィルターフックでやる
    • posts_join フックに多々して add_filter すると… $join に JOIN クが入って来るので、 $join .= でくっつけたいSQL クをつける
    • posts_where もある posts_search を使うと キーワードサーチの時のwhere の一部がわたされる
  • 290 54min
    • posts_limit とかもある distinct とか order や groupbyも select用の fields も
    • posts_requestフィルターでは、SQL分全体が渡されてんこうできる最終手段 SQL分各ににもtukaeる(が、プラグインでいい気がする)
    • global $debug_request; を宣言して、それを表示させてる (global 変数の出番が多い)
    • wp-includes/query.php をみると、WP_Queryのことが完全にわかるとのこと (292 , 58min)

大十章 ユーザーと権限

10.1 仕組み

  • 294 2min
    • wp_users テーブルと wp_usermetaテーブルと wp_options テーブル
    • 名前とかだいたいのものはwp_usermeta に入ってる
    • wp_options に権限グループ情報が入ってる
    • ユーザ操作欠かすうやクラスがあるよ
    • 権限グループに権限をつける他に、ユーザに直接権限をつける(wp_usermeta 管轄)ことも可能なのだ
    • もちろんグループがオススメとのこと
    • みんな大好き unserialize()
    • administrator, editor, author, contributor(寄稿者), subscriber がデフォルトである
    • 式日本語ドキュメントは普及にやくだつね

10.2 ユーザ操作api

  • 297 7min
    • $user = new WP_User(2); $firstName = $user->get('first_name'); $email = $user->get('user_email'); $current_user = wp_get_current_user();

    • かんたんなコード
    • WP_User_Query を使いこなすとユーザを検索できる
    • GenerateWP というプラグインも検索というかクエリ生成がかんたんとのこと

10.3 ロールや権限の開花カスタマイズ

  • 298 9min
  • 301 11min
    • いままでと同じ漢字でユーザを操作してる

10.4 権限のチェック手法i

  • 302 12min
    • current_user_can($capability)
    • マルチサイトの場合は、current_user_can_for_blog($blog_ id, $capability) 関数を利用します WP_Roles クラスやWP_User クラスと同様 に、ソースコードはwp-includes/capabilities.php にあります。

    • そこに入ってるのね
    • $currentUser->has_cap('kengen_name')

第十一生 管理画面のカスタマイズ

11.1 メニュー

  • 306 15min
    • リッチな管理画面がついてくるのがWPのいいところ(とのこと)
    • クライアント、ユーザからの要望がメニューには多いとのこと
    • 追加関数があるので admin_menu フックに add_action しよう
    • この追加関数の中にhtml 書いてるけど、複雑なものを作れるのかな この後に書いて有りそう
    • コールバック関数または メソッドを別途用意したほうが良いかもしれません

  • 309 18min
    • 特定のメニュー を隠すカスタマイズも、追加同様に要望が多い項目です。

    • メニューから隠すことができる (URL知ってたらアクセスできるけど)
  • 312 20min
    • サブメニューは、現在ヒョょじしているページごとに $submenu_slugが異なるので、 $_SERVER['REQUeST_URI'] から生成しないといけないらしい

11.2 Settings API 独自設定画面を作成

  • 315 22min
    • データベースのデータをサワれるように鳴るらしい? iアノ?
    • セクションという謎概念が登場
    • add_options_page () で追加mfk iM設定画面を追加
    • 任意の値 ここでは サンプル設定1 へテキストを追加できるようになってる

11.3 投稿データ一覧ページに独自項目をついか

  • 318 25min
    • サムネ追加とか更新日時ソートとかができる (現在のバージョンでは更新日時ソートはデフォルトでできる気がする)
    • フックで追加しましょう
    • ソート処理も追加できるとのこと

11.4 カスタムフィールドの入力フォーム作り

  • 320 27min
    • カスタムフィールドの追加編集フォームを自動で追加してくれるWP
    • プログラマブルなアプローチとの親和性はこれではほとんどないとのこと
    • プラグインが一番
    • 海外でも人気のToolset Typesプラグインを紹介しています。Toolset Types以外にもSmart Custom Fields注2や、Advanced Custom Fields注3 が人気があり、

    • 入力値チェックとかがないのがプログラマブルなアプローチとの相性が悪いとのこと
    • やはりフックに色々書けばできる
    • is_admin や admin_init アクションでは current_user_can() や check_admin_referer が大事だったり、 Ajaxには wp-admin/admin-ajax.php をエンドポイントにするのが大事とのこと、

第十二章 その他機能やAPI

12.1 wpdb クラス データアクセスDAO

  • 326 33min,
    • 基本はAPIを使おう とのこと
    • global $wpdb を使ってるよ
    • prefixを使って独自テーブル名をつくろう > $actual_my_table_name = $wpdb->prefix . 'my_table_name';
  • 329 37min
    • $wpdb->queries に実行したSQLが保存されるとのこと
    • $wpdb->prepare で安全に値を入れたりできるとのこと
    • insert, replace, update, delete という便利メソッドもあるよ ユーティリティメソッド
  • 332 39min
    • ALTER 分を作ってくれる dbDelta()
    • それを使った マイグレートプログラムが書かれてる
  • 335 42min

12.2 バリデーション・ナンス・サニタイズ

  • 336 43min
    • ナンスは聞いたことしかないかも (どういうことかわからない)
    • バリデーションから
    • 基本バリデーションはないWP サニタイズは豊富とのこと
    • (公式、コアですら) WordPressの投稿画 面でバリデーションを実装することは難しいこと

    • プラグインでも JavaScriptでブロックして実現してるとのこと
    • ユーザIDとか メアドのバリデーションはあるらしい
    • 何個かバリデーション関数がある
    • WP_Error クラスにエラーを書くのうしよう
    • ここに、自分でそのクラスを使っっエラーを表示する方法がかかれてる
    • $errors にエラーがあったら自動で履くとかはなさそう
  • 339 47min
    • ナンス: リクエスト正当性 のための一意なトーク
    • クロスサイトリクエストフォージェリー対策のもの
    • これがないとPOSTを打たせられたら更新してしまうね
    • wp_nonce_field() でそのためのhtmlタグが出力されるっぽい wp_verify_nonce() で検証
    • $REQUEST['wpnonce'] に入ってる
    • check_admin_referer( 'my-action' ); で、リファラとナンスを両方検証するとのこと
    • サニタイズ
    • sanitize_text_fieldみたいな関数が何個かある
    • 投稿では wp_insert_post() 無いでサニタイズされてるらしい
    • APIでは抱いたいやってる
  • 342 53min
    • 出力時はWPは勝手にはサニタイズしない
    • 頻出 する echo esc_html (); WPの欠かすう関数
    • the_title() とかでは不要とのこと
    • フックもあるし、基本テンプレタグを使おうとのこと
    • esc_js()も大事とのこと これもWPの欠かすう関数 esc_html はすの,PHPにありそうだけどない
    • html 属性には esc_attr
    • 指定した要素と属性を残せる 他は消す wp_kses()
    • ホーカライズの翻訳ローカライズファイルも危険かも サニタイズすべし とのこと
    • esc_html_e( 'Hello World', 'text_domain' ); でサニタイズしながら翻訳できるとのこと
    • _x 版もあるとのこと 343まで 58min
  • 344 8min 2021/08/17 0:18 7分間はcFnのレビューの返事をしていた
    • $_GETとかにはWP龍マジッククォートされてるから注意とのこと
    • stripslashes() クォートをとり除く

12.3 オプションAPI

  • 345 10min
    • wp_options テーブルに やはり key value で プログラムの設定を保存できるとのこと
    • add_option()
    • upsertはないっぽい
    • プラグインごとに接頭辞をつけるとぶつからなくていいとのこと

12.4 jsやcssの管理

  • 347 13mijn
    • これら用のAPIがあるとのこと
    • jsの依存関係とか、複数のプラグインが同じjsをロードするのを解消できるイケてる手段
    • wp_enqueue_scripts フックで wp_enqueue_script を呼ぶ感じ
    • 依存関係を第三引数で指定できる 先に 'jquery' を呼ぶみたいになる
    • バージョン番号をクエリパラメータとして出力する機能も搭載
    • 第語引数trueキと html 待つでscript 出力される
    • 登録だけ wp_register_script() でやって、皮下用になったら wp_enqueue_script() で出力させることもできる とのこと
  • 350 18min
    • wp_localize_script() でPHP変数をjsのオブジェクトに変換してページに埋め込み (便利)
    • WPでは元から jQuery{,UI}, underscore, backbone が読み込まれています (WP本体で利用)
    • それを読み込み停止もAPIでできるとのこよ
    • if (!is_admin()) で、フロント再度だけで処理をするのは頻出 iだね
    • CSSにも同じ用にAPIがあるとのこと
  • 353 23min
    • $media 引数で、どのmediaのときだけ出すか指定できるとのこと
    • CSSでもwp_enqueue_scriptsにフックします。

12.5 キャッシュ

  • 354 24min,
    • Object Cache API (インメモリ、単一リクエストで有効)
    • Transients API (DBにストア、有効期間内で有効)
    • の2つがある
    • Object Cache API
    • /wp-includes/cache.php にて実装されてる
    • wp_cache_set/add/get で key value ストアとして使う
    • $group 引数があるので、プレフィックスをつけなくていいね
    • serialize せずに変数をそのまま保存できるっぽい
    • /wp-includes/object-cache.php を 作ると、Object Cache API を乗っ取れるので、 memcachedとかにできるとのこと
    • Transients API
    • 中身的には オプションAPIを使ってるらしい
    • set/get_transient() という感じ やはり key value ストア
    • こっちは $group引数がないのでプレフィックスとかがいる
    • set_site_transient() だと、マルチサイトでも共通のが作れる とのこと

12.6 ショートコード (動的出力)

  • 357 31min
    • この「ショートコード」を知らないことも、WPをもっと知ろうとおもったきっかけなのだった
    • ショートコードとは、投稿中にユーザが書くと動的出力をエられるコード
    • add_shortcode() で 追加できる
    • デフォルトは WordPressショートコード超詳細ガイド(自作例も紹介) にあるものかな? 少ないかも?
    • 公式を見ても ショートコード API - WordPress Codex 日本語版 その六種類だった
    • ショートコードでは、投稿本文中の任意の範囲を囲み、その囲まれた範囲の 文字列に対して処理を行うこともできます

12.7 ウィジェット 36min

12.8 マルチサイト

  • 365 42min
    • ネットワークサイトともいうとのこと マルチサイト化のことをネットワーク設置ともいうみたい
    • define('WP_ALLOW_MULTISITE', true); が設定開始のための設定とのこと
    • 管理画面 ツール > ネットワークの設置で設置できるみたい
  • 368 45min
  • 371 47min
    • wp_get_sites() とか switch_to_blog() とかで、複数サイトを渡り歩ける
    • restore_current_blog() で戻れる
    • 用語が入り乱れてるので頑張って という感じ
    • マルチサイト未対応のプラグインもあるとのこと, 癖強いとのこよ

12.9 WP REST API

  • 372 49min,
    • REST まであるよ
    • XMLよりJSONの方が取り扱いやすいね (さらに未来だとymlがかんたん)
    • http://example.com/wp-json/wp/v2/posts で新着が取れたりする
    • getはいいけど 更新とかちゃんと閉じられるのかな(羽沢)
    • http://example.com/wp-json/wp/v2/users でユーザ名がとれる 塞ごう
    • POST /wp-json/wp/v2/posts とか DELETE /wp-json/wp/v2/posts/1 もあるようだ
      • 勝手に人のサイトを更新するのは犯罪(だと思う)
      • この後にデフォルトで塞がってるか書かれてるかな?
    • Chromeアプリの PostmanがREST API 操作にオススメとのこと 375 はで 57分
  • 375 2021/08/17 21:14 1min 今日終わるでしょう
    • WPのユーザ権限通りの操作がREST API でできるとのこと
      • ユーザをみるだけだったら非ログインでも全員できるのは変な気もするけど。。
    • Cookie認証、OAuth1.0a認証、Basic認証があるとのこと,
    • Cookie認証が、管理画面にログインしたブラウザからは通るヤツだね
    • ログインだけですべての操作がAPIから行えると、CSRF脆弱性 が発生しますので、APIへのアクセス時には専用のトークンを生成する必要が あります。

    • OAuth が標準的,
    • BASIC認証は平文だから危険だよ とのこと
    • determine_current_user でプラグイン独自の認証が作れるとのこと
    • リソースは posts, pages, media, post_meta, post_revisions, comments, taxonomies, terms, users, post_types, post_statuses とのこと
    • フロントサイトでエられない情報は users だけかな
    • rest_api_init, register_rest route で君だけの REST API をつくろう
  • 378 9min
    • users の塞ぎ方はこの本には載ってなかった

12.10 国際化

  • 378 11min,
    • gettext ライブラリと wordpress-i18n tools を使うとのこと
    • gettext 構文で書こう
    • .pot テンプレートファイルを自動で作ってくれるらしい (?)
    • これから .po が作れラルらしい
    • それをコンパイルして .mo ができて アプリケーションに組み込まれるらしい
    • XCode と Homebrewで試してみよう
    • タイトル: を <?php _e( 'Title:', 'mytextdomain' ) ?> と書く (これだと長いけど短くもかけるようになってそうな予感がする)
  • 381 16min
    • _n() フクイ右傾
    • _I() とかプレフィックスつけたときは先頭大文字にすればいいのかな (自分でローカライズシステム作るときには,)
    • コンテキストというものがあるらしい x
    • esc_attr() や esc_html と合体したメソッドもあるよ
    • 遅延評価の _noop ュあるよ
    • ('リーダー', 役職) とか ('リーダー', 電子書籍) みたいな感じのがコンテキストかな?
    • 元の(第一引数の)文字列が同じでも、プラグインやテーマによって約語が違うから、テキストドメインがいるのね
    • makepot.php とかを実行してコンパイルしていく
  • 384 21min
    • 最終的にはload_plugin_textdomain() で読み込む

12.11 自動アップデート

  • 386 22min
    • 自動更新設定してると、自動で更新されるらしい
    • デフォルトでは 1.2.3 の一番小さいところだけ(マイナーバージョン)だけ自動であがる みたい
    • 自動アップデート時に wp はメールで教えてくれるとのこと

12.12 メールの送信

  • 388 25min
    • PHP の mainl() ににた wp_mail() があるとのこと
    • この後は索引(391-396) 著者紹介 (5名の共著) 30min

所要時間

  • 1日め: 2021/08/06 21:08.
    • はじめに~1章 概要
    • 23分で 33ページまできた(0.7分/page)
    • 全体は290分 = 5時間で終わる!?
    • 今日は目次が多かったからね
  • 2日め: 2021/08/07 21:37
    • 1章~ 2章 用意 参照 資本機能 四章 プラグインを使おう
    • 55分で 34-72 39ページ 1.4min / page
    • 全体は 588分かな 10時間弱 あと8.5時間か?i
    • 開発なしで部屋予約システムが作れる、ノーコードの先駆けという視点はすごかった
  • 三日目 : 2021/08/08 22:30
  • 四日目 2021/08/09 21:22
    • 5章基本アーキテクチャ
    • WPの処理の話に入って面白かった
    • 56分で 148まですすんだ 37ページ (1.5min/page)
    • のこり 269ページ。 403分 (=6.7時間) 途中で別のことするけど、あと 7日。
  • 5日め 2021/08/10 23:03
    • 5章基本アーキテクチャ。処理の流れになっててちょっと楽しい
    • 40分。その前に17分で勉強時間などまとめていた
    • 130-145 40ページで16ページかな。 おそい 内容難しくなったのかもね
    • のこり 253ページ。
  • 6日目 2021/08/11 22:23
    • ノンプログラマのためにデータや変数を隠蔽するために、全てを関数にした独特の世界の解説を読めて面白かった
    • 146- 166 21ページかな。50分で。
    • 0,muicちょっと時間かかるようになってきたね
    • 5章基本アーキテクチャがだいたいおわり
  • 7日目 2021/08/12 21:55
    • 58分で 167-194 28ページ
    • 6章テーマ作り、カスタマイズがおわり
  • 8日目 2021/08/14 2:34
    • 195-230 56分 36ページ
    • 7章プラグイン作り 一番気になってたところだけどかんたんだっっ
    • 8章 投稿データと関連エンティティ 途中
  • 9日目 2021/08/15
    • 231-292 62ページ 57分
    • WP_Queryのパラメータダラケデ、読み飛ばせた
    • 9章 WP_Query
    • 正直、ここまで深いところは自分は使わないだろうな感があった。ので早めに読み飛ばした
    • 明日はユーザと権限で、面白そうかも
  • 10 日目 2021/08/16 0:48
    • このくらいコアなことになると、自分は扱わないだろうからいいかなって感じで早めに読み飛ばした
    • 293 -343 51ページ 56分
    • 明日ギリギリ終わらないくらいかな
    • 10章 ユーザ周り、 11章 管理画面、 12章 その他
  • 11日め 2021/08/17 2:13
    • 343 - 374 50フル 32ページ
    • REST APIエンドポイントは面白かった
    • 12章色々な機能
    • 明日終わるといいな。
  • 12日め 2021/08/17 22:07
    • 30分で最後まで読んだ

所要時間まとめ(最後に)

ファイナル感想

  • まぁ、ブログサービスにはWordPressが機能やプラグインが充実しててNo.1だね 2021/08/07 21:22
  • やっぱり、WordPressはブログ投稿,表示に処理が特化してると思う 日時2021/08/09 21:20
  • 時間的には、当初の予想どおり10.5時間だった。標準的な時間のかかり方かなと思う
    • 417 / (10.5 * 60 ) の逆数で 1.51分/page

WordPressのMediaCloudプラグインをアップデートすると、S3との通信が詰まって困っていたが、解消バージョンが出ていた件

概要

詳細

MediaCloud の過去のバージョンで発生していた不具合

  • バージョンアップ後、15分経つと、Webサーバソフトのプロセスが、S3とのコネクションを終了させられていないプロセスだらけになって、1分経っても応答しない & リクエストを受け付けない状態になった

解消方法

  • MediaCloud は Media Cloud 4.2.0(2020/12/31版)で「Replace Urls」をオフにする設定 (WP管理画面のMediaCloud設定画面でオフにできる)を追加し、上記の問題に対応した

反省点

  • 2021/4に私は最新のバージョンでも不具合が発生したままか確認したが、その時に微妙に古いバージョン(2020/9/23版)を使って、見つけるのが2日遅れた
    • 本当の最新版を使って検証しよう
  • 上記の「詰まる」現象が起こるのは、本番環境にある画像の中でも一部の画像だけだったが、 私が 2020/8 に検証環境を作って負荷をかけてテストした時に、「本番環境から全記事データと全画像データを検証環境にコピー」…などはせず、適当に作った記事と自分でアップロードした2,3種類の画像を含む1つの記事に負荷をかけただけだったので、再現できなかった
    • 不具合が発生している環境と同じ環境を作り上げて検証しよう

この案件に関連して導入したもの

  • メンテナンスプラグイン
  • 画面上部に「何月何日にメンテナンスにつき閲覧できなくなります」告知を出す必要があったが、WordPressのメニュー機能を使って、そこに記事タイトルと、メンテナンス告知記事へのリンクを出した

学び

  • プラグイン開発が活発であれば、半年くらいで問題点は修正されそう
    • MediaCloudプラグインは、1ヶ月に1つほどバージョンリリースを行っており、開発は活発といえる。

もしなおってなかったとしたら

  • メールを出してプラグイン製作者に問い合わせをするつもりでした

所要時間

  • このブログを書くのに27分かかった。

キーモーメント・VideoObject構造化データを学ぶ

動機・目的

調査

かかった時間

  • このブログを 2021/08/02 1:10 に書き始めるまでに 7/29 に始めて、2時間45分かかった
  • その後、 2021/08/04 21:04 に ブログをかきあげて、追加で調べることを調べるまでに 90分かかった

こういう事をしていきたい

  • VideoObject 構造化データを入れて 動画検索結果に出す
    • WPの SEOプラグインで VideoObject 構造化データ出るか確認する
      • そういうプラグインはなかった
      • 元々 SEOのシステム部分を本で学ぶつもりでもあったので、まずは本を読んで、それから、埋め込みプレイヤーが記事中にあったら、そのVideoObject構造化データを入れる WordPress プラグインを作ろうと思う
    • (動画サイトマップもいいらしい)
    • (SeekToActionも入れられるといいかも)
  • そもそも Article 構造化データをつける

もし埋め込み動画プレイヤー用プラグインを作った時にしないといけないこと

  • 入れた結果を測定できるようにする
    • 運営の人に入れるよ~といえば?
    • WP管理画面でアクセスデータ(流入データ)を見れる?
  • 効果が出るようなら、他プロダクトにも広げる

読んだもの

いろんな構造化データ編

再び色々編

追加で調べたこと

業務のEC2をCloudFormationにするぞ2:ベストプラクティス勉強編

2021/07/15 21:41(11日め): 業務AWSのNW要素見落としないかチェック, 業務AWSのNWをテンプレ化開始

  • VPCのメニューをチェック中 (あとでEC2をやる)
  • AWSマネージドドメインリスト
  • Wavelength
    • VPCのSettingsにあった
    • 5G向けらしい
    • wavelengthについては、オプトアウトしているので、使わないようにしているのだろう
    • azは普通 a,c,d apnortheast-1の
  • (VPCは全部確認おわり)
  • EC2のメニューを見ていく
    • NW周りでは特に見てないものはなかった
  • (↑を20分でやった)
  • じゃあ、Elastic BeanstalkでNW周りが変更されないか一応みておこう
    • 初回以外は、NW周りについては、既に作ってあるものを再利用するようだ (EBの環境の設定をみた)
  • ◎いよいよテンプレ化開始した。
  • (35分で↓をした)
  • ☆10種類のものをcFnのテンプレにする対象として洗い出した
    • VPC, IGW, Subnet, Route Table, Managed Prefix List, NAT Gateway, Elastic IP, Network ACL, Security Group, S3用エンドポイント
  • VPCとIGWをテンプレにしてみた
  • サブネットを1つテンプレにした PubSubAPne1dForSSH

2021/07/18 5:00 (12日め): マクロを学ぶ必要があると分かった

  • (G検定の準備をしていたので2日ぶり)
  • 業務のAWSをcFnにしていってる
  • でも、そのままでは、同じことを何度も書くことになりそう
  • マクロを学ぼうと考えた

2021/07/18 14:38(13日め、14日め): cFnで使えるマクロ(というか同じ内容の繰り返し方法)を学ぶぞ, ベストプラクティスというか、使ってる人の記事を読むぞ

パラメータストア自体を知る

  • まずパラメータストアのことを知る必要があったので読む (21分)
    • Amazon EC2 Systems Managerでパラメーターストアを試してみた #reinvent | DevelopersIO
    • 2016年発表
    • 私物でやってみた(簡単)
    • Run Command で取れるということなので、やろうとした
      • デフォルトのコマンドがたくさんある Ansibleを流すとか configDockerとか
      • シェルスクリプトも実行できる(これがメインになりそう)
      • でも、起動してるEC2がないとダメだったのでやらなかった
        • 私物AWSで、自動で起動しているEC2を止めて回る定期ジョブをなんとかして搭載したい
        • AWSに、いかにも、そういう定期ジョブ登録機能がある気がしている。
    • (↑を5分で書いた)

パラメータストアを使って、cFnのテンプレの重複をなくす手法を学ぶ

その前に、まずはパラメータストアの普通の利用法を一応みておく

  • 次に、パラメータストアを使って、cFnの重複設定をDRYにする方法を知った (22分)

いよいよ、「cFnの重複をなくす方法」

  • 本題
    • [Tips]CloudFormationで文字列の繰り返しやめたいと思ったのでAWS Systems Manager パラメータストアに保存することを思いついた話 | DevelopersIO
      • これが、本来知りたかった、「cFnの重複部分をなくす方法」
        • もっと繰り返したいとか条件分岐をする必要があれば、AWS CDK等での対応も検討ください - AWS Cloud Development kit。 Pythonとかでかけるサービス。cFnより複雑

      • IAMRole2: Type: AWS::IAM::Role ManagedPolicyArns:

      • !Ref "IAMManagedPolicy2"
        • この部分は、 Role に この名前のpolicyをつけるよってこと
      • ssmに登録する体をとることで、何回も出てくる文字列を変数的に扱えるのだ
      • 気になる方はpoliciesを設定して有効期限を短くして削除してしまうことも可能かと思います

      • TagsのName に_for_cfn_template みたいな わかりやすい名前をつけてもいいかも。
      • 元のcFnテンプレよりだいぶよくなってる
    • (↑を8分で書いた)

cFnを実際に使われてる方のノウハウ記事を読む

  • 実際にcFnを使われてる方の記事を読んだ (23分)
    • というのも、ベストプラクティスというか、テンプレの良い書き方とかを知りたかったのだった
  • CloudFormation入門 - ハマリポイント・注意点 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
    • ☆かなりイケてる資料
    • ◎実はcFnもファイル分割できる(スタック1個に複数ファイルのテンプレ)とのことなので、やり方を調べたい
    • IAM, DBをスタック別にするのは確かに良さそう。でも、デメリットもあるので、最初は分割なしでいいかな。
    • なるほど、構文チェックツール
    • Subnet には EnableDnsHostnames: true EnableDnsSupport: true みたいなのが要るらしい
      • まぁ、実際に作ってみて、「むむ、ここが違うぞとなったら気付けるかな」
    • Condition も Mappingsも初めて聞いた (使えそう)
    • リソースの名前、英数字だけ(記号不可)と書かれててしっかりしてる。
    • Outputs もようやく意義がわかった (他のスタックにわたすものをOutputsとして出力する)
      •  必要最低限にしないとだめよ ロックされるから とのこと
      • 弊社のサービスではスタックに番号が振ってあり、小さい方から大きい方へのみ参照するようにしています。

      • ↑大変そう
    • 変更セットは「JSONの変更」 が一番くわしいらしい
    • ☆ > "replacement": "False", # これがtrueだとリソースが一度削除されて作り直されるのでサービスが停止する可能性あり
    • 弊社のAWS環境は小規模な方だと思いますが、それでもCFNのテンプレートは数千行に及んでいました。 今となっては、だからといって手動でひとつひとつ設定していくわけにも行きません。 - つよい - でもterraformでもそのくらいあった感じがする

    • (感想) やはり、CDKでは? cFnをマスターしたら素早くCDKに行こう!
  • (おさらい)CDKとは

テンプレを分割する手法を学んだ

  • 2種類の方針がある
    • 1つのスタックを複数のテンプレで記述(少数派)
      • だいたいCDKにしよう!という感じ
    • 役割でスタックを3,4つにわける (多数派)

1つのスタックを複数のテンプレで記述

複数のスタックを連携させる (クロススタック)

15日め 2021/07/19 21:07 : cFnのベストプラクティス調べ

  • 前日に引き続き、ベストプラクティスを学んでいる
  • CloudFormationの実践ベストプラクティス - Qiita (21分)
    • めちゃいい資料
      • (これを読むまで、テンプレをきれいに分割する方法が分からなかった…というか、「1スタックは1テンプレファイル」ということが繰り返し出てきたのだが…?)
    • この方も、現時点では CDK (Cloud Development Kit) 推し
      • 自分もcFnマスターしたら早急にCDKにいくぞ。
    • 「ライフサイクル」で分けよう の話
      • まぁ、今までに考えてきた、 NW → Security → DataDtore → App でも、後ろの方ほどライフサイクルが短くなってて、ちょうどよさそう  - 前のやつほど、全然更新されないので、依存関係的にもよさそう
        • そうかな?なんか、接続元IPが変わるので、 VPNを変えたい、とかなりそう
    • teamAとBのテンプレを分けておくと、変更しやすくてよいという話
    • 「タグのnameは気軽に変えられるもののままにしておこうね、クロスすタック参照にしたりしないようにしようね」
    • 「ネストされたスタック」
      • 普通に、他のテンプレをインポート的なことができる
      • しかも、Parameter を何にするかを親(呼び元)で指定できる
    • ☆ファイル構成もぜひこれを真似しよう
      • Layerがさっきまでカンガえてた nw, security, datastore, app かな?
      • (2021/08/26 19:31 追記) ただ、次回のブログで、「子スタックを持つスタックはインポートできない」(=インポートでは二段構成までしか作れない) ことが判明した
    • (↑を9分で書いた)
  • 私的CloudFormationベストプラクティス - Qiita (11分)
    • cFnテンプレのかなり詳細な例がある
    • 差分テンプレいい感じ(多分 web-office.yml のこと)
    • 依存しているスタックを書くのは行数(みやすさ)が見合ってないかも。
      • 書くならコメントでいいかも
    • ネストには2019/9/30当時には、「子の詳細な変更セットが見れない」という弱点があったとのことなので、いまでもそうか実験してみたい
    • 命名法も参考になった
    • (↑を5分で書いた)
    • これでベストプラクティスは一旦いいだろう!

今後の方針を考えた (cFnをマスターしたらCDKにいきたい)

  • どう考えても、将来的には、ちゃんと書けるCDKを使うのがよい
  • ただ、 CDK は cFn のラッパーなので、まずはcFnをマスターしたい

16日目 2021/07/20 20:48 : 今でもネストすると詳細な変更セットが見れないのか調査(2020/11に見れるようになったことを確認した), 変更セットの公式ドキュメント読んだ

変更セットの公式ドキュメント

  • 変更セットのサンプル - AWS CloudFormation (21分)
    • cFnが認識する変更には「テンプレの直接変更」と「パラメータ値の更新による変更」があるらしい (ChangeSource フィールド)
    • RequiresRecreation: インスタンスの置き換えが必要ないかを示す
    • replacement: AWS CloudFormationが新しいリソースを作成して古いものを削除する必要はないということを示す。falseなら 安心して実行できる。
      • ☆true だと危険!
    • (↑を4分で書いた)

ネストした子の詳細な変更セットが見れるようになった調査

  • その後、20分で、下の調査をした
  • ネストされたスタックの変更セット - AWS CloudFormation (10分)
    • 自信満々な「ネストされたスタックも変更セット見れる」というドキュメント
    • ただ、日付が書いてないので、2019/9時点での問題を解決したものか分からなかった(フィードバックを送った)
  • 変更セットの差分は、このリソースが変わるよ、ということしか分からないものだと理解した
    • (Drift (テンプレと実体の差分)では どの部分が違うかの差分が出る)
  • AWS CloudFormation 変更セットがネストされたスタックのサポートを開始
    • この資料により、上記のドキュメントは、2019/9時点の問題に対応したものだとわかった
    • つまり、現時点(2021/7)では、「ネスト機能」は有効に使えそうだと分かった
  • (上を3分で書いた)

17日目 2021/07/22 2:36: 学んだベストプラクティスを使って業務AWSのNWをcFnテンプレにし始めた

  • 52分で↓をした
  • テンプレの構成考えた
  • VPCと IGWをその構成でテンプレにした
  • 私物AWSでテストしようとしている
    • この時に、業務AWSで使おうとおもってたS3バケット名を使ってしまった
      • (世界でユニーク、一度も使われてない必要があるので、業務AWSで使えなくなった)
  • cFnでテンプレを読み込んで、デザイナーにきれいに表示された
    • 実際の実行はまた明日
  • (↑を4分で書いた)

18日目 2021/07/22 17:26: VSCodeでLintできるようになった

19日目 ベストプラクティスで作ったcFnテンプレでVPCとIGWを作った, SubnetをcFnテンプレにしてる

VPCとIGWを作れるか試す

  • ↓を32分でやった
  • VSCodeでcfn-lint できるようになったので、ベストプラクティスに則った形で VPCとIGWを作った
  • つまりポイント
    • Terapadyaml のコメントを日本語で書いた後に VSCodeにそれをもっていったら、 文字化けして、 cfn-lintは ファイルを読み込めません的なエラーを出した
      • そのコメントを消したら解消した
    • cfn-lint 的には UpdateReplacePolicy をつけるのが必須みたいなので、Retainでつけた
      • 更新のためにリソースを置き換えるときに、元のを残すかの設定
      • retainにしておくのが、料金かかるリスクはあるが安全 (最初は安全に倒すべし)
    • template url は、 s3:// ではダメで https:// じゃないと通らなかった
  • スタック作る時に 予想コストもでていいね (vpcとigwだけなら0円)
  • 作成できた
    • VPCとIGWだけでも1分半かかった
    • (↑までを6分で書いた)

Subnetをテンプレにする

      Tags:
        - Key: Name
          Value: !Join 
            ["-", [!Ref InternetAccessibility, "Subnet", !Ref AvailabilityZone, "routetable", "cfn"]]
  • のように、配列の一行記法を使って、見やすく書いた
    • ↑のブログを4分で書いた

20日目 2021/07/25 16:37: SubnetをcFnにした, 残すはSGだけになった

Subnet編

  • 18分で下をした
  • cFnテンプレを完成させて、私物AWSで流してみた
    • うまくできた
  • テンプレのS3パスが前回と同じでも、「既存テンプレを置き換える」を選択せねば、前回実行時のテンプレが使われてしまう (変更セットの作成)
  • ドリフト検出も、変更セット作成も、今回の「サブネット追加」くらいなら1分間くらいかかる
  • localへのrouteは書かなくても勝手に追加されてた
  • (↑を4分で書いた)

他のNW要素編

  • その後、下のことを30分でやった
  • よくみたら、1つのRouteTableを複数のSubnetで使ってたので、Subnetのテンプレから切り出した
  • managed prefix list は S3が勝手に作るものだからテンプレにしなくてよいと考えた
  • NAT Gateway は 今回 Private Subnet がないのでテンプレにしなくてよいと考えた
  • Elastic IP も、NAT GatewaySSHサーバをテンプレにする時にテンプレにすればいいと考えた
  • NACLも、私物AWSで試しに作ったスタックでは、勝手に全通しのNACLができていたので、別にテンプレに書く必要はないと確認した
  • S3エンドポイントも今回S3は対象外なのでいいや (多分S3を作る時にも勝手にできそう)
  • あとは VPC用、default のセキュリティグループだけになった

21日め 2021/07/26 20:58 : Security Group も今回はcFnに書かなくていいと確認した、チームに説明する資料を書いている

  • 49分で↓をした

Security Group 編

  • 事前の調査によると、今回は VPC用SGと default SG をcFnにすればよさそうだった
  • しかし、 VPC用SG は説明に VPC用と書かれているだけで、実際は EC2用SGだった
    • 今回は EC2 を作らないのでパス
  • default SG (default SGからのinを全通し、 outは全通し)は、私物AWSでcFn練習した時に、勝手に作られていた
  • このため、今回はSGをcFnに書かなくて良い、と判断した。

チームに説明する

  • 説明するため、社内ドキュメントに説明書きを書いていっている。

22日め 2021/07/27 22:03 : チームへの説明を書ききった, テンプレを仕上げ中

  • 58分
  • チームへの説明をかききった
  • テンプレを仕上げてる

23日目 2021/07/28 20:50: gitbucket にprを出して、説明の準備が完了した

  • 56分
  • 私物AWSで実行したらエラーが出たので直した
    • 「Parameters: [IgwId] do not exist in the template」というエラーがでていた
    • テンプレで使ってないパラメータを含めてるよ、というエラーだった(消して解決)
  • gitbucket にリポジトリを作ってprを出した
  • 説明ドキュメントを読み返して修正した

24日め 2021/08/05 21:37: Beanstalk は マルチAZ

Beanstalk は マルチAZ

時間まとめ2

  • 21日め 2021/07/26 20:58 63分
    • Security Group を今回はcFnにしなくて良いと確認した
    • チームに説明するドキュメントを書いてる
  • 22日め 2021/07/27 22:04 59分
    • チームへの説明をかききった
    • テンプレを仕上げてる
  • 23日め 59分 2021/07/28 20:52
    • prを出して、説明準備完了

業務のEC2をCloudFormationにするぞ1:勉強編

経緯

  • 業務のEC2 が IaCになってないのでしたい

選定

  • そのシステムはAWSべったりなどの理由でCloudFormationでもよいとなった(ざっくり)
    • GUIがあって初めて見る人もわかりやすそうというのもよい

時間的目論見

  • 結構大きいので15時間 (= 15日)で終わるといいなと思う
  • 2021/07/04 20:38(1日目) 開始

やること

  • まず、 AMI になってなかったらとっとく
  • CFについて知る
  • まずは私物AWS
    • GUIポチポチでさわってみる
    • IaCでやってみる
  • 本物をCF (IaC)にする

AMI編

  • 2021/07/04 20:43
  • EC2にいって、AMIのところを押しても何もなかったので、無い

    とり方

  • インスタンス一覧でチェック、右クリック、「イメージを作成」

    • No reboot を選んでおく(取得時に再起動しない)

CF知る編

自分のAWSで試してみる編

  • 【CloudFormation入門】5分と6行で始めるAWS CloudFormationテンプレートによるインフラ構築 | DevelopersIO
    • 入門1のVPCつくるところまでやった (この部分のまとめ書くのに3.5分かかった)
  • その後20分で、その入門3まで、つまり全部やった 2021/07/04 22:39
    • そこで、 下のまだできないポイントがうまれた
      • これで作ったVPC消してみたんだけど、復活はどうするんだろ
      • 生成に失敗したときの再挑戦方法まだわかってない
  • EC2を作りたいので、次の御手本を探した
  • その後、14分でこれを読み切り、このテンプレをコピペさせていただき、EC2をcreate_in_progressまでやった

2021/07/05 (2日め): EC2立てた。ドリフトわかった

  • まず32分で、下のことをした
    • MyIP に XXX.XXX.XXX.XXX ではなく XXX.XXX.XXX.XXX/24 を指定して、EC2を作り直した
    • ssh -i .ssh/2021-07-05_aws.pem ec2-user@52.XXX.XXX.XXX でログインした
      • AWSのキーペアには _awsって名前につけるとどこの鍵かわかりやすくてよい
    • このEC2スタックの作成は1分20秒、削除は1分30秒 かかるとわかった
    • スタックの初回生成に失敗した場合、「削除して最初からやりなおすしかなさそう」とわかった
    • スタックセットは「スタックを複数アカウントや複数地域で立ち上げるもの」だとわかった
    • (↑の記述を4分で書いた)
  • その後、20分で下のことをした
    • 「ドリフト」について調べた
      • (テンプレと実体との違い、ギャップのこと)
      • CloudFormation Drift Detectionを試してみた - Qiita
        • わかりやすかった
      • CloudFormation Drift Detection を使うことで、テンプレ更新前に、実体とテンプレの違いがわかると知れた
      • 手で消したVPCが、Drift Detectionで Deletedになるのを確認した
        • deleted の場合は、「テンプレとここが違うよ」差分は出ないようだ
      • スタックをupdateするには、やはり、テンプレートのどこかに変更がないといけなさそう
        • その際に、実体はテンプレの方に合わさせられる
          • (ので、実体の方を残したいなら、先にテンプレに反映させる)
        • テンプレート反映(update)前にはかならずこのDrift Detectionをチェックして、意図した変更だけになるか見よう
    • CloudFormationには結構知れてきたので、業務のSSHサーバに何があるかを書き出してみた(要件)
      • 確かに、EC2は中身がかなりでかいので、ファーストステップとしてはVPCとか周辺のものだけで、その後EC2に進むのがよさそう。
    • でも、「既存のリソースをCloudFormationにする方法」とかを知らないので勉強中

2021/07/06 21:06 (3日め): 既存リソースをcFnにするぞ

  • まず5分で AMIとった
  • つぎの17ふん(累計22分)で、上の「既存リソース組み込み公式」読んだ
    • 結局は、「手作業でテンプレに既存リソースを書けば、組み込める」ということ
  • このあと、私物AWSで、手創りVPCを組み込んで見ようと思う (3分でブログ書いた)
  • その後20分で、既存のVPCを取り込んでみた
    • AWSTemplateFormatVersion: "2010-09-09"
      Description: VPC Import test
      Resources:
      ImportedVpc:
      Type: AWS::EC2::VPC
      DeletionPolicy: Retain
      Properties: 
      CidrBlock: 10.0.0.0/17
      
      • インデントこわれた
    • 確かにコピーできた。
    • 上の書き方だと、 インポート時に VPC ID指定しないとだけど、 https://dev.classmethod.jp/articles/chonyumon-cloudformation/ "RouteTableId" : { "Ref" : "MyRouteTable" }, みたいに、テンプレートで指定も可能そう
    • 「変更セット」: cFn に変更したテンプレートを上げて、どれが変わるかみる機能。どのリソースかまでしかでないので、違いは テンプレートを読むしかなさそう。
    • なんか、元のvpcを取り込むじゃなくて、コピーしてる感じ
    • 10分たっても UPDATE_COMPLETE_CLEANUP_IN_PROGRESS]

2021/07/08 0:33(4日め): VPCを理解するぞ

  • (↓23分で以下のことをした)
  • VPCはcFnでインポートしても、コピーになるようだった
  • そもそも、VPCとかSecurityGroupを完全に理解してないので、はっきりと理解していくことにした
  • VPC
  • AWSのVPCって何?メリットや使えるシーンなど徹底解説! - TECH PLAY Magazine
  • CidrBlock: 10.0.0.0/16 という中に世界を作る感じ
    • 複数のVPCを作れば、複数 10.0.0.0/16 の世界を作れる (行き来できない世界になりそう)
  • SecurityGroupを VPCに所属させて、EC2をSecurityGroupに所属させる感じ
    • EC2を複数のSecurityGroupに所属させられるので、1台のEC2を複数のVPCに所属させられる
  • 可能な限りプライベートサブネットにしよう - > プライベートサブネットをパブリックにするには、後述するインターネットゲートウェイに接続する必要がある

  • ルーティングもあるよ(要るよ)
  • テナンシー: 他のリソースと物理リソースを共有するかしないか。デフォルトはdefault(普通に共有する)
  • …ということで、VPCの説明記事は一つ読んだので、実際の私物AWSVPCをみて、わからないところがないかチェック中
  • (↑を5分で書いた)

2021/07/08 21:20(5日め): Internet Gateway, NAT Gateway, Subnet, RouteTable を理解するぞ

  • (↓のことを27分でした)
  • 引き続き、 AWS CloudFormationでEC2を構築 - Qiita を完全に理解しようとしています
  • InternetGateway を理解した
  • EC2 にそのままだと、割り当てられるGlobal IP Address は非固定、Elastic IPで確保すると、固定のを割り当てられる…ことを思い出した
  • (↑を5分で書いた)
  • (その後、 18分で↓を理解した)
  • Subnet とは
    • サブネットとインターネット通信 | DevelopersIO
    • まぁ、普通のサブネット、 /18 とかで区切るやつです
    • パブリックは IGW があってインターネットと通信できる
    • プロテクトは、 NAT GW を通じて、 パブリックサブネットのIGW経由でインターネット通信ができる
      • インターネット側から始まる通信はできない
    • 踏み台サーバは英語で Bastion (砦の意)
    • プロテクトサブネットとは、 NATサーバや踏み台サーバ経由で、インターネットと通信できるサブネット
      • (Privateサブネットの一種と捉えられることが多そう。インターネットと通信できない真の Private Subnetより弱い版)
  • ルートテーブル
    • (ここまでで大体わかったので、AWS Console みて理解した)
    • VPCの設定項目
    • 送信先(ターゲットに振り分ける対象)とターゲット(流し込む相手)をきめる
    • ↑の EC2の御手本cFnテンプレでは、、PublicSubnet用のルートテーブルを作って、実際のルーティング(Route)を設定して、ルートテーブルをサブネットにassociateしてる
      • ルーティングで、全部の通信のTargetをIGWにすることで、インターネットへの/からの 通信を仕放題にしている (SecurityGroupで守る)

2021/07/09 20:16(6日目): Security Groupと Network ACLを理解するぞ、既存VPCをcFnに取り込むぞ

  • (↓まず、29分で下のことをした)
  • 引き継ぎ、https://qiita.com/tyoshitake/items/c5176c0ef4de8d7cf5d8 を完全に理解しようとしています(最後)
  • なぜネットワークACLでなくセキュリティグループで細かいトラフィック制御を行なうのか | DevelopersIO
    • 基本セキュリティグループとわかった
      • IPセグメントまるごと規制したいときくらいにしかNACLの出番はない(基本全通し)
    • セキュリティグループは基本通さない (必要なものについて穴を開ける)
      • inbound の 80, 22 だけでなく、 outboundの全通しも設定しましょうね
    • セキュリテぃグループIDとは
      • あるセキュリティグループがアタッチされているインスタンスをまとめて設定できる
  • (↑を5分で書いた)
  • (↓その後20分で↓のことをした)
  • 問題:「前、既存VPCを私物AWSのcFnに取り込めなかった」
  • 再度やってみたら取り込めた
    • 前回は VPCIDの指定を間違えたのかな?
  • CloudFormationで既存のVPCと既存のサブネットの中にEC2インスタンスを立ち上げてみる - Qiita を読んだ
    • どこをどう変更したのかといった変更履歴も保持しているので追跡性もあります。

    • ◎*cloudformerというのを使って既存のデータをコード化します - 変換機能(ただし、テンプレが手でメンテできなくなる)があるらしい (多分使わない)

    • Design Template というGUIがある
  • 私物VPCをcFnのスタックに取り込めたし、Tags の Name を着けることもできた (元々あったNameを上書いた)
  • ドリフトの差分もみれた (実物は/16 だけど テンプレは /17 みたいな)
  • でも、変更セットを作ってもドリフトの解決をできなかったので、明日はここから (ドリフト解決したい) (私物AWSの話)
    • その後、 業務SSHサーバ周りのNWを知って、cFn化を目論む
  • (↑を5分で書いた)

2021/07/10 12:43(7日目): ドリフト解消方法の理解を深めた, 業務のAWSのNW周りを理解中

  • (↓13分で↓をした)
  • VPCの /16と/17をcFnで変えられないなぁ
  • ドリフト解消方法を知るぞ!
  • AWS CDK/CloudFormation、リソースを変更せずにスタックドリフトを解消する | DevelopersIO を読む
  • cdkとは
  • データベースが絡む場合です。テンプレートを更新すると、インスタンスを再作成してしまいます - > 実施したシナリオ。。aurora mysqlクラスターをcdkで作成していた状態で、auroraの自動マイナーバージョンアップグレードが走ったために、スタックドリフトが発生した、というシナリオでスタックドリフトの解消を行ってみたいと思います。 - うーん、データベースに使うのは難しそうだ - retainにしてからコメントアウトして一度スタック管理外にしようね。すると、バージョンを実体に合わせられるよ - > これらのリソースはスタックから切り離したまま運用するという選択肢もあるかもしれません。

  • つまり、「全てをcFnで変更できるわけではない」
    • (/16と/17を切り替えるのは、IPセグメントがかぶっていて、一度切り離さないと無理、ということのようだ)
    • 一度スタックから外して、再度インポートすればよい
  • データベースの件で、cFn本当に大丈夫か気になったが、
    • 「cloudformation」でツイッター検索しても「CloudFormationはダメだ」みたいなのは見えない
    • というか、普通に運用に使われてそうだった
  • (↑を5分で書いた)
  • (↓その後、34分で↓をした)
  • AWS CodeCommit がgit だと理解した
  • cFnにすべく、業務のAWSのNW周りをみていってる
    • VPC, Internet Gateway, Subnet (EC2とRDSがどこにあるかも見た)
    • RouteTable 理解中
      • メインと private用がある
        • メインは、VPCのcidrだったらlocalに送るし
        • 他は igw
      • privateは VPCのcidrだったらlocalに送るし
        • ほかは nat gw
      • ここで、新キャラ: マネージドプレフィックスリスト が登場したので、明日はそれを知るところから。
  • cFnのスタックにインポートするだけなら、実体に変更は入らないから安全!
  • (↑ を3分で書いた)

2021/07/11 14:39(8日目) : Managed Prefix List, AWSのネットワークインターフェイスを理解

2021/07/13 20:55(9日目): 業務AWSのNetwork ACLを理解

  • NAT Gateway
    • 業務のNAT GW には、Private IPアドレスが割り当ててある
    • 最初からcFnで構築するなら、無指定で任意のを割り当ててもらっていいけど、今回はcFnのテンプレにこのPrivate アドレスを書いた方が無難そう
  • Elastic IP
    • NAT Gateway用 と SSHサーバ用 で 2つあるから、これもcFnにしよう
  • Network Access Control List
    • 業務AWSに1つだけある 4つ全てのサブネットと関連付け
      • インもアウトも全通しなよくある形
      • (subnetには、必ずNACLが割り当てられる)
    • 私物AWSをみると、cFnでは、特にNACLの作成を指定しなくても、(VPCやsubnetを作ると) 勝手に全通しで作られるようだ
      • それどころか、 VPCを作るだけの簡単なcFnテンプレでも、勝手にサブネットが4つ作られてるような…
      • /24で public a, private a, public c, private c で
    • 業務ACLの話に戻ると、NACLは、やはり、最初からcFnだったら、「NACLを無指定にしたら、勝手に全通しのができてた」で良いと思う
    • しかし、今回は既存のNACLがあるので、NACLもcFnのテンプレに含めた方が無難だと思う
    • その際には AWS CloudFormationでNACL設定を入れてみる | DevelopersIO を参考にするとよさそう。
      • subnetは4つしかないので、大して面倒ではない

2021/07/14 19:40(10日目): 業務のAWSのSecurity Group を理解, 見落としてるNW要素ないかチェック中(S3用エンドポイントがあった)

  • (↓25分で↓をやった)
  • 業務AWSのSGを理解
    • Security Group は、 SGの方の一覧からは、どのSGをどのインスタンスで使ってるかわからないので、「production RDS Security Group」みたいに、どこ用か、Nameか説明で示すのが大事
    • 業務AWSには、4環境ある
    • 業務AWSには、 VPC用 4、 LB用 4、RDS用 3 (stagingが productionと同じ)、SSHサーバ用 2 (gitbucket, office)、 default 1 の計14個のSGがあった
    • 全てのSGが、outbound は全通し
    • SSHサーバには、office IPサブネットから全ポート inbound OKとするSGがあった
    • defaultでは、defaultからのインバウンドは全部通すようになってた (内部通信はAll OK)
  • そのSGを使うインスタンスをcFnにする時に、一緒にSGもcFn管理にするのが良いと思った
    • つまり、 最初は SSHサーバ用2 と default を管理下にするのが良いと思った
  • (豆知識) EC2の一覧の実行中、停止中の横の +, - 虫眼鏡は、「同じstatusのインスタンスだけに絞り込む/同じstatusのインスタンスを一覧から抜く」ボタン
  • (↑ を 8分で書いた)
  • (↓を 17分でやった)
  • ↑までに書いたもので、cFnにする時どうするのか観点が抜けてるところがあったので書いた (MPLとか)
  • 他に見逃してるNW構成要素がないか、業務VPCの左メニューをチェック中
  • すると、エンドポイントというものが1個だけあった
  • (↑を5分で書いた)

時間まとめ

  • 2021/07/04 1日め 80分
    • AMIがまだとってないことはわかった
    • どう取るか調べた (簡単)
    • CFの概要を掴んだ
    • EC2を作成中のところまですすんだ
    • 業務のSSHサーバ移植まで、15時間もかからなさそう。
    • 明日は、EC2立てるのが、うまくいったか確認から。
  • 2021/07/05 2日め 62分
    • EC2を建てれた
    • EC2にsshできた
    • ドリフトとその検出方法、違いがある時の動作がわかった
    • sshサーバの機能を書き出した(要件)
    • 既存リソースをcFnにする方法勉強し始めた
    • 70分中、52分勉強し、18分 ブログ記述などをした 。 25%が記述の時間
  • 2021/07/06 3日め 50分
    • 既存リソースインポート方法学んだ
    • やってみた。コピーになるのはしかたないのかな…?(次回調べたい)
      • 既存スタックに取り込む、でも変わらないだろうけど…、コピーでも問題ないのかな…?
  • 2021/07/08 4日め 29分
  • 2021/7/8 5日め 58分
    • Internet Gateway, Subnet, RouteTable がわかった
    • あとは、 Security Group だけ
    • その後は、業務の踏み台周りのネットワーク部分をcFnにするにはどうするか、ということになりそう。
    • 多分、12時間ほどで ネットワーク周りは cFnになるんじゃないかな。 (ここまでを1つのものとしたい)
      • その先(sshサーバのcFn化)はさらに10時間かかりそう。(これを別の1つの実践としたい)
  • 2021/07/09 6日目 60分
    • Security Group, Network Access Control List を知った
    • 私物AWSで既存VPCをcFnのスタックに取り込み練習中
  • 2021/07/10 7日目 56分
    • 全てをcFnで変更できるわけではないと知った
    • 業務のNW周り理解中
  • 2021/07/12 2:23 8日目 53分
  • (2021/07/12 70分、 2021/07/13 25分)
    • 月イチの1on1ミーティングを受けるべく、準備をした
    • 勉強進捗、案件にかかった時間まとめ、期末の評価資料を少しずつ作っていく
  • 2021/07/13 20:32 32分 9日目
    • 業務のAWSのNetwork ACLをみて、どうcFnにするか考えた
  • 2021/07/14 20:13 56分 10日目
    • 業務AWSのSecurity Group 理解した。
    • 見落としてる業務AWSのNW要素ないかチェック中
      • S3用エンドポイントを見つけた。
  • 2021/07/15 23:07 64分 11日め
    • 他にはNW周りで見落としてるものがないことを確認した
    • VPC, IGW, Subnet 1つを cFnのテンプレにした
  • 2021/07/18 5:00 31分 12日め
    • マクロなど、繰り返しを避ける方法が必要そうだった
  • 2021/07/18 13,14日め 142分
    • cFnのテンプレを書くベストプラクティスを調べた
      • というかまだ調べ中
    • CDK (Cloud Development Kit) を推してる人が多かった
    • 自分も、cFnをある程度マスターしたら、すぐにCDKに行こうと思った
  • 2021/07/19 21:51 15日め 60分
    • cFnのベストプラクティスを学びきった
    • いまは、「ネストすると(テンプレ分割すると)、子の詳細な変更セットが見れなくなるよ」というやや古い情報が見つかったので、それを実験して確かめ中
      • ネストできないと、テンプレがとても長くなってかなりよくない
  • 2021/07/20 21:18 16日目 57分
    • 変更セットの見方を知った
    • 2020/11に変更が入り、ネストされたスタックの変更箇所も、変更セットで表示されるようになった事が確認できた
  • 2021/07/22 2:40 17日目 58分
    • ベストプラクティスに則って業務AWS NW周りをテンプレにし始めた
  • 2021/07/22 17:31 18日目 54分
    • VSCodeでcFnのLintできるようになった
  • 2021/07/25 3:48 19日目 80分
    • VPCとIGWをベストプラクティスで作れた(私物AWSで)
    • サブネットをベストプラクティスに則ったcFnにしてる
  • 2021/07/25 22:02 20日目 63分
    • サブネットをテンプレにした
    • あとはセキュリティグループだけになった

統計検定2級(CBT)を受けて合格した

経緯

  • 統計検定2級に合格すると、いいことがある

背景

  • 自分は統計系の研究室出身です
  • でも、2級で出てくる公式はほとんど使いませんでした
    • 大体1つの手法を多用するよね

合格までの軌跡

  • 過去問試し解き~受験まで12日間、17.5時間でした
    • ボーダー60点で73点獲得
  • 『統計検定2級 公式問題集 2017~2019年』の初見正答率は↓でした
    • 最後の回(6回目)は受験前日の最後に解いたので、これくらい解けてたら、合格できると思います
1回め 77.1%
2回め 68.9%
3回め 70.6%
4回め 55.9%
5回め 73.5%
6回目 68.6%

受かるコツ

  • 公式を覚えるのが大事です
    • 統計検定2級チートシート - Qiita
      • でもこの公式集は網羅しすぎていて、全部覚えたら100点取れると思います
      • 過去問を解いていると、どれが頻出公式かわかるので、それを重点的に覚えると良いと思います (このシートの半分くらい?)

この次

  • そろそろ(業務に直結する)Docker実践ガイドに戻りたい