名古屋の悪口言ってたら治りました。
さぽーれは有るけどお金持ちは必要なものを必要なだけしか買わないから商品あんまり動かないんよな。



因みに404はURIパス的にはdefault_flame.twigを通っているので、ヘッダーやフッター、サイドバーが有る未だ可愛い方の404ですからね。



➊dtb_class_name
➋dtb_class_category
❸dtb_product_class


これらを確認して、自分の環境では今回一部の➊と➋だけ消した
状態でした。いずれにせよ❸は手を加えていなかったから逆算し
て考える事が出来、不正解だとは思うのですが最低限の状態に戻
せました。
復元しても良いのだけどソートがダブるのが気分的に嫌だったの
と件数がたまたま少なかったので手作業しました（非推奨。本当
はファイル作成してコマンド打ち込まないといけないんだろうけ
ども）


足りない（削除した）class_nameを作成するために、仮に
ec-root/admin/product/class_name　からレコードを作成して、phpmyadmin　から有るべきIDに採番しなおしてUPDATEしたら動く
ようになりました。とにかく現状が空なので何かしらレコードを作って正しく採番することが必要でした。EC-CUBEがIDを削除した
ら永久欠番の扱いのように一意になる採番設計だったので良かったです。



ポイントはbackend_nameの管理名がSQLでは順番として先に来る
ので（管理画面の入力フォームでは後になる）恥ずかしい名前が公
開されるのは要注意だと思いました。規格に関連する商品を複製の
上該当商品の紐づけを仮にして廃止にステータスを変更しました。（たぶん意味のない無駄な行為）



良く分からないのですがカートに入れるタイミング以降、そのあと
は、商品規格が外れても規格自体がテーブル上に存在すればエラー
にならない仕様なのでしょうか？なんだかそんな気がしました。商
品をカートに入れるまでがすごい厳格なイメージです。



自分は念のために、検証する時間が勿体ないのと臆病なのでもう少
し日を改めて落ち着いてから検証します。
月曜日から気分がハイになったので中日の水曜日当たりに鬱になり
ます。



自分が消した規格が、IDとしてテーブルに登録されているかどうか整合性が取れているか一番簡単な確認方法は、
admin管理画面から注文取消した受注情報についてあとから商品を沢山追加して送料無料とか割引あるなら送料再計算します。
フロントのマイページから過去注文履歴を見て、エラーにならなかったら雑におけだと思います。

あれ。規格取得の処理走るからカート閲覧出来たら雑におけなのかにゃ？