だから私はカスタム創世記の子テーマを持つWordPressベースのサイトがあります。サイトが公開されたら、明らかに子テーマのコードを定期的に変更する必要があります - CSSの修正など。これらは私が遭遇した問題です:
私はShellまたはFTPアクセスを持っていないので、サーバー上のファイルを置き換えることはできません(彼らはセキュリティとメンテナンスの容易さのためにこれらの専用のWordPressホスティングプロバイダを使いたかったのです)。
Webベースのアップロード機能を使用しているときにアクティブなテーマを「その場で」アップグレードすることはできません(これはWordPressのリポジトリ経由でインストールされたテーマでのみ可能です)。
上記の制限を回避するには、Zipファイルを作成するたびにgitリビジョンハッシュなどのテーマ名を入れて、WordPressでそれを別のテーマとして認識させてから切り替えることができると思います。古いものから新しいものへ。これはうまくいきますが、WordPressがその設定の一部(特にどのメニューが 'Navigation Bar'として設定されているか)をリセットします。
明確にするために、私は変更をプロダクション環境で行う前にテスト/変更を確認する方法を尋ねていません。私の問題は特に変更を加えるメカニズムにあります。
私の状況を考えれば、中断することなく/更新するたびに設定を変更する必要なしにこれを行う方法はありますか?
私は私自身の質問に答えるつもりだと思います:
私の問題#1(直接サーバーにアクセスできない)は、おそらくこの状況を最もいらいらさせるものでしょう。それが問題ではなかったならば、私には他にも多くの選択肢が開かれると思います。
しかし、その制限を考えると、「新しい」テーマを作成してアップロードするのが最良の選択のようです。それを受け入れて、質問は私が#2で述べた問題をどうやって解決するかになりますか?
その答えは、
この問題はWordPress自身の制限( tracker#18588 )であり、将来のバージョンでは修正される可能性があります。それまでは、リンクされたチケットでユーザーによって提供される(そしてStack Exchangeでは ここでも のように)プログラムによる回避策があります。切り替え時のテーマ間そのコードを私自身のテーマに合わせたところ、私のユースケースには回避策で十分であることがわかりました。
乾杯
この場合は、新しいテーマを作成します。
しかし、ライブアップデートには注意してください。これはカウボーイコーディングに変わる可能性があります。 localhostで変更を加えてから、管理を通じてZipファイルとして新しいテーマをアップロードしてアクティブにします。
それは前のテーマの正確なコピーですが、修正があります。