Orpharion

Orpharion — See who reads your wp_options, then clean up safely

The wp_options table accumulates leftovers from plugins and themes that have been deactivated or deleted. Many of those rows are still autoload = yes, riding along on every page load. WordPress doesn’t ship with anything that tells you which rows are still in use, or which ones are safe to remove.

Orpharion is a GPL WordPress plugin that backs that decision with data.

Observe → Quarantine → Delete

Orpharion’s workflow is three stages. The point is to not delete blindly.

1. Observe — record who’s reading what

Orpharion dynamically registers option_{$name} filters and walks the live PHP backtrace to attribute each get_option() call to its real caller. It records last_read_at per row and per caller — not just per alloptions bulk-fetch — so you can answer “is this option still in use, and by whom?” at the row level.

2. Quarantine — rename and watch

For rows you’re not sure about, send them to Quarantine first. Orpharion renames the row with an _orpharion_q__ prefix; WordPress core and the plugin that owned it both stop seeing it. Orpharion keeps watching the original name during quarantine, so you can see whether anyone is still trying to read it. The expiry behavior (auto-restore / auto-delete / leave) is configurable per option.

3. Delete — only what you’re sure about

The Delete button is enabled only for rows that received zero reads during the quarantine window. If you want a safety copy, use Export selected to download a JSON file in your browser — Orpharion never writes option_value content to the server’s filesystem on your behalf, because option_value can hold API keys, SMTP credentials, and other secrets you don’t want leaked into your wp-content/ snapshots.

WordPress core options are protected on both the deletion and the import side. As of 1.0.3, every protected-option check (cleaner / importer / quarantine / options-list filter) is derived from a single ProtectedOptions helper, so you can’t sneak past the safeguards with case differences or trailing whitespace.

The same flow from WP-CLI

  • wp orpharion list --inactive-only --accessor-type=plugin
  • wp orpharion export --inactive-only --output=before-cleanup.json
  • wp orpharion clean --inactive-only --i-have-a-backup

clean requires an explicit --i-have-a-backup flag. As of 1.1.1, export --output= only accepts a bare *.json filename and writes into wp-content/uploads/orpharion/ — absolute paths, relative paths, and other extensions are rejected. The output directory is created on first use with index.html and .htaccess, so it isn’t browseable from outside.

Performance, on purpose

Tracking is not always on:

  • A 10-minute activation window opens when an admin loads the dashboard
  • The frontend is never touched
  • Reads are buffered in memory and flushed once per request at shutdown (a single upsert)
  • The sampling rate is configurable from 0% to 100%

You can leave it on in production without dragging on the request hot path.

Try it in your browser

Orpharion ships with a WordPress Playground blueprint. The link below boots a WordPress instance with Orpharion preinstalled, entirely in your browser (no install, session-only data).

Launch Orpharion in Playground

Source & license


Orpharion — wp_options を「誰が使っているか」で見える化し、安全に掃除する

WordPress の wp_options テーブルは、無効化・削除されたプラグインやテーマの設定行が残り続けがちです。多くは autoload = yes のまま毎リクエストの初期ペイロードに乗ります。標準の WordPress には「どの行が今も使われているのか」「安全に消せるのか」を判断する手段がありません。

Orpharion は、その判断を データ で支えるための GPL ライセンス WordPress プラグインです。

Observe → Quarantine → Delete

Orpharion のワークフローは 3 段階です。いきなり消さない ことに意味があります。

1. Observe — 誰が読んでいるかを記録する

option_{$name} フィルタを動的に登録し、get_option() が呼ばれたときに PHP のバックトレースから本当の呼び出し元 を特定します。alloptions(autoload まとめ読み)経由の参照ではなく、行ごと・呼び出し元ごとに last_read_at を残すので、「今も使われているか」「使っているのは誰か」を行単位で答えられます。

2. Quarantine — 隔離して様子を見る

判断に迷う行は、まず 隔離(Quarantine) に回します。Orpharion は対象行を _orpharion_q__ プレフィックス付きにリネームし、WordPress 本体や元のプラグインからは「無いもの」として振る舞わせます。隔離期間中も Orpharion はその名前へのアクセスを監視し続けるので、誰かがまだ読みに来ているか が後から分かります。期限到達時の挙動(自動復元 / 削除 / そのまま)はオプションごとに選べます。

3. Delete — 確信が持てたものだけ削除

隔離期間中にアクセスが一度も観測されなかった行に限って、削除ボタンが有効になります。万一に備える場合は、Export selected で JSON を ブラウザにダウンロード してから削除してください。Orpharion はサーバー側のファイルシステムには option_value を書き出しません(API キー・SMTP 認証情報など、wp-content/ のスナップショットに紛れ込ませたくない値が含まれることがあるためです)。

WordPress コアのオプションは、削除側でも インポート側でも 保護対象です。1.0.3 で各機能(cleaner / importer / quarantine / オプション一覧フィルタ)の保護判定を ProtectedOptions ヘルパに集約し、保護リストの単一のソースから派生させるようにしました。表記ゆれや末尾スペース付きの名前で保護をすり抜けるルートも塞いであります。

CLI で同じことを

  • wp orpharion list --inactive-only --accessor-type=plugin
  • wp orpharion export --inactive-only --output=before-cleanup.json
  • wp orpharion clean --inactive-only --i-have-a-backup

clean には明示的な --i-have-a-backup 確認フラグが必須です。1.1.1 以降、export --output=wp-content/uploads/orpharion/ 配下の *.json ファイル名のみ を受け付けます(絶対パス・相対パス・他拡張子は拒否)。出力ディレクトリは初回利用時に index.html.htaccess を同時生成するので、外部から URL で覗かれることもありません。

パフォーマンスへの配慮

監視は常時稼働ではありません。

  • 管理者がダッシュボードを開いた瞬間から 10 分ウィンドウ だけ有効
  • フロントエンドには干渉しない
  • 各リクエストの読み取りはメモリにバッファし、shutdown1 回の upsert にまとめる
  • サンプリングレートを 0〜100% で調整可

本番に乗せたままでも、ページ生成のホットパスを引きずらない設計です。

ブラウザでそのまま試す

WordPress Playground のブループリントを同梱しています。次のリンクからブラウザ内で Orpharion 入りの WordPress が起動します(インストール不要・データはセッション限定)。

Orpharion を Playground で起動する

ソース・ライセンス

WordCamp Kansai 2025 ふりかえり

2025年11月1日(土)〜2日(日)に開催された WordCamp Kansai 2025 に実行委員として参加しましたので、ふりかえり記事をここに残しておきたいと思います。

私の役割としては、委員長チーム・スポンサーチーム・会場/当日チームを担当しました。
また、自社株式会社Webの相談所はブロンズスポンサーとして参加しました。

今回の WordCamp はイベント全体を通して、関西の WordPress コミュニティらしさを感じられるいい WordCamp だったのではないかと思っています。

その証拠に開催から1週間が経過した今でも、X のハッシュタグ #wckansai2025 に「ふりかえりのブログ記事を投稿した!」というポストがあることは、実行委員としてとてもうれしいことです。(ふりかえりブログ記事一覧は公式サイトにもまとめられています。)

参加者のみなさんにお願いしたアンケートにも快くご回答いただき、満足の声を続々と寄せてもらって、安堵しています。本当にありがとうございます。

私はYouTubeにアップロードされたセッション動画をゆっくりと視聴しながら、停滞している仕事に追われる日々を過ごしています。

アフター・ドラマで日本初開催の WordCamp としてのふりかえり

WordCamp Kansai 2025 は WPDrama が起こった WordCamp US 2024 (2024/09/20)よりも前から企画が進められていました。

運悪く?このタイミングに当たってしまった WordCamp の実行委員としてはこの点にも触れておかないといけないという想い、そして日本国内で開催されるこれからのWordCamp のために私たちが何をしてきたのかを残しておきたいと思います。

この記事にたどり着いた人の中には、通称「WPDrama」をご存知でない人も多いと思うので、その場合は国内で最も信頼できる WordPress メディアの Capital P の記事をどうぞ。

会場予約・予算レビュー

「WordCamp を開催するぞ」という気持ちだけでは、WordCamp Central へ開催予定を掲載することはできず、金額の最も大きい会場の予約やイベント全体の予算計画の審査を経ていくことになりますが、ドラマ直後の最も混乱したタイミングと重なって、とても複雑な気持ちで進めたことをよく覚えています。

WordCamp の予算レビューを担当してくれる Automattic の担当の人には「グローバルスポンサーの費用をあまりあてにせず、ローカルでしっかりスポンサーを集めるように」と言われる中、WordCamp にはドラマの影響で様々な方針変更が加えられてくことになったのでした・・・。

参加者への変更点(2024/12/20あたり)

WordCamp の参加チケットを購入するには WordPress.org へのアカウント登録が必須となりました

この変更は一部の WordCamp 参加者への参加ハードルを引き上げ、主催者としては制限の多いWordCampサイトの中で、せめてもと注意文を掲載する対応を実施しました。

WordCampに参加するためにチケットを購入するにはWordPress.orgへのアカウント登録が必須となったせいでWordCampのチケット購入ページに掲載された注意文。「チケットの購入にはWordPress.orgのアカウントが必須となります。こちらのリンクより事前に作成をお願いします。」と記載されている
WordCampに参加するためにチケットを購入するにはWordPress.orgへのアカウント登録が必須となったせいでWordCampのチケット購入ページに掲載された注意文。

参加者としてチケット購入をしようと思ったら、WordPressのログイン画面が表示された時にどのように感じるでしょうか?

ある人は、ご自身の管理する WordPress のユーザーID・パスワードを入力してエラーになり、またある人は「なんでイベントに参加するためによく分からない WordPress にユーザー登録をしないといけないの?」と思ったことでしょう。
そして、パイナップルをピザに〜云々のチェックボックスの意味が分からずに離脱してしまった人もいるでしょう。

参加者アンケートにもその点について触れる声を寄せて頂いていますが、実行委員としては何も手を討つこともできず、「 WordCamp は変わった・・・」としか言えなかったもどかしさがあります。

※ちなみに、経緯・目的は依然としてすっきりしない感じです

※ WordCamp と同じく、WordPress 公式コミュニティの WordPress Meetup への参加には WordPress.org へのアカウント登録の必要がありません・・・。

スポンサーへの変更点(2025/1/1から)

事前に聞いていたものの、Matt 氏からのお年玉となった、

今後の WordCamp スポンサーは全部俺たち( Matt 氏 & Mary 氏 )が審査するよ宣言

・・・正直なところ、頭を抱えました。

WordCamp の予算レビューを担当してくれる Automattic の担当の人にも「一部の国ではスポンサー集めに苦戦している」ということを聞かされる一方で、ほんのり厳しくなったことを感じさせる予算レビューでは、「やりたいことを全部やるならローカルのスポンサーを集めよ」とのプレッシャーもありました。

例年 WordCamp にスポンサーとして参加してくれる企業さんには、スポンサー申し込みを開始する前から事前に連絡して経緯を説明したり、実行委員内で事前審査をしたりもしました。

いちボランティアが企業の Web サイトをチェックし、 WordPress という単語・ WordPress ロゴの使用状況をチェックし、修正依頼をする・・・。

・・・正直なところ、「これはボランティアでやっていいことなのか?」と何度も思いました。(今でもその思いは変わらず

最終審査は Matt 氏・Mary 氏のどちらかで行われているらしいが、多忙な彼らが世界中の WordCamp スポンサーをくまなく審査する余裕があるはずもなく、実際は Automattic の社員が日本語の Web サイトを翻訳しながら「仮チェック」をしていく運用がおこなわれていました。

その「仮チェック」の結果をそのままスポンサーに伝えるべきか、実行委員内で解釈を汲み取ってから伝えるか、いろいろな悩みがありました。(なんせ相手は機械翻訳で審査して、機械翻訳で変更指示を伝えてくる。)

・・・正直なところ、「これはボランティアでやっていいことなのか?」と何度も思いました。(今でもその思いは変わらず

そんな中でも、WordCamp を支えてくれるためにご対応いただき、参加いただいたスポンサー企業のみなさまには心からの感謝を申し上げたいと思います。本当にありがとうございました。

また、WordPressコミュニティとしては「WordPress に関連するビジネスを展開していない企業の方が審査が通りやすく、スポンサーになりやすい」という事実と向き合う必要があると思っています。

これは、WordPress に関連するビジネスを展開していない企業であれば、100%GPLの宣誓や商標の問題を難なく乗り越えることができてしまうということですが、そのような企業が WordCamp のスポンサーになること自体は何の問題でもなく、結局はその時の実行委員が判断するしかありません。
関連ビジネスを展開していなくても、 WordPress ユーザーとして応援してくださる企業さまもいらっしゃいますしね。

どのような企業が WordCamp へのスポンサーになるのがふさわしいかについては、WordCamp オーガナイザーハンドブックの資金の調達ページに記載されている内容を引用しつつ自分の想いを書き出しておくことにしますので、あなたが判断に迷ったときに思い出してもらえると嬉しいです。

スポンサーの金銭的支援は寄付金であり、イベントを応援するために支払われるものです。資金を提供してくれる方々を「スポンサー(出資者)」と捉えるのではなく、「サポーター(支援者)」と考えましょう。

実行委員内部でも「スポンサー」ではなく「サポーター」と呼ぼうか?という意見はありました。

過去のイベントにおいてこういった企業はスポンサーと呼ばれ、WordCamp 運営チームによって様々な段階のスポンサーシップレベルが設定されていました。貢献する金額のレベルが上がるほど特典(多くはマーケティング向け)が高くなるというケースが一般的でした。しかし、この傾向によって多くの WordCamp が商業的になりすぎるという弊害が生まれました

「商業的になりすぎた WordCamp 」はあまり見たくないと個人的には思っています。

スポンサーになってもらう企業に金銭的支援をしてもらう対価としてイベントの参加者に対してマーケティングや広告をしても良いという考え方はしないでください。こういったことをすると、結果的には WordCamp のスポンサーシップが広告の購入であるという形になり、WordCamp Foundation や WordCamp 運営チームの非営利性が失われることにつながります。

ローカルの WordCamp はビジネスイベントではないので、参加者としてもスポンサーとしても、こういった商業的な目的での参加は Flagship WordCamp と呼ばれる WordCamp への参加をお勧めするのがよさそうです。
WordCamp Asia 2025(フィリピン・マニラ)・WordCamp EU 2025(スイス・バーゼル)・WordCamp US 2025(ポートランド・アメリカ)と2025年に開催されたFlagship WordCamp 全てに参加した者としての意見です。

最後に

「せっかく楽しかったイベントなのに愚痴っぽい」と感じられてしまったら大変申し訳ありませんが、私個人的には今後の日本国内での WordCamp が都市圏だけではなく、以前のように地方でも開催されることを楽しみにしていますし、そのために協力できることがあれば、これからも喜んでお手伝いしたいという前向きな気持ちでいます。

WordPressプラグイン「BASE Item List」をバージョン2にアップデートしました

BASEのAPIを使って商品情報をWordPressに埋め込むことができるプラグイン「BASE Item List」をアップデートしました。

主な変更点としては、検索APIの新規受付を停止したことによるAPI認証方式の変更です。

検索APIはいろいろ問題があったらしく、BASEさんから直接お問い合わせを頂くこともあり、今回のアップデートに至りました。

V2にアップデートするとAPI認証をやり直す必要があります。

プラグイン設定画面に新方式のAPI認証の説明を記載しているので、移行をお願いします。

BASE Item List V2の設定ページのスクリーンショット

ショートコード[BASE_ITEM]はそのまま使えますが、パラメータがAPI仕様にもとづいて変更になったので注意してください。

最後に

本プラグインへのサポートについて。

本プラグインはWordPress.orgに公式プラグインディレクトリにオープンソースとして公開しています。

無償で公開していますが、設置サポート等はすべて有償にて承っております。

設置サポートについては、BASE APIの登録が終わっている状態で、ショートコードを利用した商品リスト表示(デフォルトテンプレート使用)まで一律 33,000円(税込)となります。

上記ご確認頂き、お問い合わせフォームより送信をお願いします。

Simple GA Ranking For Shifter Static

Shifter Advent Calendar 2020の20日目の記事。Simple GA RankingをShifter Static でも使いたい!という検証です。

この記事はShifter Advent Calendar 2020の20日目の記事です。

Shifterって?という方はShifterの中の人の赤塚さんによる1日目の記事を読むとよいでしょう。


Simple GA Ranking ?

Simple GA RankingはWordPressとGoogle Analyticsを連携させて人気記事ランキングを取得するプラグイン。

Google Analyticsからデータを取得するので、記事へのアクセスごとにデータベースに書き込むプラグインと比べて軽量に動作する。

公式サイトにはマニュアル動画も用意されていて、セットアップもこの手順通りにやればだいたい迷わずに設定できる。

Simple GA Ranking の設定マニュアル動画。クセになるBGMだ。

mt8もプラグインメンテナーとしてこのプロジェクトに参加している。(更新ができていないのは追々、、、)

Shifter Static でも使える(、、だが!)

Shifter StaticでもSimple GA Rankingを設定して使用することは可能だ。

ただし、表示されるランキングはShifterでジェネレート(静的書き出し)を行った時点で取得したものとなる。

つまり、ジェネレートを頻繁に行わないサイトの場合だとランキングの表示が次にジェネレートするまで変わらないということになる。

・・・惜しい。これはどうにかしたい。

Shifter Staticで静的化されたWordPressサイトからGoogle Analyticsの最新データが取得できれば人気記事だけではなく、関連記事なども実現できる可能性がある

これはどうにかしたい、、、!


ちなみに

静的化する上で避けられないWordPress運用における動的処理の代表格である「お問い合わせフォーム」・「サイト内検索」・「コメント」については

Shifterが公式ブログで外部サービスとの連携する方法を紹介してくれているので是非確認してほしい。

https://support.getshifter.io/en/collections/1394677-contact-forms

https://support.getshifter.io/en/articles/762156-integrating-algolia-search-with-wordpress

https://support.getshifter.io/en/collections/1394686-wordpress-comments

解決したい内容を整理してみる

「Shifter Staticで人気記事ランキング」を実現させるために必要となる要件を書き出しておく。

  • 静的化されたサイトに人気記事ランキングを埋め込む
  • ランキングデータはGoogle Analyticsと連携する
  • サイトアクセス時の最新のランキングを表示する

以上を実現するために、この記事ではSimple GA Ranking for Shifter Staticができないか実験していく。


Simple GA Ranking for Shifter Static

STEP1:WordPressの設定

Shifterにサインアップ・サイト追加をし、WordPressを立ち上げたらパーマリンク設定を以下にしておいた。

/%post_id%/

これで https://example.com/{記事ID}/ で静的書き出しが行われる。

STEP2:Google Analyticsアカウント

アカウント作成時の注意点としては「プロパティ」をユニバーサルアカウントとして作成すること。

手順は以下

①、「プロパティの設定」で”詳細オプションを表示”する

「プロパティの設定」から、詳細オプションを表示する

②、「ユニバーサルアナリティクス プロパティの作成」にチェックを入れる

「ユニバーサルアナリティクス プロパティの作成」にチェックを入れる

STEP3:カスタムディメンションの設定

記事の詳細ページへのPVのみをランキングデータとするためにGoogle Analyticsのカスタムディメンションを設定しておく。

ここでは次のように設定しておいた。

名前post
範囲ヒット
アクティブチェック(有効化しておく)
カスタムディメンションの設定
カスタムディメンションを定義

この設定をしておくことでGoogle Analyticsに記事詳細ページのPVであることを明示的に送信することができる。

作成したカスタムディメンションの「インデックス」の数値はこのあと使うので覚えておく。(スクショの場合は1)

STEP4:WordPressからGAにPVカウントを送信

以下のコードで、記事詳細へのアクセス時にGoogle AnalyticsにPVカウントを送信した。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-1-php

参考記事:gtag.jsでページビューのときにカスタムディメンション送信

カスタムディメンションが意図した通りに送信されているかは

Google Analtytics > 行動 > サイトコンテンツ > すべてのページ にアクセスし

「セカンダリディメンション」から作成したカスタムディメンションを選択する


もしくは、公式レポートツールのQuery Explorerを使ってもよいだろう。

次のようなパラメータで実際にサイトで取得したいランキングを問い合わせてみる。

idsga:から始まるビューID
start-dateyesterdayPV集計期間From
end-datetodayPV集計期間To
metricsga:pageviewsPVを取得
dimensionsga:pagePath, ga:pageTitleパス, タイトルを取得
sort-ga:pageviewsPVの降順で取得
filtersga:dimension1==postカスタムディメンションはpost

実行してデータが取得できていればカスタムディメンションが計測されていることになる。


Google Analytics APIをどのように実行するか

サイト訪問者がアクセスした時点でのランキングをリアルタイムに表示させたいので、Google Analytics APIはブラウザ側(javascript)から実行させることにする。

しかし、通常API実行のためのアクセストークン取得にはOAuth2認可を行う必要がある。これにはGoogleログインが必要で取得できるトークンには期限がある。

また、javascriptはソースコードが公開されるため、取得したトークンをソースコードで公開するのは問題がある。

そんなときに、GoogleのEmbed APIのページにServer-side Authorizationというページを見つけた。

具体的には以下のような手順となっていた。

  • GCPでサービスアカウントを発行しキーのjsonファイルを取得する
  • GAでサービスアカウント 発行時に作成されたメールアドレスに表示と分析権限を付与する
  • サービスアカウントのキーjsonファイルからサーバーサイドでAPIへのアクセストークンを取得する

※サービスアカウント 取得からAPI実行まではこちらの記事が参考になる:【2019年版】Google Analytics API v4 の使い方(PHP)

この例では取得したトークンをjavascriptソースに記述するようになっており、注釈として以下が添えられていた。

Important!  When you add an access token to the source code of your page, your site’s visitors could use that access token to run any query the service account could run. If your account contains sensitive information, considering adding the service account only to a specific view. You may also want to add a view filter to limit what data the service account can access.

Embed API Server-side Authorization

・・・サーバーサイド?

サーバーレスなShifterを使っているのにサーバーを用意するなんてとんでもない

そこで、今回は以下のようなAPIをserverless frameworkで構築することにした。

  1. サービスアカウントのAPIアクセストークンを取得
  2. アクセストークンを使ってGoogle Analyticsからランキングデータ取得

(このAPIを SGA4SS API と呼ぶことにする。)

SGA4SS APIをserverless frameworkで構築

serverless framework ?

Serverless Advent Calendar 2020の18日目の記事:Serverless Framework はじめの一歩という記事を読んでみるといいだろう。

ここではserverless frameworkの詳しい解説はしないが、ソースコードはGithubに上げておいた。

https://github.com/mt8/sga4ss

※なんでPython?:Embed APIのサーバーサイド認証のサンプルコードがそうだったから

このAPIの注意点

実際にAPIを公開するときにはスロットリングやキャッシュなどをきっちり管理した方がよいと思われる。(APIのURLは公開するので誰でも実行可能)

GA側ではフィルタ機能などを使って、「見られてもいいビュー」を作っておくのがよいと思われる。

***ご利用は自己責任でお願いする***


SGA4SS WordPress Pluginでデータ取得・表示

用意したSGASS APIはWordPress側では [sga4ss] というショートコード でデータを取得してリスト表示することにした。

コードは以下のようなものになる。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-2-php

・・・記事ランキングにアイキャッチ画像も付けたい

アイキャッチの取得についてはShifterの場合だと少し工夫が必要だった。

なぜならGoogle Analyticsから取得できるのはページパス(投稿ID)だけで、javascriptからでは投稿IDだけ取得できてもアイキャッチ画像を取得することはできない

Shifterサポートのお兄様たちに相談したところ、以下の方法を教えてもらった。(1時間で解決した)

①、/wp-json/wp/v2/posts/{ID} にアイキャッチ画像のURLを含める

以下のコードで、WP REST APIの/posts/{ID}にアイキャッチ画像のURLを追加することができる。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-3-php

②、/wp-json/wp/v2/posts/{ID} も静的書き出し対象に含める

以下のコードでShifterの静的ファイル出力対象にアイキャッチがある投稿については/post/{ID}をjsonファイルとして含めることができる。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-5-php
参考:Appending URLs to the artifacts

これでGA APIから取得した投稿IDからアイキャッチ画像を取得することができた。

抜粋になるが、コードだと以下の部分になる。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-6-js

最後に

実際にShifter Staticで書き出したサイトを貼っておく。

ページ最下部の人気記事ランキングの部分が紹介した方法で実装した部分だ。

https://dazzling-mestorf7276.on.getshifter.io/

いつまで残すかは未定

今回作ったコードは以下に上げているので同じようなことにチャレンジする人の参考になれば嬉しい。

SGA4SS API (Serverless framework): https://github.com/mt8/sga4ss

SGA4SS (WordPress Plugin): https://github.com/mt8/sga4ss-wp

***ご利用は自己責任でお願いする***

WordPressの書籍を執筆しました。

WordPressの書籍を執筆しました。