- このトピックには28件の返信、2人の参加者があり、最後に
により1ヶ月、 2週前に更新されました。
-
投稿
-
以下整理してご共有いたします。
お手数おかけしますがご確認のほどお願い申し上げます。– アップデートした際、アップデートしたものは何でしょうか？
WordPress本体 Ver5.3.2 → Ver7.3
Snow Monkey Ver7.10.3 → Ver28.0.2– 復元した際、復元したものは何でしょうか？
サーバー(ロリポップ)のバックアップバックアップオプションにて保存されていたhp階層以下のすべてのファイル– 「復元元のファイルには /debug-template-overwrite.php が存在しなかった」とのことですが、サーバー上の Snow Monkey を復元元と全く同じものにすることは可能でしょうか？
手作業になりますが、物理的には可能です。– 復元に使ったデータを共有していただくことは可能でしょうか？（可能な場合、共有方法は別途）
サーバー上のバックアップをダウンロードし共有することが可能です。共有方法は別途ご相談。– Snow Monkey Child を共有していただくことは可能でしょうか？（可能な場合、共有方法は別途）
→こちらもサーバー上のファイルをダウンロードし共有することが可能です。共有方法は別途ご相談。いいねをした人: 居ませんありがとうございます！
では一旦データを共有いただき、それを拝見してからどうしたほうが良さそうか回答させていただければと思います。オンラインコミュニティ（Discrod）の DM か、お問い合わせフォームでデータを共有いただきたいです。
zip だと重くて送れないと思うので、Dropbox 等のファイル共有サービスで共有いただければと思います。### オンラインコミュニティ
### お問い合わせ
お手数おかけいたしますが、よろしくお願いいたします！
—
WordPress本体 Ver5.3.2 → Ver7.3
現在の WordPress の最新版は 6.7.1 なので、6.3？か6.7？かなと思いますがどうでしょうか？
いいねをした人: 居ません先ほど、お問合せよりギガファイル便をお送りいたしました。
お手数ですがご確認のほどお願い申し上げます。また、ワードプレスのバージョンについて、
変更後の正しいバージョンは、6.7です。大変失礼いたしました。
いいねをした人:
ありがとうございます。ダウンロードできました。
復元元のデータを確認したところ、
snow-monkeyの中にはdebug-template-overwrite.phpが入っていなかったので、これが正として、サーバー上のファイルを置き換えてみるのが良いのかなと思いました。例えば今サーバー上に
wp-content/themes/snow-monkeyがあるとしたら、それをwp-content/themes/_snow-monkeyとリネームして、復元元データの中にあるsnow-moneyをwp-content/themes/にアップロードする、という感じです。もしかしたら復元元のデータも完全ではない可能性があるかもしれませんが、現状動いていないのなら試しても良いのかなと…。ダメだったら削除してリネームしたものを元に戻せばよいですし。—
あと気になったのは、
snow-monkey-child-masterの中に、特にカスタマイズしていないと思われるファイルが複数入っていたことです。子テーマによるファイルの上書きは「どうしても必要なものだけ」をおこなうのがベターです。そうしないと今回のようなアップデートによる動作不良の発生確率が高くなるためです。上書きする必要のないファイルが大半なのであれば、snow-monkey-child-masterを使わずにすむ可能性もあるので、まずは本当に上書きする必要があるファイルを選別するのが良いかなと思いました。—
諸々作業をおこなってまた最新版へのアップデートをおこなう際は、また動作不良が発生してしまわないように、テスト環境を用意して、そこでちゃんと動くようにできたら本番にも反映するようにするのが良いです。自分のパソコンの中にテスト環境をつくれるツールも色々あるので、一度見てみてください（もしかしたら本番環境が古いので動かない場合があるかもですが…）。
いいねをした人: 居ませんご確認ありがとうございます。
1点確認したいのですが、最新版のSnow Monkeyのテーマはchildは不要というのが基本となっているのでしょうか？
そうであれば、1度childはリネームし使用せず、親テーマのみ置き換えを行ってみたいとおもいます。
いいねをした人: 居ません子テーマをリネームし、親テーマを復元前のものに置き換えてみました。
不完全なレイアウトのサイトと、管理画面にはログインすることができましたが、親テーマ(Ver28.0.2)に更新したところ、再度エラー画面となってしまいました。
エラーログはこちら
Fatal error: Uncaught Error: Call to undefined function register_block_pattern_category() in /xxxxx/wp-content/themes/snow-monkey/app/setup/remote-block-patterns.php:172 Stack trace: #0 /xxxxx/wp-includes/class-wp-hook.php(288): snow_monkey_register_remote_block_patterns('') #1 /xxxxx/wp-includes/class-wp-hook.php(312): WP_Hook->apply_filters(NULL, Array) #2 /xxxxx/wp-includes/plugin.php(478): WP_Hook->do_action(Array) #3 /xxxxx/wp-settings.php(523): do_action('init') #4 /xxxxx/wp-config.php(94): require_once('/home/users/1/c...') #5 /xxxxx/wp-load.php(37): require_once('/home/users/1/c...') #6 /xxxxx/wp-admin/admin.php(34): require_once('/home/users/1/c...') #7 /xxxxx/wp-admin/themes.php(10): require_once('/home/users/1/c...') #8 {main} thrown in /xxxxx/wp-content/themes/snow-monkey/app/setup/remote-block-patterns.php on line 172サイトに重大なエラーがありました。 詳細については、サイト管理者のメール受信ボックスを確認してください。
WordPress でのデバッグをさらに詳しく見る。
いいねをした人: 居ません不完全なレイアウトのサイトと、管理画面にはログインすることができましたが、親テーマ(Ver28.0.2)に更新したところ、再度エラー画面となってしまいました。
わー！いきなりアップデートしてはだめです！前にも書いたように、現行の Snow Monkey は WordPress の 6.7 からをサポートしています。それ以下のバージョンの WordPress では正しく動きません。
喜多さんがどういう方針で対応されたいかによると思いますが、個人的には一旦元の状態に戻し、元のレイアウトで表示されるようにするのが良いと考えていますがどうでしょうか？「不完全なレイアウト」には復元できたということなので、それがなぜ不完全なのかを調査して対応していけば元に戻せると思います。
※ここでいう「復元」は完全に元の状態に戻すことを指しています。WordPress のバージョン、Snow Monkey のバージョン、各種プラグインを元に戻す必要があります（可能ならデータベースも）。
その後、本番でいきなりアップデートすると同じことになってしまうので、前に書いたように、
あと気になったのは、snow-monkey-child-master の中に、特にカスタマイズしていないと思われるファイルが複数入っていたことです。子テーマによるファイルの上書きは「どうしても必要なものだけ」をおこなうのがベターです。そうしないと今回のようなアップデートによる動作不良の発生確率が高くなるためです。上書きする必要のないファイルが大半なのであれば、snow-monkey-child-master を使わずにすむ可能性もあるので、まずは本当に上書きする必要があるファイルを選別するのが良いかなと思いました。
諸々作業をおこなってまた最新版へのアップデートをおこなう際は、また動作不良が発生してしまわないように、テスト環境を用意して、そこでちゃんと動くようにできたら本番にも反映するようにするのが良いです。自分のパソコンの中にテスト環境をつくれるツールも色々あるので、一度見てみてください（もしかしたら本番環境が古いので動かない場合があるかもですが…）。
の対応をするのが良いです。一般的にもテスト環境でを用意して作業することが推奨されています。どうしてもテスト環境を用意するのが不可能・ある程度サイトがダウンしているのを許容できる状況、なのであれば、本番で作業しても良いとは思いますが…。
1点確認したいのですが、最新版のSnow Monkeyのテーマはchildは不要というのが基本となっているのでしょうか？
まず、Snow Monkey 公式としては子テーマは用意していません。WordPress でテンプレートを書き換える場合は一般的には子テーマを使うことになるので子テーマを作っている方のページにリンクはしていたと思うのですが、そもそも、個人的に子テーマが必須なカスタマイズは非常に高度なものだと考えているので、WordPress にそれほど詳しくない場合は、子テーマを使うレベルのカスタマイズはしないほうが良いと考えています。やはり不具合が発生したときに元に戻すのが難しくなるので。
繰り返しになりますが、snow-monkey-child-master の中に不要と思われるファイルが入っているので、本当に上蓋が必要なファイルだけに絞ってみてください。そうしないとテンプレートの上書きを行っているのか、行っている場合は本当にする必要があるのか、を検討するのが難しいと思います。ほとんどが不要という結果であれば、アップデートのための書き換えも最小限ですむと思いますので…。
いいねをした人: 居ませんすみません、キタジマ様のおっしゃられている変更の手順としては、
①ワードプレスのテーマをスノーモンキー以外のもの（例：Twenty Twenty-Five）に変更して、ワードプレスのバージョンをアップデート
②スノーモンキー子テーマの記述を、最新版の親テーマに対応するように記述しなおす
③最新版のスノーモンキー親テーマと記述しなおしたスノーモンキー子テーマをアップロード
④スノーモンキー子テーマを有効化
で認識は合っていますか？
また、今までスノーモンキーの子テーマを使用していた人が最新版のスノーモンキーテーマを使用するためには、自分でスノーモンキー子テーマの記述を最新版に対応するように記述しなおす必要があるということで認識は合っていますか？
そうであれば、親テーマのアップデートに伴い、子テーマで修正が必要な個所をすべて（購入者側でカスタマイズした部分を除く）教えていただくことは可能でしょうか？購入者側でテスト環境を用意して確認していかなければならないものなのでしょうか？
いいねをした人: 居ません認識に違いがでないように細かく書きます。
### 本番環境の復元
バックアップデータを使い、エラーが発生する前の状態に戻す（WordPress 本体、各プラグイン、Snow Monkey、Snow Monkey Child）### テスト環境の構築と、Snow Monkey Child の最新版への対応
- ローカルにテスト環境を用意し、WordPress の最新版をインストールする（ローカル環境ではなくてサーバー上に用意しても可）
- 使用するプラグインの最新版をインストール・有効化する
- Snow Monkey の最新版をインストールする
- Snow Monkey Child から不要（= 上書きする必要がない）なファイルを削除する（Snow Monkey からコピーしてきたけど何も変更していないファイルは全て不要です）
- Snow Monkey Child をインストール・有効化する
- 恐らくここでエラーがでて表示されなくなる（このトピックを立てたときと同じ現象）
- でてきたエラーメッセージに応じた変更を加え、エラーを解消する。
- (7) をエラーが無くなるまで繰り返す
※本当はここで本番環境のデータベースをテスト環境にインポートして、ページの内容についても崩れが発生しないか確認したほうが良いですが、難しいのであれば、僕ならページの内容については本番で直していきます。
### 本番環境への反映
- 本番環境のテーマを Snow Monkey 以外のものに切り替える（Twenty◯◯が良いと思います）
- WordPress と各プラグインを最新版にアップデート
- Snow Monkey 最新版をインストール
- テスト環境で修正した Snow Monkey Child をインストール・有効化
※もしここでまたエラーメッセージがでるならエラーが出なくなるまで修正をおこなう - エラーが無くなったら、各ページの内容を確認し、レイアウト崩れが発生していないか確認
- レイアウトが崩れている部分があったら、そのページの編集画面を開く（ブロックを使ってページを作成している場合、ブロックの内容が古くなっている場合はページの編集画面を開くことで、そのページ上のブロックが最新のブロックに置き換わります）
- ページの編集画面を開いてエラーが発生するようなら修正をおこなう
- もし CSS を独自に追加している場合、WordPress 本体や Snow Monkey のアップデートで CSS が効かなくなっている場合があるので、必要に応じてその修正もおこなう
また、今までスノーモンキーの子テーマを使用していた人が最新版のスノーモンキーテーマを使用するためには、自分でスノーモンキー子テーマの記述を最新版に対応するように記述しなおす必要があるということで認識は合っていますか？
カスタマイザーやブロックの設定パネルで設定していたものが正しく動かなくなるのはこちらで修正してアップデートを日々おこなっていますが、各ユーザーごとのカスタマイズは何をどうカスタマイズするかはこちらで完全に把握することはできないため、基本的にはご自身で変更していただく必要があります。車や PC を購入してそれを自分でカスタムした場合、保証が効かなくなったり修理を断られたりすることがあると思います。自分でカスタマイズをおこなうというのはそういうことだと思います。
もちろんサポートはおこなっているので、状況を教えていただければできる範囲で調査してお答えしています。
そうであれば、親テーマのアップデートに伴い、子テーマで修正が必要な個所をすべて（購入者側でカスタマイズした部分を除く）教えていただくことは可能でしょうか？
「子テーマを作成する」ということ自体がカスタマイズになる（こちらで用意したファイルではない）ので、こちらで全てを調査・把握して修正作業をおこなうということは行っておりません。もちろん、前述したようにサポートはおこなっているので、状況を教えていただければできる範囲で調査してお答えしています。
購入者側でテスト環境を用意して確認していかなければならないものなのでしょうか？
「していかなければならない」と強制するものではありませんが、カスタマイズをおこなう場合はテスト環境を用意したほうが良いというのは一般的な認識だと思うので、僕もテスト環境を用意することを推奨しています。
—
Snow Monkey に精通している方を「Snow Monkey エキスパート」としてサイトに掲載しているので、どうしても難しい場合はエキスパートの方に相談するのも良いと思います。これまでもサポートフォーラムで Snow Monkey エキスパートの制度を紹介し、相談された方が何名かいらっしゃいます。
いいねをした人: 居ませんこちらの理解が不十分で大変失礼いたします。
前提として、Snow Monkey ChildはSnow Monkeyのテーマには不要なもので、Snow Monkey公式が作ったものではないので関与しません（ただし善意で相談には乗りますよ）ということなのでしょうか？
Snow Monkey Childの説明にはSnow Monkeyの子テーマとの記載があるため、子テーマと親テーマのアップデートには関連性があるものと認識しておりました。
もし関連性があり、古いバージョンから新しいバージョンへの変更の際に、購入者側でカスタマイズしたものを除く部分でも都度子テーマ内の記述の変更が必要なのであれば、必要個所を事前にお伺いすることでローカル環境にて子テーマを最新の親テーマに対応できるように修正できるかと思い、
そうであれば、親テーマのアップデートに伴い、子テーマで修正が必要な個所をすべて（購入者側でカスタマイズした部分を除く）教えていただくことは可能でしょうか？
と質問させていただきました。（### 本番環境への反映の4番の手順でエラーが出てサイトが表示できないことを防ぐため）
長々と恐縮ですが、いかがでしょうか？
いいねをした人: 居ません「していかなければならない」と強制するものではありませんが、カスタマイズをおこなう場合はテスト環境を用意したほうが良いというのは一般的な認識だと思うので、僕もテスト環境を用意することを推奨しています。
カスタマイズする場合についての質問ではなく、テーマをアップデートする場合の質問ととらえていただけますと幸いです。
いいねをした人: 居ません前提として、Snow Monkey ChildはSnow Monkeyのテーマには不要なもので、
「Snow Monkey を動作させるため」には必須ではありません。
他のテーマの場合、テンプレートを上書きする場合には子テーマが必須です。
Snow Monkey は子テーマがなくてもテンプレートの上書きや出力される HTML を書き換えることができる機能があるので子テーマは必須ではありません。必須ではない、という意味で言えば不要ですが、にテンプレートの上書きをする場合は「一般的には」子テーマでおこなうものなので、Snow Monkey 独自の方法を使わずに、自分がわかりやすい方法でやりたいということで子テーマを使われる方はいらっしゃると思います。そういう意味では、子テーマも使えるようにしておく、という意味では不要とは言い切れないです。
Snow Monkey公式が作ったものではないので関与しません（ただし善意で相談には乗りますよ）ということなのでしょうか？
基本的にはそのようなスタンスになります。
細かく言えば、子テーマを使わずに Snow Monkey をカスタマイズするための My Snow Monkey プラグインは僕がつくって公開しているものですが、そこにユーザーさんが独自に追加したコードについて僕が責任を負うことはありません（制限なくなんでも自由に書けるから、そもそも負うことができません）。だから「Snow Monkey 公式が作ったものではない」から、というよりは、「ユーザーさんが独自に追加したファイルやコードだから」というのがより正確な表現になります。
購入者側でカスタマイズしたものを除く部分でも都度子テーマ内の記述の変更が必要なのであれば、
前述したように、ユーザーさんが独自に追加したファイルやコードはカスタマイズになります。僕にはなぜそのファイルを追加したのか、そのコードを書いたのかはわからないので…。また、「都度」変更の必要はありません。変更しなければならいときだけ変更することになります。
繰り返しになりますが、「Snow Monkey Child から不要（= 上書きする必要がない）なファイルを削除する」のが先決だと思います。もし必要なファイルが少しだけなら変更作業も減らせることになります。
どこをカスタマイズ（Snow Monkey からファイルをコピーしてきて書き換え）されたかはご自身がわかっていると思うので、前述の手順で作業をおこない（手順はあくまで「僕ならこうする」というものなのです）、Snow Monkey Child から不要なファイルを削除してみてください（もとに戻せるように必ずバックアップは残しておいたほうが良いです）。いいねをした人: 居ませんたびたび恐縮です。
子テーマとカスタマイズ部分の件については承知いたしました。言葉たらずで恐縮ですが、
「購入者側でのカスタマイズがまったくされていない場合でも、テーマのアップデートの際にファイルの更新が必要な個所を教えてください。」
というのが質問の意図でした。
購入者側でカスタマイズが全くされていない場合は、エラーを1つずつ修正していく必要はないということでしょうか？
いいねをした人: 居ません購入者側でカスタマイズが全くされていない場合は、エラーを1つずつ修正していく必要はないということでしょうか？
全くされていない場合は必要ありません。
ただ、アップデートにバグが含まれている場合、かつ、そのバグを修正するアップデートも実行できない場合は、管理画面からのワンクリックアップデートではなく zip ファイルアップロードによるアップデートをお願いする、のような対応をお願いすることはあり得ます。
あと、ブロックについてはプラグインやテーマのアップデートだけでは HTML 構造をアップデートすることができない（WordPress の仕様）ため、ブロックの HTML 構造のアップデートが必要な場合は、プラグインやテーマのアップデートの後にページの編集画面を開き、更新ボタンを押してください（WordPress の仕様で、編集画面を開いた段階でそのページ上のブロック HTML 構造がアップデートされる）、とご案内することもあり得ます。
テーマのアップデートの際にファイルの更新が必要な個所を教えてください。
アップデートのたびに、どの箇所に変更や修正が入ったか、お知らせ記事を書いています。
例えば、v14.0.0 へのアップデートの場合、
Framework\Helper::has_category_thumbnail()が廃止されてFramework\Helper::has_term_thumbnail()に変わることを案内しています。なのでアップデート前に記事を確認して、独自に追加しているコードの中でFramework\Helper::has_category_thumbnail()を使用している場合はFramework\Helper::has_term_thumbnail()に書き換える必要があります。また、Snow Monkey テーマと Snow Monkey Blocks などのプラグインは全てのコードの変更履歴を GitHub で公開しています。お知らせ記事に全てのコードの変更履歴を書くのはわかりにくいので概要を書いていますが、独自のゴリゴリにカスタマイズしている場合は概要だけでは必要な全てがわからない場合がありえます。そういう場合は GitHub の変更履歴を見ると細かいところまで全て確認できます。
※右側の「745d533」などの英数字の羅列の部分をクリックすると、その時点のコードレベルでの変更履歴が確認できます。
いいねをした人: 居ません
- このトピックに返信するにはログインが必要です。