ブロックエディタにフル対応したWordPressテーマを作ってみた所感

ブロックエディタにフル対応したビジネス向けウェブサイト用のWordPressテーマ「Foresight」をつくりました

もともと去年2018年11月頃から、WordPressのブロックエディタ (Gutenberg) に対応した WordPressテーマ開発に取り組み始めましたが。いつの間にか方針転換をして WordPressスターターテーマ「WP Theme Boilerplate」を開発していました。テーマ開発は先延ばしになってしまいました。

今回ようやくWordPressテーマ「Foresight (フォーサイト)」がお披露目できてホッとしているところです。

タイミンク的に、ブロックエディタが WordPressに実装されてほぼ1年が経った頃で、その間ブロックエディタにも色々使いやすく改良が加えられて充実しつつあり、良かったんじゃないかと思います。

WordPressテーマ「Foresight」の特徴

WordPressテーマ「Foresight (フォーサイト)」の特徴は、

  • ビジネス向けウェブサイトまたはランディングページなど1ページもののウェブページが作れるように
  • 新しいエディタであるブロックエディタをフルに活用できるように

設計したテーマです。

ビジネス向けはもちろん、ランディングページはじめ、ブランディングやマーケティングで活用することを考慮して、デフォルトレイアウトに幅広なレイアウトを採用して作ってみました。ブログ・メディア向けテーマにするとサイドバーが必須になることが大半でブロックエディタの全幅・幅広なレイアウトが活かせないところもあったり。といっても必要な方にはオプション設定やテンプレートの選択でできるように作っています。

WordPressテーマ「Foresight」の公式ディレクトリへの登録は、これから登録申請する予定です。ので管理画面経由からのインストールはまだできません。しばしお待ちを。早々に試したい方は GitHub からダウンロードできますので、是非試してみてください。

ブロックエディタにフル対応したWordPressテーマを作ってみた所感

テーマのコンセプト的なことは、とりあえずテーマの紹介ページを用意しましたので、そちらに譲ります。またテーマの技術的なことは、GitHub のレポジトリをご覧ください。この記事では、ブロックエディタにフル対応したWordPressテーマを作ってみたときに感じたことを綴ってみたいと思います。

なぜ作ったの?

4つあります。

まずは、テーマを作るのに先立って WordPressテーマスターターキット「WP Theme Boilerplate」を作ったので、これをベースに公式ディレクトリに登録されるテーマとして実績を作ることを目指しました。

2つ目がブロックエディタにフル対応したテーマを設計するというテーマ開発の動機ができた。

WordPressの関わりは、テーマ開発がはじまりで (オープンソースで公開しているのはプラグインだけで。いくつかリリースして使われているのでプラグインの人かと思われている感がありそうですが)。当時テーマを作って公式ディレクトリに登録しようと思ったが、気合を入れすぎて機能を作ったけど、プラグインテリトリなど全く知らないこともあり、登録を断念したまま時が過ぎていきました。一時テーマ販売もしたこともありますが、どちらかというとマーケティングやメディア運営が軸に活動しているところもあり、テーマ開発は、作ったテーマの改良を続けているだけでした。新たにテーマを開発する動機がありませんでしたが。

去年末に WordPress 5.0 からブロックエディタが導入されました。開発したテーマは前エディタであるクラシックエディタに対応したものがほとんどで。今回ブロックエディタに対応したWordPressテーマを作ろうという動機が少しずつ出てきたので、手を動かし始めました。ベースにある感覚は、Gutenbergを開発段階から触っていて、完成度が高まるとコンテンツ作りに集中できるなぁという感覚でした。

ツイッターでもちょこっと所感をツイートしていた。

3つ目がブロックエディタへ移行してなにかか生まれる契機になりそう、特にビジネス面で。

ウェブサイト運営の現場も変わりつつありそうなのも動機の一つになりました。

公式ディレクトリを見てみると、ブロックエディタに対応したテーマがまだまだ少ないのが現状です。今はまだブロックエディタへの移行期の途中ですね。無料有料のWordPressテーマもクラシックエディタの部分を引きずっているところがあります。(現実的には継続してアップデートを繰り返してもブロックエディタへの移行も難しいですから。特に機能部分の移行や破棄はやりづらいですね。テーマ開発者にとって辛いことですが。コツコツ頑張りましょう。ボクも以前作ったテーマで苦労している最中です〜。)

実際のウェブサイト運営の現場でも今までの業務の仕方で特に支障がないためブロックエディタに変える必要性があまり見いだせないところでしょう。クラシックエディタから使い込んでいるWordPressサイトでは、ブロックエディタへの移行もなかなか進んでいかないのも現状かと思います。

テーマの設計面やウェブサイト運営の現場など広く見渡しても一筋縄でいかず、解決策を探るべく模索がまだまだ続いていくかと思います。

その中で、特にビジネス面でなにかか生まれてくることに期待しています。その期待を見据えつつ、ビジネス向けWordPressテーマとして作ってみたところがあります。

4つ目がウェブサイト設計の知見を一層深めること。

ブロックエディタになったWordPressで、いままでのウェブページの作り方がガラリと変わります。

以前のクラシックエディタは、HTMLベースのテキスト入力 (テキストモード) あるいは見出しや太字などテキストの装飾をメインにしたビジュアル編集 (ビジュアルモード) でした。

これがブロックエディタになると、見出しや太字などテキストの装飾はもちろん、コンテンツ部分の構成やレイアウトもブロックを積み重ねるようにして作ることができます。HTMLやスタイルシートを扱わなければできなかったことが、HTMLを直接扱うことなく (ブロックエディタがその部分をうまく吸収してほとんど表に出ることなく、求められる技術スキルのハードルが下がり)、文章の作成や編集修正、レイアウト作りが誰でもできる形でウェブページが作れる。つまり、コンテンツ作りに集中できる環境がブロックエディタで実現しています。

ウェブサイトを運営する方にとっては、ホームページの開設や日々の運営していくコンテンツ作成の敷居が下がる分、ビジネスチャンスを掴みやすい環境になります。コンテンツの部分でもビジネスに発展していく機会が増えていってほしいですね。

これからのWordPressテーマ設計を考えてみる

反面、テーマ開発者はじめ、ホームページ制作やウェブサイト構築に携わっている方にとってウェブサイト構築やウェブデザインのあり方まで変わる可能性を秘めているところです。面白いところでもありますが、設計と実装面で相当の技術レベルが要求されつつあります。ウェブサイトを運営する方にとってハードルが下がるということは、設計実装面ではハードルが上がることを意味します。そこについていくことがなかなかつらい現状ですが...。

WordPressのテーマ設計面を診てみると、
ブロックエディタの導入による大きな変更は、テーマの機能として実装していた部分

  • ウェブサイト機能 (ウェブサイト全体設計の部分)
  • コンテンツ機能 (本来はプラグインテリトリに該当するかなぁ)

として機能を作り込んできたかと思います。

レイアウト機能やコンテンツを構成するコンポーネント、ウィジェット、ショートコード、ビジュアルエディタの機能拡張などを独自の設定画面を作ったり、カスタマイザに設定パネルを用意してWordPress管理画面に使いやすく実装してきました。

これからは4つのレイヤーで設計を考える

いままでWordPressのテーマ設計を考える場合、3つのレイヤーで考えるところが (テリトリにもつながるところですね)

  1. WordPress本体の機能 (標準機能)
  2. WordPressテーマの機能 (ウェブサイト機能とコンテンツ機能)
  3. WordPressプラグインの機能 (付加機能)

そこにブロックエディタが加わり、テーマの機能にあったコンテンツ機能に当たる部分がブロックエディタに移ることになると思います。以下のように。(コンテンツテリトリみたいになっていくのかなぁ)

  1. WordPress本体の機能 (標準機能)
  2. WordPressテーマの機能 (ウェブサイト機能)
  3. WordPressプラグインの機能 (付加機能)
  4. ブロックエディタの機能 (コンテンツ機能)

つまり、テーマあるいはプラグインのどちらに実装すればいいのか今まで曖昧で、はっきりしなかったコンテンツ機能の実装が、ブロックエディタの導入で明確になったことが大きいなぁと感じます。

ということで、いままでカスタマイザにあったコンテンツ機能がブロックエディタに移っていくように設計されることになるかと思います。 プラグインもコンテンツ機能を担っていたものの一部はブロックエディタ (またはカスタムブロックとして) に移りそう。特にウィジット系はブロックエディタに統合される将来があるのかなぁとも思いますね。全体的にもブロックエディタ上に統合する形の方向にもなりそう。

またWordPressテーマ不要論もチラホラ見受けられます。が、WordPressテーマはウェブサイト全体設計として残ります。そのテーマで出来上がるウェブサイトを規定する上位の設計思想 (コンセプトの部分にあたるところ) として。WordPressテーマ「Foresight」もそんな感じで作ってみました。

WordPressは、全体を見るとなにか複雑になっているように見えますが。
設計面をこうして見ると、うまく分かれてWordPressが進化しているのが理解できますね。

ということを考えることが楽しい今日この頃です。

WordPress 本体のアップデートプロセスチャート

WordPress 本体のアップデートプロセスチャートを作ってみました。

WordPress 3.7 から実装された自動更新で WordPress がアップデートされると、WordPress 本体が自動でアップデートできます。

自動更新は、いくつかのアップデート方式 (マイナーバージョンだけ、メジャーバージョン・マイナーバージョン両方) があり、それぞれが WordPress 本体がどのようにアップデートするか図解してみました。

加えて、開発したプラグイン「WP Auto Updater」で実装したアップデート方式

  • Minor Only Version Update
  • Previous Generation Version Update

を追加してみました。

安定的な WordPress サイトの運用に参考にどうぞ。

WordPress Update Process Chart
WordPress Update Process Chart

参考

次世代 WordPress テーマスターターキット「WP Theme Boilerplate」をリリースしました

WordPressスターターテーマ「WP Theme Boilerplate」を開発しました。

去年2018年11月頃。WordPress 5.0 から新しいブロックエディタ (Gutenberg) が出ることだし、それにフィットする WordPressテーマを作りたいなぁと。公式に掲載してみたいなぁと。
もともと定番スターターテーマである「_s (Underscores)」をベースにテーマを作っていましたが。
気づいたらいつのまにか方針転換をしちゃって、テーマ作りより独自のオリジナルテーマがスムーズに作れる環境を作ったほうが広がりがあって面白いなぁと思い、取り組んでみました。

WordPressテーマスターターキット「WP Theme Boilerplate」 8 つの特徴

特徴は 8 つほど。

  • テンプレート階層とディレクトリレイアウトを改善
  • WordPress Theme Autoloader を実装
  • テーマの機能をクラスベースで実装
  • Theme hooks を実装
  • Block Editorに最適化した WordPressテーマを目指して Block Editor (Gutenberg) をサポート
  • Theme Starter script で独自テーマのスターターテーマを生成
  • npm scripts でテーマ開発環境を整備
  • composer scripts でテーマテスト環境を整備

スターターキットとしてテーマ開発環境を整備

  • フロントエンド開発環境
  • WordPressテーマ開発環境
  • テスト環境 (ユニットテストや静的コード解析、CI/CDまで)

この辺がサクッと整備されたらいいなぁと。

ただ効率的にテーマがつくれることだけを追求してもだめで。(単にテーマを作れるだけでは価値はだんだんなくなってくる)
一番価値が生まれるところである、デザインやコンテンツにきちっと時間を割きたい。
ビジネスにスピードと柔軟性が求められている中でプロトタイプ的な、アジャイル的なアプローチで開発ができるようにしたい。
常に改善されるテーマになるよう機動性を手に入れたい。
新しい価値を生み出す今の開発環境にマッチできるような設計思想をいくつか組み入れてみました。

結果、ただテンプレートが揃っただけのスターターテーマではなく、開発環境やテスト環境など周辺環境を整えた「スターターキット」にしてみました。

テーマ設計で感じたこと

WordPressテーマは、ディレクトリ直下にテンプレートファイルが置かれる (WordPress 全体から見るとテーマフォルダ自体が View って感じな、テーマ開発者にとって View がディレクトリ直下にある感じな) ので、
ディレクトリ構成上フラットになりやすく、いろんな種類や役割がファイルが混ざってくる。
シンプルなテーマなら気にならないが、開発しているとファイルが散らばり複雑になってくる。
のちのち開発効率や開発意欲の低下がボディブローのように効いてくるので手を入れて整理してみた。

シンプルにテンプレートファイルを一つ下のディレクトリにまとめるアプローチで解決する。
テンプレート階層にも関わってくるので、複雑なことはしないようにする。
WordPressは、テンプレートの選ばれ方を把握していないとそう簡単に動かすことはできないけど。
これでディレクトリレイアウトが少しばかり整理される。

次にテーマの機能を関数からクラスベースに変える。
従来だと、関数名がWordPressコアの関数や他のテーマ・プラグインの関数とかぶらないように
関数名を「テーマ名のプリフィックス_関数名」みたいに先頭に namespace をつける。ので関数が必然的に長くなる。
また開発を続けていると、どの機能に関係している関数か、この関数はどこに影響や副作用を及ぼすのか、
functions.php が肥大したり、次第にまとまりがわからなくなってくる。
方向性としてテーマの機能は、クラスベース (クラスファイル) で namespace をつかってそれぞれの機能が分離するように再設計した。

そのクラスファイルは、composer autoloader のように自動的に読み込んでくれるように
WordPressのファイル命名規則に基づいて WordPress Theme Autoloader を実装してみた。
必要ならば composer autoloader を使って外部のライブラリにある機能を取り込めることもできるし。
大掛かりにならない程度の実装で機能を取り込めるように、開発が楽しくなるように目指してみた。

メインテンプレートには、複雑なロジックを入れないようにベースとなるレイアウトだけ定義する形がよさそう。
そしてパーツとして切り分けたファイルをメインテンプレートに読み込むのが基本線。
また wp_head, wp_footer などテンプレートタグにフックする。(最近 v5.2 だと wp_body_open が出てさらに便利になったね)

フックは WordPressの大きな特徴で醍醐味な部分なので。(フックを覚えたらWordPressの開発が楽しくなると思うなぁ)
テーマ専用のフックがあってもいいのではなかろうか。(将来共通化したものが出てくれたらうれしい)
ということで Theme hooks を実装してみた。
メインテンプレートのレイアウトの所々にいくつか設けた Theme hooks に引っ掛けることでメインテンプレートには手を入れずに追加要素を差し込んだり、フックした関数 (アクション) 側で複雑なロジックを組み入れることを目指してみたい。

あなただけのオリジナルWordPressテーマをつくろう

独自テーマが作れるように Theme Starter script を用意してみました。
テーマ名を引数に Theme Starter script を走らせるだけでオリジナルテーマの雛形がすぐに生成されます。
そこからあなただけのオリジナルWordPressテーマをつくっていける開発環境ができあがる。
WordPressテーマを作れる環境はすでに目の前にあります。
WordPressテーマ作りを楽しく過ごしてみてね。

素敵な、便利な、魅力的な WordPressテーマがたくさん生まれたり、
面白い、読み応えのあるコンテンツがある WordPressサイトがいっぱい出来上がったり、
テーマ開発やWordPress構築プロジェクトを成功に導いたりと。
WP Theme Boilerplate が縁の下の力持ちとして
少しでも力になれば幸いです。

リソース

今後すること・したいこと

今後やることをメモ。

  • テストを書く
  • ドキュメントをつくる
  • WP Theme Boilerplate をベースに公式テーマを (やっと) つくる

WordPress運用保守チェックリスト

WordPressでウェブサイトやブログを立ち上げるのは、手軽でツールとして便利な一方。
運用しつづけるには、メンテナンスをする手間やセキュリティ上のリスクを自分で対応する必要があります。

保守管理レベルで対応できる範囲はそれぞれですが。
個人でWordPressサイトを運営する方から、ビジネスでWordPressを使ってウェブサイトを開設している方、ウェブ制作会社などクライアントのウェブサイトをサポートしている方に参考になるようできるだけ幅広い視点から「WordPress運用保守チェックリスト」を作成してみました。

WordPress運用保守の底上げに繋がれば幸いです。

WordPress運用保守チェックリスト (2019.06.26更新)

WordPress保守・保全

  • WordPress本体・テーマ・プラグインがアップデートできる環境になっている
  • 自動アップデートが機能している環境になっている
  • WordPress本体はこまめにアップデートしている
    1. 手動
    2. 自動
  • テーマ・プラグイン・翻訳はこまめにアップデートしている
    1. 手動
    2. 自動
  • データのバックアップを定期的にしている (ファイルとデータベース両方)
    1. 手動
    2. 自動
  • バックアップデータの格納先
    1. サイトと同一サーバー上
    2. 別のサーバー・ストレージサービスなど遠隔スペース
  • バックアップ先は、セキュリティを施してアクセスは制限されている
  • データベースの肥大化を防いでいる
    • 投稿履歴の件数を制限している
    • データベースの​​最適化を定期的に行っている
  • リストアなど復旧作業のシミュレーションを検証環境上で行っている

WordPressセキュリティ

アプリケーションレイヤー

  • テーマ・プラグインは出所 (開発元) を確認して適切に管理している
    • 公式ディレクトリ掲載 (審査レビューチェック済み)
    • 有料テーマ・プラグイン
    • 野良テーマ・プラグイン (配布先ダウンロードが特定サイトのみ、GitHubなどレポジトリのみ)
  • 使っていないテーマ・プラグインは削除している
  • セキュリティ系のプラグインを少なくとも一つは導入している
    • ログイン試行防御 (総当たり攻撃・ブルートフォースアタック、パスワードリスト攻撃)
    • DDoS 攻撃防御
    • メールフォームスパム対策
    • セキュリティ監視
  • wp-config.php の salt を wordpress.org salt generator で生成して設定している
  • wp-config.php をアクセスできないルートディレクトリ外に配置している
  • ファイル編集機能を停止している

ミドルウエアレイヤー

  • ファイルパーミッションを適切に設定している
  • PHPの実行を拒否、ファイルアクセス拒否制御を行っている
    • wp-config.php
    • /wp-admin/includes/
    • /wp-includes
    • /wp-includes/js/tinymce/langs/
    • /wp-includes/theme-compat/
    • /wp-content/themes/
    • /wp-content/plugins/
    • /wp-content/uploads/
  • 管理画面ログイン・アクセスを強化している
    • 2段階認証・2ファクタ認証を導入している
    • CAPTCHAを導入している
    • Basic認証を導入している
    • 管理画面のアクセスをIPアドレスホワイトリストで限定している
  • サイトへの特定のアクセスをIPアドレスブラックリストで制限している
  • 国外IPアドレスフィルタを有効にしている
  • WAFを導入している、またはWAF機能を有効にしている
  • マルウェア混入チェックを定期的に行っている
  • 脆弱性診断を定期的に行っている

ヒューマンファクター

  • ユーザ名 admin は削除している、または存在していない
  • ユーザ名 admin のログインを禁止している
  • ユーザーのパスワードを適切に設定している
    • 8文字以上
    • 小文字・大文字・数字が最低1つずつ含まれている
    • できれば記号も含める
    • パスワード自動生成なら尚よし
  • 複数のユーザアカウントには、適切な権限を付与している
  • 使われていないユーザアカウントは定期的に削除している
  • セキュリティ系のプラグインでログインアクセスを履歴記録している

サーバ・システムインフラ基盤

  • サーバーの保守管理担当者がいる
  • レンタルサーバーまたはVPS・クラウドサーバーで運用している
  • 独自ドメインで運用している
  • SSL/TLS (サーバ証明書) を導入して暗号化通信している
    1. http と https 両方でサーバー接続している
    2. 常時SSL (https のみ限定サーバー接続、http はリダイレクト処理)
    3. 常時SSL (https のみ限定サーバー接続、http は80番ポート閉鎖)
  • サーバー・データベースやPHPなどミドルウエアを定期的にアップデートしている
  • 定期的にサービスプランを変更してサーバーを刷新している、またはサーバ・システム基盤をリプレイスしている
  • システムパフォーマンスを定期的に計測している、またはモニタリングしている

運用体制・障害対応

  • WordPressの保守担当者がいる
  • 死活監視を導入している
    1. 人的監視
    2. リモート自動監視
  • アラート通知など障害発生にすぐに気づく体制がある
  • 24時間以内に一次対応 (応急処置) で障害の復旧ができる
  • 障害の原因調査ができる体制がある
  • WordPressサイトの再現検証、テスト環境がある
  • 再発防止策の実施など根本的な解決を行える体制がある
  • 障害報告・対応作業報告・作業予定など情報を共有している
  • 運用保守体制を定期的にチェックして改善している

参考

WordPressバックアップスクリプト「WP Offsite Backup」をリリースしました

仕事柄「WordPress (ワードプレス) 保守管理サービス – シングスマネジメント」でバックアップ体制をつくったり。
プラグインでバックアップを試してみたり。
そうこうしているうちに WordPress サイトをバックアップするスクリプトをつくっていました。

WordPressバックアップスクリプト「WP Offsite Backup」は、WordPressのファイルやデータベースのデータを Amazon S3 など外部ストレージに遠隔バックアップするスクリプトです。

WP Offsite Backup - GitHub

使い方は簡単

あらかじめデフォルトの設定をして

bash wp-offsite-backup

とコマンドを走らせるだけ。手動でバックアップします。

また、自動で走らせるには、Cron でスケジュールを設定するだけ。

MAILTO=hoge@example.com

20 0 * * * bash /path/to/wp-offsite-backup/wp-offsite-backup

とすると、毎日0時20分にバックアップします。

WordPressバックアップスクリプト「WP Offsite Backup」の特長

  • ワードプレスのファイルとデータベースをバックアップ
  • ストレージサービスにバックアップファイルを保存 (今のところ Amazon S3 だけに対応)
  • Cron で自動バックアップ
  • 設定のカスタマイズでいろいろなバックアップができます
  • バックアップファイルのローテーション
  • ログ履歴の管理

サポートしているストレージサービスは、いまのところ Amazon S3 だけですが、
おいおい Google Cloud Storage や Microsoft Azure Storage などにも対応してみたいと思います。

基本設計は、依存関係の解決やメンテナンスを極力減らすため、
WordPress のプラグイン、WP-CLI などコマンドラインツールに依存せず、
Linux コマンドとストレージサービスのコマンドラインツールだけで済ませるようにしました。
またデータをローカルサーバに残さないようにセキュリティに配慮してみました。

使い方もデフォルトの設定をしたら、コマンドを走らせるだけでバックアップができるを目指してみました。

WordPressバックアップスクリプト「WP Offsite Backup」を導入するには、
いまのところ AWS Command Line Interface などストレージサービスのコマンドラインツールをインストールする必要があるので、
root 権限を持っている VPS やクラウドサーバーに導入に限られてしまいますが、
レンタルサーバーでも動かないかなぁと模索中です。

設定のカスタマイズでバックアップいろいろ

インストールや設定の仕方は、ドキュメントの「Getting Started」を参考にどうぞ。

もちろんバックアップのカスタマイズもできます。

カスタマイズした設定に名前を付けるだけ。

設定も保存して複数持てるので、
WordPressファイルをフィルタリングしたり、
データベースだけバックアップということも。
一つのサーバに複数の WordPress サイトがあっても、
それぞれのウェブサイト用に設定を切り替えてバックアップできます。

その場合のコマンドは、カスタマイズした設定を渡すだけ。

bash wp-offsite-backup customized-config

Cron で自動バックアップも
環境変数 WP_OFFSITE_BACKUP_CONFIG にカスタマイズした設定を渡すだけ。

MAILTO=hoge@example.com

20 0 * * * WP_OFFSITE_BACKUP_CONFIG=customized-config bash /path/to/wp-offsite-backup/wp-offsite-backup

設定のサンプルもあるので参考にしてみてください。

  • db-only-backup-config (データベースだけバックアップ)
  • full-backup-config (フルバックアップ)
  • partial-backup-config (wp-content とデータベースだけバックアップ)
  • wp-content-only-backup-config (wp-content だけバックアップ)

バックアップファイルのローテーションで費用負担を減らす

ストレージサービスをバックアップに利用すると、
いつの間にかバックアップファイルがたくさんできてしまします。
気が付かないでいると、ムダな費用を払うこともあると思います。
バックアップの性格上、何かがあったときの復旧に必要な直近のバックアップファイルだけあれば、
充分済むことが大半だと思います。

ファイルの整理をするには、Amazon S3 だと、ライフサイクルで有効期限を決めて、
その有効期限が切れたならば、ファイルを削除するということを
ストレージサービス側で設定する必要があります。

これはこれで便利なのですが、
できたらファイル数で制限してファイルのローテーションをしたいと思い、実装してみました。

ストレージサービスの課金は、ディスク使用量によって決まるところが大半なので、
ファイルサイズが大容量になりやすいバックアップファイルにとってより大切なこと。

バックアップファイルのファイル数で制限することで費用をコントロールしながらバックアップシステムが構築できます。

是非WordPressバックアップスクリプト「WP Offsite Backup」を試してみてね。

ドキュメント: wp-offsite-backup - GitHub

最近の投稿

カテゴリー

アーカイブ