5.0.11の新規インストールを試しましたが
PHP Fatal error: Allowed memory size～ のエラーが出てしまいます。
memory_limitを128Mから、どんどん増やしてみても解消しません
私の環境構築で、どっかしくじったのかなぁ
5.0.10までと同じ環境を作ったつもりなんだけど…
【環境情報】
・baserCMSのバージョン：5.0.11
・レンタルサーバー名：Windows2022 (Hyper-V)
・使用テーマ：初期テーマ
・PHPスキル（自己評価）：少し出来る
php.iniで Xdebugを読み込むようにすると上記エラーは解決しました。
＃xdebugは、やっぱりいるんですかね？
読み返したら…そうですね。何処のエラーと書いていないですね。申し訳ないです。
php.iniのxdebug関係を全てコメントアウトして、STEP1の代わりに以下の作業を実施
C:\opt\curl\curl-8.6.0_1-win64-mingw\bin\curl -sS https://getcomposer.org/installer | C:\opt\php\php833nts_2\php.exe
cd /D D:\website\iis\test4\
set HOME=D:\website\iis\test4\composer\
C:\opt\php\php833nts_2\php.exe D:\website\iis\test4\composer\composer.phar self-update
cd /D D:\website\iis\test4\
set HOME=D:\website\iis\test4\composer\
C:\opt\php\php833nts_2\php.exe D:\website\iis\test4\composer\composer.phar update --ignore-platform-req=ext-xdebug
※最後の問い合わせは Y で
.envのコピー
"D:\website\iis\test4\config\.env.example" をコピーして
"D:\website\iis\test4\config\.env" として貼り付け
中身は
export SITE_URL="https://localhost/"
export SSL_URL="https://localhost/"
export ADMIN_SSL="true"
↓↓↓
export SITE_URL="http://127.0.0.1:4080/"
export SSL_URL="http://127.0.0.1:4080/"
export ADMIN_SSL="false"
STEP2移行は、BaserCMSの作法通り、Webから行って最後まで完了します。
その後の、サイトを表示するとエラーとなります。
php.iniのxdebug関連の設定を有効にして、アプリケーションプールをリサイクルして、サイトを開くと問題なく表示されます。
再度、php.iniのxdebug関連の設定を無効にして、アプリケーションプールをリサイクルして、サイトを開くとやはり表示されません。
上記の表示が行われない際には、phpのエラーが記録されています。
PHP Fatal error: Allowed memory size～
php.iniのmemory_limitを増やしても解決しませんでした。
（どっかで無限ループとか、巨大クエリとかあるのかしら？）
を参考にWindows 10にてIISでPHP8.2を入れてbaserCMS5.0.11を入れてみました。
別途リライトモジュールが必要でしたので、
からリライトモジュールを追加、web.default.configを参考にweb.config作成しました。
MySQLは choco.exe install mysql でMySQLインストールしています。
ご指摘通りbaserCMSインストーラからcomposerが動作しなかったので、コマンドラインでcomposerを実行してモジュール関連をインストールを行い、ブラウザでセットアップ続行してインストール。
最後エラーになるがこれもご指摘通り.envを手動でコピーしたところ、 XDEBUGはない状態、memory_limit 128Mでエラーも出ないまま、特に問題なく動作しているようでした。
ちょっと原因がわからないですね、、、
@kaburk さん
検証ありがとうございます。
＃rewriteモジュールは入れてます。
私もインストール直後は、管理画面もトップページも表示されるのですが、アプリケーションプールをリサイクルすると表示されなくなるのです。（500番エラー）
そこでphp.iniの以下の部分をコメントアウトして、アプリケーションプールをリサイクルすると問題なく表示がされるという感じです。
[xdebug]
zend_extension=xdebug
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_enable=1
xdebug.remote_autostart=1
※インストール時、およびインストール直後の確認時は、これらはコメントアウトしています。
xdebug.remote_portは、9003が正しいかもしれないけど…
@bon ちょっと整理しますね。
STEP2移行は、BaserCMSの作法通り、Webから行って最後まで完了します。
その後の、サイトを表示するとエラーとなります。
→ インストールはxdebugを有効にしても問題ない
→ エラーはトップページが対象
php.iniのxdebug関連の設定を有効にして、アプリケーションプールをリサイクルして、サイトを開くと問題なく表示されます。
→ xdubug on → 問題なし
再度、php.iniのxdebug関連の設定を無効にして、アプリケーションプールをリサイクルして、サイトを開くとやはり表示されません。
→ xdebug off → 問題あり
私もインストール直後は、管理画面もトップページも表示されるのですが、アプリケーションプールをリサイクルすると表示されなくなるのです。（500番エラー）
→ ここで矛盾がある。前述ではインストール直後問題があると書いてあったが、ここでは問題ないと書いてある。
「アプリケーションプールのリサイクル」というのは、IISの設定再読み込みのようなものですよね。
つまりリサイクルの目的は、xdebugの設定切り替え。
つまり、インストール云々関係なく、常時、xdebugが無効だとエラーになるということでよいでしょうか？
WebサーバーはIISということでよかったでしょうか？
もしそうである場合、IIS+xdebugの組み合わせに問題があるということになります。
@ryuring さん
私の書き方が悪いですね。
;[xdebug]
;zend_extension=xdebug
;xdebug.remote_host=127.0.0.1
;xdebug.remote_port=9000
;xdebug.remote_enable=1
;xdebug.remote_autostart=1
このようにコメントアウトして、始めます。
STEP1は、Windows環境では面倒だったので、手動でコマンドでインストールを進めます。
STEP2以降はBaserCMSの作法通り進めます。
インストールは完了し、BaserCMSのサイト画面や管理画面は正しく表示されます。
－－ここまで正常に思います－－
その後
IISのアプリケーションプールをリサイクルします。（ついでにサイトも再起動）
この結果 サイトトップは表示されず、管理画面も表示できません。
→サイトは500番エラー、管理画面は表示しようとしますが、DBを読めない感じです。
→PHPのログにはPHP Fatal error: Allowed memory size～が記録されています。
※元々xdebugはoffだったのですが、リサイクルによりサイトが正常に表示されなく
なったので、インストール時にxdebug的な何かが読み込まれてオンメモリー状態で
サイトが稼働していたのではないかと推測します。
その後に試しに、php.iniのxdebug系をコメントアウトして
IISのアプリケーションプールをリサイクルします。（ついでにサイトも再起動）
サイトも管理画面も正しく表示されます。
つまり、xdebugがoffだと何故かうまく表示されないという状況です。
＃書いていて思ったのですが、DBアクセス周りですかね。
＃また、条件を変えてインストールを試してみます。
@ryuring さん
xdebug有効時は、BaserCMSのdebug.log以外は記録されていません。
xbebug無効時は、BaserCMSのdebug.log、error.log、PHPのphp_erro.logが記録されています。
xdebug無効時debug.txt (142.5 KB)
xdebug無効時error.txt (1.1 KB)
xdebug無効時php_errors.txt (1.0 KB)
xdebug有効時debug.txt (149.3 KB)
@bon ありがとうございます。ログを見たところ、ツールバーでエラー処理の無限ループとなる箇所がありましたので修正してみました。
もしかしたら、無限ループでメモリーオーバーとなっていた可能性があります。
@ryuring さん
ご対応ありがとうございます。
ダメでした…
エラーログを添付しておきます。
debug.txt (142.5 KB)
error.txt (1.1 KB)
php_errors.txt (1.0 KB)
@ryuring さん
何か、本当にすいません(^_^;)
前回と併せて都合、３箇所直してみましたが、やはりエラーとなります。
＃全然、内容とは関係ないことですが
＃この３箇所だけタブでインデントされてたので編集された時期が違うのかな
debug.txt (142.5 KB)
error.txt (10.1 KB)
php_errors.txt (1018 バイト)
＃Ubuntu環境を構築して検証したいのですが、環境構築ではまり中。
@bon ありがとうございます。メソッドだけじゃダメそうですね。
もう少しお付き合い頂けますでしょうか。
toolbar.php の 2行目あたりで次のコードを書くとブラウザにどのように表示されるでしょうか？
var_dump($this->getName());exit();
return;
@ryuring さん
私でよければ、いくらでも付き合います 
１の結果です。
string(5) "Pages"
２の結果です。
サイトも管理画面も表示されます。
phpもBaserCMSのエラーログは、何の記載もありませんでした。
debug.txt (143.9 KB)
@bon ご協力ありがとうございます。
ツールバーが影響しているということはわかりましたが、原因がいまだはっきりしませんね ^^;
１点気になるのは、エラーログに次のように AppView に対して dispatchLayerEvent() がないといってること。
Call to undefined method App\View\AppView::dispatchLayerEvent()
AppViewには、dispatchLayerEvent() が存在しないのでそのとおりなのですが、私の環境の場合、同じ場所で存在しないメソッドをコールしてエラーを出してみると次のように、BcFrontAppViewが対象となります。これが正しい仕様です。なぜ、AppViewに切り替わっているのかが分からない状況です。
Call to undefined method BaserCore\View\BcFrontAppView::aaa()
もしかしたら、何かしらのエラー(1)が発生してエラー時にツールバーが呼び出されると、BcFrontAppViewが適用されず、ツールバーでエラー(2)が発生するのかなと思っていました。
そしてエラーの無限ループに突入してAllowed memory sizeのエラーにつながるのかなと。
ですが、ツールバーを return で呼び出さないと正常に画面が表示され、エラー(1)も発生してない様子という事で、暗礁に乗り上げた感じです。。。
ちなみに、次のようにして変更して画面表示にどういう変化があるか試して頂けますか？
var_dump($this->getName());exit();
↓
var_dump($this->getName());
var_dump(get_class($this));
return;
@bon むー、、、BcFrontAppViewが表示されてますね、一旦、手詰まりになってしまいました。
ちなみに、debug.txt に記載されているWarningは、PHP8.2 特有のものになり、今回の事象には関係ないと考えています。こちらの環境でPHP8.2の環境を作りためしたところ、Warningは同様に発生していますが、xdebug off でも、画面は正常に表示されています。
こちらのWarningは、次のバージョンで改善される予定です。
Copyright (C) baserCMS User Community All rights reserved.
