1からまでを表示 (計11) |
tomoyaさん、hissyさん、引き続き対応策の模索並びに紹介ありがとうございます!
今回バージョン5.6.0.2へアップグレード予定なので、hissyさんの移行スクリプトを検証してみたいと思います。
(バージョンアップ前にインストールする必要があるとのことなので、少し時間がかかりそうですが…)
このスクリプトがうまく使えればバージョンアップをためらってる方々に順次以降に踏み切れそうな気がしますね。
Posted on 3月 01, 2013 at 11:34 午前
|
tomoyaさん、ご丁寧に回答していただきありがとうございます。
曖昧な理解だった部分がだいぶスッキリしました。
やはり基本は手作業によるスタックへの引き継ぎなのですね。
大規模なサイトではアップグレードそのものが現実的ではないようです。
2に関しては5.4.2.2から段階を経て5.6.0.2へアップグレードした私の環境では、スクラップブックに登録していたブロックが多数(全て?)クリップボードに格納されていました。
ただし、一部のブロックは「このブロックは使用不能です。」と表示され、削除する以外どうしようもない状態になっていましたが…
ちなみに、DetaDisplayというアドオンは導入していません。
なんにしても、以前のスクラップブックを継続して利用はできないことがはっきりしたので諦めが付きました。
PHPブロックを使った対応法は是非利用させていただきたかったのですが、5.5.2.1までしか更新が反映されないのですね…。
以前5.5.2.1にXSSの脆弱性が報告されたので5.6.0.2にしたという経緯があるため、利用はできませんが大変参考になりました。
今後の本家の動きにも注目したいと思います。
ほんとうに色々とありがとうございました。
Posted on 2月 25, 2013 at 12:00 午後
|
度々お世話になっております。
5.4系まで利用していたスクラップブックが、5.6系でどういう扱いになるのか理解しきれていないので確認させてください。
1.表示はされるがグローバルブロックではなくなる
2.グローバルブロックとしては扱えないが、全てクリップボードに格納されており、クリップボードからペーストができる
3.今までのグローバルブロックと同様の利用をするには新規でスタックを作るかグローバルエリアを設置する必要があり、手動で置換するしか方法がない
上記の認識で合っていますでしょうか?
利用しているスクラップブックが非常に多いので、今までのスクラップブックを何とか引き続きグローバルブロックとして利用したいのですが、なにかいい方法はありませんでしょうか?
よろしくお願いします。
Posted on 2月 21, 2013 at 2:19 午後
|
hissyさん、taoさん、ご返答ありがとうございます。
データベースについては現在InnoDBを利用しており、既に最適化はしている状態です。
クエリキャッシュは過去にも増やしたことがあるのですが、改善が見られないので、これ以上の効果は見込めないように感じます。
APCについては導入自体はできそうです。
phpコードのキャッシュを行うモジュールというのは理解しましたが、導入に際して注意事項などあればご教示いただきたいです。
APCの利用においてはアンケートブロックやview.phpファイルのオーバーライドなどカスタムを行う必要はないという認識で間違いないでしょうか?
Posted on 2月 18, 2013 at 11:11 午前
|
現在5.4.2.2で、大規模なサイトを運営しているのですが、ページの多くに公式ブロックによりアンケート(このページの情報は役に立ちましたか?という趣旨のもの)を1ページあたり2ブロック挿入しています。
アンケートを挿入しているページ数が多すぎるのか、http://【base_url】/dashboard/reports/surveys/view/を開こうとすると、表示に非常に時間がかかります。(おおむね2〜3分程度)
全部で2000ほどアンケートがある状況なので、一覧を生成するのに時間がかかっているのではないかと推測しているですが、一度に表示されるのは10件なので、この辺りなんとか表示を高速化させられないでしょうか?
どなたか知恵をおかしください。
よろしくお願いします。
Posted on 2月 15, 2013 at 3:25 午後
|
ありがとうございます。
5.3系から5.4系にアップグレードする際、Concreteフォルダに直接データを書き込んでいた記憶があるので、今回も上書きされているものだと思い込んでいました。
updates/concrete5.6.0.2.ja/concreteフォルダから該当ファイルをコピーしたら正常に動きました。
大変お騒がせしました。
Posted on 2月 15, 2013 at 2:34 午後
|
解決しましたので報告させていただきます。
結論から言えば、themes内にlogin.phpが存在していたのが原因でした。
昔Concrete5の仕様の理解が不十分なときにカスタマイズを行い、こんな場所に作ってしまったのだと思います。
5.4.2.2では上記の状態で問題なく動いていたので、完全に盲点でした。
てっきりバージョンアップにまつわる不具合だと思って投稿してしまいましたが、こちらの間違ったカスタムが原因でした。お騒がせして申し訳ありませんでした。
そして、助言いただいたacliss19xxさん、hissyさんありがとうございました!
Posted on 2月 15, 2013 at 12:07 午後
|
先日、既存サイトの5.6.0.2へアップデートを行ったのですが、オーバーライドや自作しているブロックが多く、エラーの頻発に苦労しています。
現在、サイトマップから新規ページを作成しようとすると、以下の様なエラーが出る状況です。
Fatal error: Call to undefined method Page::getAllowedSubCollections() in /xxx/xxx/xxx/public_html/elements/collection_add.php on line 40
/Concrete/elements/collection_add.phpと見比べましたが、該当行に変更はなく、試しに現在のファイルをリネームして、オーバーライドを外したところ正常に動作しました。
ただし、/Concrete/elements/collection_add.phpを/elements/内にそのままコピー(同じファイルをオーバーライド)してもやはり同様のエラーが出ます。
elementsフォルダの中身はオーバーライドできなくなったのでしょうか?
切り離して考えたほうがいいのかもしれませんが、メソッドが定義されてないとのエラーなので、フォーラムで以下のスレッドを参照させていただいていたところ、こちらの5.6.0.2環境にはconcrete/coreフォルダ自体が存在しませんでした。
http://concrete5-japan.org/community/forums/development/post-5795/
これは存在するのが正常な状況だと思うのですが、上記エラーと何か因果関係はありますでしょうか?
色々調べたのですが、手詰まりの状態なので、どうぞご回答よろしくお願いします。
Posted on 2月 14, 2013 at 2:54 午後
|
説明が不足しており申し訳ありません。
カスタマイズについては1,2どちらも行なっています。
1.については助言の通り環境情報を確認したところ、ちゃんとsingle_pages/login.phpが含まれていました。
これでオーバーライドが正常にされているかどうか確認できるのですね…初めて知りました。
今回single_pages/login.phpのデータを削除しても解決しなかったので、login.php本体の問題というのは可能性が低い気がします。
2.については一度改めてview.phpに問題がないか確認してみたいと思います。
何かわかりましたら追ってこちらに報告並びに相談させていただきますので、よろしくお願いします。
Posted on 2月 13, 2013 at 6:38 午後
|
返答ありがとうございます。
元々サイトキャッシュの機能は全てオフにしていましたが、念のためクリアしてみました。
しかし症状は変わりませんでした…。
オーバーライドを外して未ログイン状態でhttp://【base_url】/dashboard/ にアクセスすると、ちゃんとConcreteフォルダ内のlogin.phpを読んでくれます。
http://【base_url】/login/ だけが挙動がおかしいので困ったものです。
Posted on 2月 09, 2013 at 11:29 午前
|