キタジマさん
アドバイスいただきありがとうございました。
教えていただいたとおりに入れ直しましたら、Warning消えました！
ありがとうございました！
@aoimiya さん
うーん、なんでだ。。とりあえずもう一回 beta3 入れ直してみましょうか。管理画面に入ってもらって、外観 > テーマの編集 > スタイルシート、と開いてください。すると、5.1.0-beta3 となっていると思うので、それを 5.1.0-beta2 に書き直してみてください。他の部分も変えちゃうと変になるかもなので、ここだけしか触らないように注意してください！書き換えたら、下のファイルを更新をクリックしてください。
ここまでできたら、ダッシュボード > 更新のメニューを開くと、再度 Snow Monkey の更新通知がでると思うので（しばらく立たないとでないかもしれません）、もう一度アップデートしてみてください。
ご報告ありがとうございます。僕のミスで余計なところにまで手を入れてしまい、
Warning: Invalid argument supplied for foreach() in /xxxxx/public_html/wp-content/themes/snow-monkey/vendor/inc2734/mimizuku-core/src/App/Model/Page_Templates.php on line 120
のエラーがでるようになってしまっていました。いまリリースした v5.1.0 beta3 か、本サイトのマイアカウント > ダウンロードからダウンロードできる snow-monkey.zip が v5.0.11 となっていますので、いずれかにしていただくと解消するかと思います！
こちらに書いていいのかわからないのですが、バージョン: 5.1.0-beta2に更新しましたところ、
ヘッダーというのでしょうか、そちらに管理画面、ブログの画面とわず、「Warning]表記がでてしまいました・・。
サイトはhttps://aoi2.jpです。
テーマはものくろさんに作っていただいた、子テーマです。
この間5.0にアップデートしたときに、表示されなくなり、キタジマさんにはその際にいろいろとおせわになりました。
以下表記です、全ページに表示されます。
Warning: Invalid argument supplied for foreach() in /xxxxx/public_html/wp-content/themes/snow-monkey/vendor/inc2734/mimizuku-core/src/App/Model/Page_Templates.php on line 120
Warning: Invalid argument supplied for foreach() in /xxxxx/public_html/wp-content/themes/snow-monkey/vendor/inc2734/mimizuku-core/src/App/Model/Page_Templates.php on line 120
Warning: Invalid argument supplied for foreach() in /xxxxx/public_html/wp-content/themes/snow-monkey/vendor/inc2734/mimizuku-core/src/App/Model/Page_Templates.php on line 120
Warning: Invalid argument supplied for foreach() in /xxxxx/public_html/wp-content/themes/snow-monkey/vendor/inc2734/mimizuku-core/src/App/Model/Page_Templates.php on line 120
M Tさん
もしかしてですけど、Snow Monkeyの4系からアップデートされた感じでしょうか？
その場合は、useの部分の構造が5系から変わってるみたいなので、
5.1.0beta以上の元のフォルダで、search.phpの中身を
<?php
use Framework\Controller\Controller;
Controller::layout( get_theme_mod( 'archive-page-layout' ) );
if ( have_posts() ) {
if ( $_GET['fe_form_no'] == '0' ) {
// /子テーマ/templates/view/search-form0.php をビューファイルとして読み込み
Controller::render( 'search-form0' );
} else {
// デフォルトのビューファイルを読み込み
Controller::render( 'archive', 'search' );
}
} else {
Controller::render( 'no-match' );
}
にしてみたら、上手くいかないでしょうか？
旧バージョンと互換性は無いようですので、他にも変更されているところがある場合はuse文をその都度変更されると上手くいくと思います。
テンプレートのカスタマイズは以前、ご教示いただいたのですが、serch.phpの中身を以下のように書き換え、検索結果によってオリジナルのテンプレートを読み込むようにしています。
<?php
use Inc2734\Mimizuku_Core\App\Controller\Controller;
Controller::layout( get_theme_mod( 'archive-page-layout' ) );
if ( have_posts() ) {
if ( $_GET['fe_form_no'] == '0' ) {
// /子テーマ/templates/view/search-form0.php をビューファイルとして読み込み
Controller::render( 'search-form0' );
} else {
// デフォルトのビューファイルを読み込み
Controller::render( 'archive', 'search' );
}
} else {
Controller::render( 'no-match' );
}
本サイトはこの状態だとマズイので、フォルダvendor/inc2734/mimizuku-core/
を旧バージョンのもので上書きし、元に戻りました。
同様の症状なので、テストサイトをご確認いただけますでしょうか。（認証はずしました。）
https://volunavi.xsrv.jp/
すみません、テストサイトのBASIC 認証を忘れていました。
すぐに返信をみられす、他の方の情報などで修正していただいたようですが、本サイトをbeta2にしたところ、ヘッダー部分に大量のエラーメッセージが出てしまいました。
（テストサイトで最初大丈夫だと思って本サイトを更新したのですが、テストサイトも後でみると同様でした。）
私だけのようで、テンプレのカスタマイズが関係しているのでしょうか。
私も細かなところを見ていこうと思いますが、もし分かりましたらご教示いただけますでしょうか。
サイト https://ohitorisama.site/
うおーもしかしたらアップデートが原因かもですね、すみません。。。
テストサイト、BASIC 認証がかかっていて確認できたかったので教えてほしいのですが、トップページは「固定ページを割り当てたページ」でしょうか？それとも、普通に記事一覧でしょうか？ あと、表示されないウィジェットエリアは「サイドバー」だけでしょうか。トップページ上部ウィジェットエリアとかもですかね？
倉本さま
返信ありがとうございます。
レンタルサーバーはロリポップをしようしております。
.htaccessですが、
RewriteBase /MAMP内の読み込みフォルダ名/
RewriteRule . /MAMP内の読み込みフォルダ名/index.php [L]
の部分のみ、フォルダ名を追加しました。
ちなみに、シングルサイトです。
もし、さくらのレンタルサーバーからMAMPへ移すなどであれば、
プラグインに「さくらのレンタルサーバー用の常化SSLプラグイン」があるかもしれません。
その場合は、該当のプラグインを移転後に停止(プラグインディレクトリから削除をして強制的な停止でも可)した上で.htaccessを変更しないと、別のサーバに移転する際には上記のようにcssやjsが読まれずにデザインが崩れてしまうと言うケースもあるようです。
さくらレンタルサーバーからのMAMPであれば、お試しくださいませ。
元々のサーバがさくらでない場合、可能でしたらサーバのサービス名など返答して下さると、その他の原因が解るかもしれません。よろしくお願いします。
参考:
キタジマさん
ありがとうございます。デベロッパーツールでエラーを見てみたところ、それだけが原因かはわかりませんがやはりSSLがひとつの原因のようです。
This site does not have a valid SSL certificate! Without SSL, your site’s and visitors’ data is vulnerable to theft and tampering. Get a valid SSL certificate before releasing your website to the public.
どうにもここまでもローカル環境とのいったりきたりで苦労をしてしまうので、あまり良くないかなという気もしています。
更新作業はサーバー上で行なった方が良いでしょうか？
スクリーンショットを見る感じだと、CSS ファイル（多分 JavaScript ファイルも？）の読み込みに失敗しているのじゃないかと思います。Chrome のデベロッパーツールの Console に何らかエラーがでていると思いますので見てみてください。
MAMP を使っていないので外しているかもしれませんが、https 化しているのが原因だったりしないでしょうか？Search and Replace for WordPress Databases Script を使っているのであれば、一度 https を http に置換してみると良いかもしれません。
結論から言うと、それはできません。
デザインスキンが現在のような構造になっているのには、2つの理由があります。
1つはデザインスキン制作の敷居を下げるためです。構造を固定化してしまうことで、書く場所に迷う、ということをなくしてしまい、なるべく多くの人がつくれるようにという意図があります。
もう1つは、カスタマイザーとの兼ね合いです。カスタマイザーでデザインスキンを選択するとプレビュー画面がリロードされてデザインスキンが切り替わる（加えてカスタマイザーの他の項目が選択できないようになる）という挙動になっているのですが、カスタマイザーのプレビュー画面に意図したとおりにデザインスキンを適用するには、どうしても wp_loaded 以降にフックして実行してやる必要があります。つまり、普通のプラグインはかなり早い段階のフックについても利用できますが、デザインスキンの場合は wp_loaded より後のフックからしか利用できないという制限があるのです。普通のプレーンな（my-snow-monkey.zip のような）プラグイン構造にしてしまうとその辺の制限が微妙になるため、ガチガチ目に構造を固定している、というのもあります。
そういうことで、デザインスキンの構造を自由化するのは難しいのですが、とはいえ、子テーマでやりたいようなテンプレートの書き換えなんかは wp_loaded 以降でもフックが利用ができるので、なるべく統合したいということでしたら、my-snow-monkey.zip（というか my-snow-monkey.zip はほぼほぼプレーンなプラグイン構造なので、何も制約はないので） に寄せるのではなく、デザインスキンに寄せてしまうほうがまとまりは良いのではないかと思います。
Macの時だけは、上手くいかないみたいです。
Macでそのまま解凍が出来ず、またMacでのLocalなどではWordPressであっても扱えないままでした。
しかし、レンタルサーバ側のWordPressだと上手くいき、制作チーム内のUbuntuでも解凍できるみたいです。WordPressの問題では無い気がします。
Macだけの問題かもしれません。
中身は見れたので私の方は問題無くなりましたが、Macで作業されている場合はそのまま解凍できないので、mac版のzipも作るか、デザインスキン同様にDropboxで上げれば解決するかもしれません。
Dropboxのzip機能は、ユーザーエージェントなどでzipを分けているらしく、各OSで上手く解凍できるzipを作ってくれるようです。
