|
1からまでを表示 (計21) |
|
ご返信ありがとうございます。
ブロックを追加でデフォルトで入っているもののみマイグレーションツールで移行可能で、どのような形であれデフォルト以外のブロックはマイグレーションツールをそのまま利用する限りでは移行不可能ということですね。
リンクも拝見しました。十分に理解できてはいないのですが、自分で制作したブロックを一つずつマイグレーションツールに登録するようなイメージかなと思います。
マイグレーションについては5.6系が完全に終了するまでの間にスムーズに移行できればと思っています。完全に終了することはしばらくはないとのことなので、こちらとしても焦ってはおらず、しっかりと準備などしていきたいと思います。
自分のサイトで移行時にエラーが出たとしても、良くはないのですが、被害は少ない、クライアント様のところではそうしたエラーをできれば完全に回避したいなと思っております。
手順につきまして年明けで大丈夫ですのでご紹介いただければありがたいです。
●Cloud9でのマイグレーションツールの利用について
xmlファイル読み込み時にエラーが出るのは変わらないのですが、先日WordPressでxmlファイルをインポートする機会があり、それは成功しました。
ということはマイグレーションがそもそもできないのではなく、インポートするxmlファイルの記述に何かしら5.8やCloud9と相性の悪い部分があるのかもしれませんね。参考までに。
Posted on 12月 27, 2017 at 11:33 午前
|
|
遠藤さま、ご返信ありがとうございます。
もちろん、フォーラムの趣旨も理解したうえで質問させていただいているつもりです。
言葉が過ぎていることも承知です、申し訳ありません。
遠藤さまだけでなく、フォーラムの皆様の気分を害していることは本当に申し訳なく思います。
私としましては長くこのツールを使っていきたいと思っております。スクリプトは皆様がご存知の通り日進月歩で変わっております。そんな中で5.6系がいつまで耐えられるのか?、非常に危惧するところです。
このツールは素晴らしいもので、コードについて今一つ理解ができていなかった私のようなものでも思ったレイアウトがほぼ再現できる点で、私は気に入っております。
どんなに私のスキルが上がっても、悪意のある方がスクリプトを使った場合、私程度のレベルでカスタマイズを行った部分は赤子の手をひねるより簡単に改ざんが可能であろうことは自分がよくわかっているつもりです。
5.7から5.8へどんどん使いやすく進化しているメリットを現在5.6系のマイグレーションで止まっているのは非常にもったいなく思っております。
2014年でしたか、もう3年が経とうとしています。マイグレーションを行うのはサイトを管理されている方のご意志ですが、いつでも思い立った時にできるようにしておくことがやはり必要ではないでしょうか。
フリーの、オープンソースのソフトにそこまで求めるな、と言われれば、それまでかもしれませんし、それを選んだのは私の責任、それもわかっております。
でも、そうやって言って過去バージョンを切り捨てていくことは簡単なのですが、影響が大きすぎませんか? 多くの方々に支持されてきた資産、、マイグレーションができないという理由だけで捨てるのはあまりにももったいない気がしてなりません。
そういった意味におきましても適切にアップグレードできるよう、個々の環境まで踏み込むまでは難しいまでも指針というか、ガイドラインというか、基本こうすることでアップグレードができる、個々の環境で難しい部分はフォーラムで共有しようといった流れがあるとありがたいです。
Posted on 12月 21, 2017 at 7:44 午前
|
|
マイグレーションにつきましては全く動作しません。
変わらずInternal server errorが出るのみ。また、ファイルアップロードをしても動作せず、マイグレーションツールのトップに移動するとファイルは正常にアップロードされました。とアラートは出るものの、何のアップロードもありません。
他のサイトでブロックがあらかじめ入っている必要があるなどの記述を見つけたので、5.6に入っているブロックを入れてみたところエラーが出て動作しません。
ところで、調べているうちに下記ページを見つけました。
http://www.concrete5.org/community/forums/customizing_c5/5.6-to-5.8-migration-strategy/
これによるとカスタムブロックはマイグレーションされないとのこと。
ということは、5.6系でDesigner contentで作成したブロックはマイグレーションできない、ということでしょうか。
これって大問題ではないですか。
だとしたら、移行は完全に不可能ということになります。
レスポンシブ対応をさせるために作成したブロックを全て内容も含めて移行???
考えただけでもぞっとします。そのための時間を割くことなど到底不可能です。
他に利用されている方はこの件はどうなっているのでしょうか???
適切に運用できているのでしょうか?????
全く持って何のためのアップグレードなのか、ツールなのか、意味が分かりません。
正しい手順を持って適切にマイグレーションできるようにしていただけないでしょうか。
今はまだサポートが切れないのでいいとはいえ、内部で使用しているスクリプトが古くなるとそれだけセキュリティ面でも影響するかと思います。
もしこのままマイグレーションできない状態を続けるのならConcrete5そのものを捨てる以外に方法がなくなります。そうなると、クライアントに提供してきたものを全て入れ替えるなどという恐ろしい事態が発生します。
当然のことながら責任上、全て私が無償で総入れ替えを行わなければなりません。フリーツール、オープンソースファイルの宿命、と言ってしまえばそれまでですが、実績があるからこそ使用してきたツールだけに残念というほかはありません。
適切にアップグレードができるよう、対策はできないのでしょうか。
ご意見をいただければ幸いです。
ご意見をいただき、適切にアップグレードができるようになるまで、こちらのマイグレーションは凍結せざるを得ません。残念です。
Posted on 12月 20, 2017 at 4:49 午後
|
|
ご回答ありがとうございます。
今のところエラーばかりで成功事例がないので試してみないとわからないのですが、、、
マイグレーションした環境をそのまま移す、ということはマイグレーションに使用した5.8のファイル一式をFTP等で現行のファイル群の中にそのまま上書き保存する、ということになりますね。もちろんデータベースの設定などは変更する必要がありますが、、、
Cloud9の問題が解決しないことには前に進まないのですが、開発環境では5.8のデータベース構造にリメイクされているので動作はするのですが、本番環境ではファイルは5.8になってもデータベースがそのままになってしまうので、動作するように思えないのですが、、、
いずれにしても試してみます。
進展があったらフォーラムの中で連絡させていただきます。
Posted on 12月 18, 2017 at 9:40 午後
|
|
ご返信ありがとうございます。
アップグレードの手順につきましては同一のアドレスで運用する場合でもデータベースのリストアだけで可能、ということでしょうか?
5.6系から5.7(5.8)へはデータベースの構造だけでなく、一部フォルダ構成も異なっていると認識していましたので、既存のフォルダについては削除した方がエラーの可能性が減らせるかなとも思っていたものですから。
となれば、5.8(現状では5.7への移行は不要?)をupgradeフォルダに入れても管理画面で反応しないのですから、concreteフォルダを5.8のものに上書きする方法+データベースのリストアで5.8への移行は完了ということになりますね??
Cloud9につきましては引き続きトライしてみるとして、今一つ理解ができません。
もし、concreteフォルダの上書き+データベースのリストアだけでアップグレードが完了するなら、migration toolはデータベースの再構築をしているということでしょうか?
それなら、データベースの構造を変えるためのスクリプトをデータベース上で走らせるだけで済みそうですが、、、、なぜにこのような大掛かりになってしまうのか。。。
データベースだけの話なら既存concreteフォルダを上書きした時にデータベース関連のエラーが出てもよさそうなのに、ファイルの存在がないとか読み込みエラーとかおよそデータベースとは関連がなさそうなエラーが出ていたので、アップグレードそのものができないと判断しております。
結局、やめておいた方がよいという変な結論になりそうです。
そうなれば、Concrete5そのものを削除して別のCMSを適用する等の、これまた大がかりな、避けて通りたい手段になってしまいそうですね。
せめてツールが出ないなら、アップグレードについてきちんとした手順、ガイドラインが欲しいものです。
Posted on 12月 18, 2017 at 2:32 午後
|
|
いつもお世話になっております。
現在5.6.3.5を使用しています。
以前からmigration toolを利用して移行しようとしていますが、失敗続きです。
現状、慌てて行う必要はないとのトピックがありましたので、深刻ではないのですが、他にも移行するサイトがあるので今に至るまで手順など模索している段階です。
現在運用している5.6サイトからのエクスポートはうまくいきました。
新しいサイトへのインポート手順について
1. 5.8(migration toolを5.7でインストールするとエラーが出るので)を構築した開発環境にインポート
2. データなどの微調整を行いデータベースのバックアップをダウンロード
3. 現在運用しているサイトはすべて削除して、5.8をインストールし直す
4. 開発環境のデータベースのバックアップを運用するサイトにリストアする
こんな感じでしょうか?
5.6サイトに5.8をupdateフォルダに入れても反応せず、concreteフォルダを上書きしても当然ながらエラーが出ますのでこのような手順しか考えられないのですが、これで会っていますでしょうか。
現状のサイトを維持しながらアップデートできるようにはならないのでしょうか。
上記方法で合っていると仮定します。
現在開発環境としてCloud9を利用しています。
5.8のインストールまではできており、migration toolのインストールもできました。
バッジを作成してxmlファイルをインポートすると「Load error! (Internal Server Error)」と出てしまい、Computing Batch Statusと表示されてLoading画像がくるくる回っています。
Internal Server Errorと出ている以上、こちらとしては手の出しようがないように思います。
Cloud9でのmigrationはできないとあきらめてxampp(私はwindows7環境)で時間をかけて構築するよりほかはないのでしょうか。
確かにシステムを刷新していくことは必要でしょうし、そのため後方互換を切り捨てざるを得ない事情もあるのでしょうが、もう少しわかりやすい方法でアップグレードできるようにならないのでしょうか。
今回の一連の作業にしても、Youtubeの動画を見いたらバッチを適用してエラーがでても、大したことが無い風で直して見えるようでしたが、migrationtoolなどの情報がどこにもなく、断片的な日本語と英語の情報をつなぎ合わせてやっとここまでできました。
長文で申し訳ないのですが、
1.アップグレードの手順があっているか
2.Cloud9でのmigrationは可能なのか
3.今後、アップグレードのツールとして簡便なものはできないものか
をお答えいただければ幸いです。
よろしくお願い致します。
Posted on 12月 17, 2017 at 5:54 午後
|
|
自己レスです。
あれからhissyさんの言葉をヒントに調べたところ、concrete/models/…にあるadd_subpage.phpは正常だったのですが、concrete/core/…にあるadd_subpage.phpに問題がありました(ファイルに何も記述がありませんでした)。そこで、再度5.6.3.3をダウンロードし、この部分のadd_subpage.phpに上書きしたところ「サブページを追加」の項目が無事に復活し、権限が設定できるようになりました。
何とかこれでクライアント様が編集できる状態にできそうです。
ありがとうございました。
Posted on 5月 25, 2015 at 2:49 午後
|
|
hissyさんご連絡ありがとうございます。
add_subpage.php は(クライアントのドメイン)/concrete/models/permission/access/list_items/custom/ にあり、
そこには
「<?php
defined('C5_EXECUTE') or die("Access Denied.");
class AddSubpagePagePermissionAccessListItem extends Concrete5_Model_AddSubpagePagePermissionAccessListItem {}」
と書かれています。
バージョンは5.6.3.3です。
対処法がわかりますでしょうか。
よろしくお願いします。
Posted on 5月 18, 2015 at 5:38 午後
|
|
いつもお世話になっています。
上級権限モードに移行後、各種権限周りを設定中にエラーが発生しています。
各ページの「権限」をクリックした後の表示やバージョンを表示、ユーザーとしてプレビューなどある画面の下、サブページを作成で「Fatal error: Class 'Concrete5_Model_AddSubpagePagePermissionAccessListItem' not found in (ファイルのアドレス) add_subpage.php on line 3」となり、設定の変更ができません。
該当ファイルでは末尾が{}となっており、ここが空であることが原因かなと推測はしたのですが、対処方法がわかりません。
クライアント様の環境でMySQLに入れない状態なので対応できる方法に制限はあるのですが、対応方法がありましたらお伝えいただけないでしょうか。
よろしくお願いします。
Posted on 5月 18, 2015 at 6:29 午前
|
|
なるほど、ありがとうございます。
サーバーエラーについてはログを取らない設定になっていたので設定を変更しました。エラーが判明するには、少し時間はかかりますね。とはいえ、設定関連のエラーでないとするとやはりスクリプト関連の衝突でしょうね。これまでも同様のサイトを作っているので、これまでとは違う点を外すなどして検証してみるほかはないですね。
エラーが出ているなら改めてこのスレッドで報告させていただきます。
ありがとうございます。
Posted on 3月 24, 2015 at 8:12 午後
|
