3.0.3→3.0.4
3.0.4→3.0.5
にアップデートする為に【アップデート方法】が記載されていますが、そのページの【マイグレーションガイド】が404で見れなくなっています。

初心者のため、マイグレーションという言葉が初めてで、これが分からないと、EC-CUBE3は使えないのでしょうか？

現在は3.0.3で無事サイトは使えております。

3.0.3で変更した箇所は
CSSの変更、ブロックの新規追加と既存ブロックの編集、ページの新規追加と既存ページの編集ぐらいです。
それだけなら、下記のディレクトリを上書きと、変更差分するぐらいではダメなのでしょうか
src/
html/
vendor/

今後のため【マイグレーション】の詳しい仕方も教えていただけると助かります

引用：

いやいや、多分マイグレーションガイドは

http://ec-cube.github.io/migration.html

…なんですが、これは開発者がテーブル設計変更したりした場合
それらの反映用にファイルを準備したり、
コマンドラインから各種操作をするための手順を
ドキュメント化したものなので…

単純にテンプレート変えたり
プラグイン導入したり、ソースコード少し変えよう、
とかそういうレベルでの使用を考えている人の場合は
知っていればなお良いけど必須というわけではない、です。

ひとまず、バージョンアップ前後の
「doctorine_migration_versions」テーブルのレコード変化と
「src/Eccube/Resource/doctrine/migration」フォルダ内のphpファイル群
両方突合せつつ眺めていると何やっているかはわかってくるかも。

少しカスタマイズしようかな、というくらいの人ならば、
今はその辺りの仕組みは置いておいて、アップデート方法のなかにある

http://インストール先/install.php/migrationにアクセスしマイグレーションを実行
html/install.phpを削除

で、バージョンアップ時のマイグレーション作業は終わってますので、
マイグレーションまわりのしくみは追々勉強する、で良いのでは？

ただ、初心者と言っても、これらの作業をする前に
・現在のプログラムフォルダを手元にコピー
・データベースをバックアップ
はやっておいて、問題が起きた場合に元に戻したり、
バージョンアップ前後の内容を比較して原因を特定できないまでも
この辺が怪しいとかアタリをつけられた方が無難かと思います。

できれば、バックアップした一つ前の状態を
手元のパソコン等にセットしておくと、バージョンアップの時に
前後で挙動が変わった際などに曖昧な記憶でなく、明確に
「バージョンアップ前と後でこういう風に違っている」と
確認・質問できて良いかと。

とても丁寧な回答ありがとうございます

少しずつikemotoさんのアドバイス通り
データベースの「doctrine_migration_versions」や migrationフォルダの中身など見ていきたいと思います。

データーベースとサイトのバックアップはしているので
勉強も兼ねバージョンアップ前後の内容の比較なども見ていきたいと思います


そてで、先ほど

http://インストール先/install.php/migrationにアクセスしマイグレーションを実行

をしてみたところ

【EC-CUBEのマイグレーションが完了しました。】

と出たのですが、
画面の上の方に【Warning...】と出ていました。

これでもマイグレーションが無事完了しているのでしょうか？

マイグレーション後、サイトはフロント、管理画面とも大丈夫そうです

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Warning: ini_set(): A session is active. You cannot change the session module's ini settings at this time in /home/users/2/サイト名/web/shop/vendor/symfony/http-foundation/Session/Storage/Handler/NativeFileSessionHandler.php on line 56
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー



それで、NativeFileSessionHandler.phpを見てみたのですが、
何か書き加えたり、編集が必要なのでしょうか？

無知な質問ばかりで本当にすみません
どうかアドバイスをお願いいたします



ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
<?php

/*
* This file is part of the Symfony package.
*
* (c) Fabien Potencier <fabien@symfony.com>;
*
* For the full copyright and license information, please view the LICENSE
* file that was distributed with this source code.
*/

namespace Symfony\Component\HttpFoundation\Session\Storage\Handler;

/**
* NativeFileSessionHandler.
*
* Native session handler using PHP's built in file storage.
*
* @author Drak <drak@zikula.org>;
*/
class NativeFileSessionHandler extends NativeSessionHandler
{
/**
* Constructor.
*
* @param string $savePath Path of directory to save session files.
* Default null will leave setting as defined by PHP.
* '/path', 'N;/path', or 'N;octal-mode;/path
*
* @see http://php.net/session.configuration.php#ini.session.save-path for further details.
*
* @throws \InvalidArgumentException On invalid $savePath
*/
public function __construct($savePath = null)
{
if (null === $savePath) {
$savePath = ini_get('session.save_path');
}

$baseDir = $savePath;

if ($count = substr_count($savePath, ';')) {
if ($count > 2) {
throw new \InvalidArgumentException(sprintf('Invalid argument $savePath \'%s\'', $savePath));
}

// characters after last ';' are the path
$baseDir = ltrim(strrchr($savePath, ';'), ';');
}

if ($baseDir && !is_dir($baseDir)) {
mkdir($baseDir, 0777, true);
}

ini_set('session.save_path', $savePath);
ini_set('session.save_handler', 'files');
}
}
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

エラーの内容自体は、セッションスタートしているのにセッションの設定を変更しようとした場合に出るパターンだったと思うのですが…

マイグレーションが無事完了しているかどうかは、マイグレーション自体は「migrationフォルダ」の中でまだ処理していない分を適用しているはずなので、前回と今回のを比較して、追加されている分のマイグレーションファイルに書かれているテーブルやカラムの変更が実際にデータベースに反映されていれば問題ないと思います。

お忙しいところ、回答大変ありがたく思います


ikemotoさんのアドバイスのおかげで、なんとなくマイグレーションというのが、少しわかったような気がします。

前回と今回のバージョンで「migrationフォルダ」の中身の変更が、
データベースに反映されていれば大丈夫そうなのですね

3.0.3→3.0.4のバージョンアップはしたのですが
3.0.4→3.0.5のバージョンアップは、ファイルが増えていることもあって、まだしていないのですが、
もう少し前回アドバイスをいただいた事や、今回のアドバイスも含めて、色々見てからバージョンアップをしてみたいと思っています。


初心者の私にも理解できる良きアドバイス、本当にありがとうございました
本当に助かりました！

この辺、自分の方で確認していなかったので推測で回答していましたが…
本日、私の方もバージョンアップ作業をしまて、特にワーニングも出ずにサクっと終わりました。

１：ローカル環境にサーバーのバックアップを復元してテスト(Win8+XAMPP環境)
２：実際にサーバーにて実行（サーバー：さくらインターネット共有サーバー）
の順ですが、両方ともOK。

異なる点と言えば、
　・3.03からダイレクトに3.05に（3.04は飛ばした）
　・ソースコードはGitHubで管理・更新している
…の２点くらいでしょうか…

3.0.5にする際、一度ローカルに
　A:3.0.3時のサーバー環境復元
B:3.0.4時（現在）のサーバー環境復元
を行って、どちらも3.0.5にアップグレードしてみて

・Aの時にワーニング出ないか見てみる
・AとBのテーブル・フィールドリストを出力して差分ツール等で確認
などチェックしてみると良いかと思います。
もし無事完了していない場合、ハッキリ差が出ているはずですので。

※カスタマイズやバージョンアップの時は、ローカルにサーバーの環境を復元してテストしてからサーバーに反映した方が、何かあった時に慌てずに済むのでおすすめ（というかリスクを考えるとほぼ必須に近い…）です。

ご連絡ありがとうございます

早速私の方でもやってみましたのですが、


★3.0.3→3.0.4アップグレード
ワーニングあり

★3.0.4→3.0.5アップグレード
無事完了でした
データベースの「doctrine_migration_versions」も更新されていました
3.0.4の時の管理画面の【商品マスターから検索結果の不具合や】、
フロントの【商品検索結果の表示結果の不具合】などなど
色々改善されていたこともあって、アップグレードは成功したのではと思っております


どちらもアップグレードの仕方は同じ作業で、フォルダの更新、【appフォルダ】の更新ぐらいでした


3.0.3→3.0.4でワーニングが出たので、
素人ながら、サーバーの問題か、インストールの失敗か疑問に思っていたのですが

その環境のまま、
3.0.4→3.0.5にアップグレードしたら、難なく成功ということは、
私が、
3.0.3→3.0.4のアップグレード時のミスなのか...と疑問が湧いてきます


ですが、
マイグレーションのやり方も、ikemotoさんのおけげで理解できましたし、
3.0.5に無事アップグレードできて、出来る事が分かっただけでも、前に進む気になります
ご教示、ありがとうございました。