phpやwpを使う際にuploadファイルの上限があることに気がつきました。 この設定をいじれば、上限が解放され、重たいファイルもupすることができるようになります。 Localで開発をしていると気づきにくいところですが、本番反映する時などには重要です。 php.iniを設定する phpの初期設定への変更を促すことができます。 サーバーの中からファイルを探して、 upload_max_filesize = 32M post_max_size = 64M memory_limit = 128M この辺りの設定を見直します。 upload_max_filesizeを変更する際に、32M(メガバイト)から128や256などにあげるといいかと思います。 その際には、必ずサーバーの再起動を忘れずにしてください。ただ単に記述するだけだと意味がないので。 再起動せずともできる方法はあるとは思いますが、再起動すれば間違いないと思います。 他には、.htaccessをいじるものもあります。 どの部分をいじったか、忘れないようにしましょうね。 参考： https://kinsta.com/jp/blog/increase-max-upload-size-wordpress/#htaccess

PHP8.1もまだリリースされていないというのに、早々とPHP8.2に導入される機能がひとつ決まりました。 導入というか削減ですが。 そんなわけで以下はPHP8.2のRFC、Deprecate partially supported callablesの日本語訳です。 Deprecate partially supported callables Introduction このRFCは、call_user_func($callable)でサポートされているが、$callable()ではサポートされていない構文を非推奨とします。 Proposal 以下の構文は、is_callableやcall_user_funcでは有効な構文ですが、$callable()には非対応です。 "self::method" "parent::method" "static::method" ["self", "method"] ["parent", "method"] ["static", "method"] ["Foo", "Bar::method"] [new Foo, "Bar::method"] このRFCでは、これらの構文をPHP8.2で非推奨とし、PHP9で非対応とします。 この構文はcall_user_func()やarray_map()等では非推奨の警告を発生します。 is_callable()やcallableは、サポートされなくなるまで非推奨の警告は発生しません。 通常のコールバック構文、function・Foo::method・["Foo", "method"]・[new Foo, "method"]はこのRFCによる影響はありません。 Discussion このRFCは、コールバックにおける二つの問題を解決しようとしています。 ひとつめは、callableの定義が矛盾している現状を解決することです。 最近はコールバックには$callable()を使うことが推奨されていますが、実際にはcallableであっても$callable()できないものが存在しました。 この矛盾の解決方法はふたつあります。 callableのサポートを廃止するか、$callable()の呼び出しをサポートするか、です。 しかし、ここでふたつめの問題が発生します。 例文では、最後の二つを除いて呼び出しはコンテキストに依存します。 self::methodが参照するメソッドは、何処から呼び出されたかによって変わってしまいます。 このRFCふたつめの目的は、コールバックのコンテキスト依存性を減らすことです。 このRFCが通過すると、あと残っているのはメソッドの可視性だけになります。 すなわち、Foo::barはあるスコープでは可視だけど別のスコープでは不可視になるということです。 将来的にコールバックがpublicメソッドに限定されたりすればこの依存性も解消しますが、このRFCでは可視性については取り扱いません。 Backward Incompatible Changes ここで非推奨とされるコールバックは、大抵は単純に置き換えることで解決します。 たとえば"self"はself::classになります。 "self::method" -> self::class . "::method" "parent::method" -> parent::class . "::method" "static::method" -> static::class . "::method" ["self", "method"] -> [self::class, "method"] ["parent", "method"] -> [parent::class, "method"] ["static", "method"] -> [static::class, "method"] 後者の形式は、コンテキストに依存しません。 コールバックが作成された場所ではなく、呼び出す側のself/parent/staticスコープを参照するようになります。 PHP8.1未満との互換性が必要なければ、ファーストクラスのコールバック構文self::method(...)を使うことも可能です。 [new Foo, "Bar::method"]は単純に置き換えができませんが、ほとんどの人はこんな使い方自体を見たことがないでしょう。 class Bar { public function method() {} } class Foo extends Bar { public function method() {} } このコールバック構文の考え方としては、[new Foo, "method"] はBar::method()をオーバーライドしたFoo::method()を呼び出します。 [new Foo, "Bar::method"]や[new Foo, "parent::method"]は、オーバーライドされる前のBar::method()を呼び出すということです。 Fooスコープ内では["Bar", "method"]、あるいは[parent::class, "method"]と呼び出せばいいです。 これは静的メソッドではなくスコープされたメソッド呼び出しであり、要はparent::method()と同じです。 PHPでは、オーバーライドされたメソッドをスコープの外側から呼び出すための、わかりやすい仕組みはありません。 どうしても必要であればリフレクションやクロージャを使って実現することはできます。 // リフレクション (new ReflectionMethod("Bar", "method"))->invoke(new Foo); // クロージャ Closure::fromCallable([new Bar, "method"])->bindTo(new Foo)(); Vote 投票期間は2021/10/08から2021/10/22で、有権者の2/3の賛成で受理されます。 本RFCは賛成32反対0の全会一致で可決されました。 感想 class Foo{ public function bar() { $callable = 'self::hoge'; is_callable($callable); // true call_user_func($callable); // "Foo::hoge" $callable(); // Fatal error: Class 'self' not found } public function hoge() { var_dump(__METHOD__); } } (new Foo())->bar(); is_callableはtrueだしcall_user_funcでは実際に呼ぶこともできるのに、$callable()ではエラーになってしまいます。 そんなわけでcall_user_funcのこのような使い方はPHP8.2でE_DEPRECATEDにし、PHP9ではエラーにします。 is_callableはPHP8.2で呼び出しは可能なのでtrueのままですが、PHP9ではfalseになります。 今後はこのような使い方をしないようにしましょう。 $callable()が動くようにしなかったのは、本文中にもあるとおり、$callable()を書く位置によって動いたり動かなかったりするからということのようです。 静的なcallableを全然使ったことがないのでよくわからないのですが、このような書式が有用な事例ってあったりするんですかね。 むしろ実際に使っている事例ってあるんですかね。

はじめに 開発したアプリケーションをherokuにデプロイしようと思ったのですが、使用した技術的にもあまり適当な情報がなかったので備忘録としてまとめるついでに誰かの役にたてばなと思います。環境がLinuxですのでMacの方は適宜読み替えてください。様々なサイトを参考にさせてもらっており、参考文献として最後に載せています。 環境 Ubuntu20.04LTS React Laravel(php) mysql xampp 前提 linuxのコマンドが触れる gitを扱える デプロイの概念がなんとなく分かる laravelアプリケーションフォルダ直下をgitで管理している herokuの登録とClearDBの設定 こちら[1]から登録します。２段階認証みたいなやつはなんか飛ばしちゃいましたが、やっといた方が良い気がする。ログインまで行けたらCreate new appを選択してアプリケーションの作成をします。名前を入力して、リージョンはアメリカとヨーロッパしかないのでアメリカを選択。Overviewを押した後にConfigure Add-onsを押すとAdd-onsと書いてある検索欄が出てくるのでそこにClearDBと入力して出てきたものをクリック。更にIgnite-freeをクリックすると赤い警告のようなものが出てくるので、そこにある下の方のリンクをクリックします。 ここで一旦ここまでの流れを解説します。herokuではデフォルトのDBはpostgreSQLなのでアドオン（拡張機能）を用いてmySQLを使用出来るようにする必要があります。そのアドオン名がClearDBです。その後利用プランを無料のものに選択ししましたが、このアドオンの利用には条件があります。それがクレジットカードの登録です。赤い警告ではクレジットカード登録しろといっているのでリンクをクリックして登録しようとしているという流れです。 リンクをクリックするとクレジットカードの番号、名前、住所などの入力画面が出てくるのですべて英語で入力してください。こちらのサイト[2]で日本語住所を変換すれば簡単に英語になるようですが、順番とか間違えない人だったらそのまま英語で入力しても大丈夫です。完了したら先程の画面に戻ってClearDBの下にあるSubmit Order Formを押したら完了です。 環境変数の設定 Settingsを押した後、Reveal Config Varsを押すと環境変数の追加画面が出てきます。左側のKEYの部分に環境変数名を、 VALUEの部分にその値を入力すれば環境変数を設定することが出来ます。環境変数CLEARDB_DATABASE_URLのURLの部分に色々な情報が含まれているので、それを環境変数として抜き出して使いやすくします。形式は下の形です mysql://ユーザー名:パスワード@ホスト名/データベース名?reconnect=true そして以下のような対応で環境変数を作成します。 KEY:VALUE DB_CONNECTION:mysql DB_HOST:ホスト名 DB_PORT:3306 DB_DATABASE:データベース名 DB_USERNAME:ユーザー名 DB_PASSWORD:パスワード 次にアプリケーション用の環境変数APP_KEYとAPP_URLの設定を行います。laravelの環境で以下のコマンドを実行します。 php artisan key:generate --show このコマンド後に表示されたkeyがAPP_KEYになります。base64の部分も含めます。ちなみにbase64はデータの表現方法の一つで、暗号ではないのでこのkeyは盗まれないようにしましょう。ただこのコマンドはキーを生成してそれをコンソール上に表示しているようですが、そもそもlaravelの設定時にAPP_KEYを.envファイルへ書き込んだ気がします（事実書いてあった）。こっちでも良さそうな感じあるんですが、一応参考サイト通りに生成してそっちを書いておきました。 APP_URLは以下の形式です https://Herokuのアプリケーション名.herokuapp.com この2つの環境変数を追加しましょう。メール機能などがあればもっと環境変数が必要になりますが、僕のアプリケーションにはないので省略します。 ビルドやマイグレーション時の設定 先程のページの下にあるAdd　Buildpackボタンを押した後、ポップアップが出てくるのでnodejsを選択した後にSave Changesを選択。もう一度phpで同じことをします。ここらへんはよくわかってないですが、ビルドに要るんだろうなあという感じです。 次にローカルのpackage.jsonの編集を行います。下記のスクリプトをpackage.jsonに追加します。スクリプトは既に存在するはずなので追記するだけでいいです。 "scripts": { "heroku-postbuild": "npm run prod" }, 次にアプリケーションを動かすためのコマンドを記述するファイルであるProcfileを作成していきます。laravelアプリフォルダ直下にProfileというファイル（拡張子なし）を作成して以下の内容を記述します。 Procfile web: vendor/bin/heroku-php-apache2 public/ とりあえずこうすればいいんでしょうが、よく分からなかったので調べてみたところProcfileの書き方は process type : command という感じらしいので、今回はwebという process typeでなんかコマンド実行してるっぽいですね。xamppもapacheで構成されてますし、なんかそこらへんのコマンドなんでしょう。もやもやしますが、深堀りしすぎると性格上脱線しやすいのでここら辺にしておきます。 次にvarchar型の文字数の制限をします。laravel,heroku,デプロイで検索すると複数ヒットしますが、どうやらvarchar型の文字数制限を191にしないとマイグレーション時にエラーが出てしまうようです。このエラー対策としてapp\Providers\AppServiceProvider.phpを下記のように書き換えましょう。 use Illuminate\Support\Facades\Schema;//追加 public function boot() { Schema::defaultStringLength(191);//追加 } Heroku CLIでの操作 Heroku CLIのインストールの前に少しだけ解説をしておくと、CLIはCommand Line Interfaceの略で、全部文字でやろうね的なやつです。これと対比されるのがGUIで、視覚的でこちらの方が一般的だと思います。とりあえずここで理解しておいてほしいのはHeroku CLIはherokuを文字（コマンド）で操作するためのものだということです。要するにターミナルでheroku操作したいからHeroku CLIインストールしようという流れです。 こちらのページ[3]から自分が使ってるOSのコマンドをコピペしてインストールしてください。僕はUbuntuなので下記コマンドになります。 sudo snap install --classic heroku ダウンロードが終わったらログインをします heroku login ここで参考サイトとは異なりメッセージが表示される コマンド 'heroku' は '/snap/bin/heroku' で利用できます '/snap/bin'がPATH環境変数に含まれていないためコマンドを特定できませんでした。 heroku: コマンドが見つかりません どうやらパスが通ってないようなので.bashrcにパスを追加して更新。 export PATH="/snap/bin:$PATH" macだとzshになってたりすると思いますが、適宜置き換えてください。 もう一度ログインするとコマンド自体は成功 › Warning: Our terms of service have changed: https://dashboard.heroku.com/terms-of-service heroku: Press any key to open up the browser to login なんか警告出てるので見てみると、利用規約の変更があったっぽい。読んだが特に問題なさそうだったのでスルーしてもう一度実行 › Warning: heroku update available from 7.59.0 to 7.59.1. heroku: Press any key to open up the browser to login or q to exit: 今度はアップデート出来るよと出てるので調べてみると、単純にアップデートすればいいらしい。 heroku update › Warning: update with: snap refresh heroku heroku: Updating CLI... not updatable としたらまたエラー。調べてみると似たような内容の記事が出てきたのでコマンドを実行 sudo snap refresh All snaps up to date. うまくいったかと思いもう一度ログインを試みるも、さっきと同じエラーが出た。もう一度検索してみると違うコマンドが載っていたのでそちらを実行 source <(curl -sL https://cdn.learnenough.com/heroku_install) curlで取ってきて更新してるっぽい。これで警告はでなくなった。警告放置しておくと後々面倒になることが多いので良かった。最終的には一番下のコマンドを実行すれば良かったっぽい。 警告もなくなったので続きにもどる。最初のコマンドの入力したあとEnterキーなどを押すとサイトが開いた。自分の場合はメールアドレスやパスワードなどは入力しなくてもログインボタンを押すだけでログインできた。恐らくクッキーで保存してるからだと思うので、してない人は入力すればいけるはず。ログインボタンを押すとコンソールの方にログインしたと出力が出来たので、とりあえずCLIでログインすることには成功。 デプロイとマイグレーション herokuではデプロイする場合、herokuリモートリポジトリのmaterブランチにローカルリポジトリのmasterブランチからプッシュすることでデプロイすることが出来ます。一応masterブランチ以外からでもデプロイ出来るようですが、基本的にはデプロイ前にはマージしてmasterブランチを更新しておいた方が良さそうです。 設定も色々変えているので、masterへのマージとプッシュしてあることを確認したら、下のコマンドを実行します。 heroku git:remote -a herokuのアプリケーション名 set git remote heroku to https://git.heroku.com/herokuのアプリケーション名.git git push heroku master これで一応アプリケーションのデプロイは完了です。最後のコマンドの後に出てくるURLをクリックすることでも、自分のアプリケーションのサイトに飛べますし、下記コマンドでも開けます（herokuにアプリケーションが複数ある場合は違うコマンドかも） heroku open しかしアプリケーションをwebで開いてみると、真っ白になっている。デベロッパーツールのコンソールを見てみると下記のエラーが Mixed Content: The page at 'https://frote.herokuapp.com/' was loaded over HTTPS, but requested an insecure script 'http://frote.herokuapp.com/js/App.js'. This request has been blocked; the content must be served over HTTPS. どうやらHttp接続をしているようだが、どこかよく分からない。言われているのがビルド後のReactファイルなのでコードの中身ではなさそうと判断し、色々と情報を調べているとこのサイト[6]の一番最後に同様のエラーに対する対処が書いてあった。この手のサイトあまり信用していないのですが、あまりに情報がないのでとりあえず実行。下記のような環境変数を追加 Key : Value ASSET_URL : https://herokuのアプリケーション名.herokuapp.com これを追加したところ表示された。正直なんでかよく分かっていないので調べたが全然情報が出てこない。恐らくhttps通信にすることが出来たのだろうが、そもそも何が原因だったのか。とりあえず動いたので一旦このままにしておくが、後々原因を究明したほうが良さそう。何か分かる人いたら教えてください。 とりあえず表示までは出来たのでDBを使用するためにマイグレーションしていく。下記コマンドでマイグレーション heroku run php artisan migrate コマンド入力後にDo you really wish to run this command? (yes/no)と聞かれるのでyesと入力。しかしエラーが出て、試行錯誤しているうちに既にテーブルが作成されているためマイグレーションがうまく行かなくなってしまった（エラーを保存し忘れていました。すみません）。コマンドを見る感じheroku runのあとにartisanコマンドが出来そうなので、下記コマンドでデータベースの再構築を試みる。 heroku run php artisan migrate:refresh しかし、同様にテーブルが存在するので無理だとエラーが出る。色々と調べてみるとこちら[7]でrefreshでなくfleshならうまくいったと書いてあったので実行してみる。 heroku run php artisan migrate:fresh このコマンド後にマイグレーションに成功。2つのコマンドの違いを調べたところrefleshはロールバックしてから実行するのに対し、freshは削除してから実行しているよう[8]。何回も実行していたのでロールバックしても同じような状態だったのかもしれない。この後に動作確認をしたが、プログラム通りではない動作は存在しなかった（本番環境になったことで見えてきた修正点はあったが）。とりあえずデプロイ自体は完成したよう。 その他調整 アプリケーション名の変更 アプリケーション名を開発環境だと適当にしていたので、本番環境で名前を変えたくなった。環境変数に以下を追加で解決。 key:value APP_NAME : アプリケーション名 herokuをスリープしないようにする herokuは無料枠だと30分でスリープしてしまう。その対策法として一定時間ごとにcurlコマンドでアクセスするというのがあったのでやってみた。 アドオンを追加 heroku addons:add scheduler:standard Herokuのブラウザアプリにアクセスし、shedulerをクリック。Add Jobをクリックし、Run Commandの部分に下記コマンドを入力 curl herokuアプリケーションのURL で完了。（デフォルトで10分ごとに実行するようになっているはず） デプロイ後のアプリケーションの感想 遅い！herokuは遅いから辞めておけという記事を見て、まあ言うほどでもないやろと思っていたが結構遅い。おかげでローディング時のUIの大切さの理解や遅すぎて動作がはっきり見えるためデバッグしやすいなどの利点もあったが、これは不便さを感じるレベルで無理ですね。まあ無料でこんな簡単に利用してる側が文句言うのはおかしな話なので感謝しなければならないのですが。リージョンに東京がないためアメリカにしているのが結構効いてそうですね。やはりちゃんとしたサービスを展開したいならAWSなどの方が良さそう（やったことないのでどうなのか分かりませんが）。とはいえ完全無料でここまで出来るので、勉強がてらデプロイの理解などをするにはちょうど良さそう。 一応デプロイしたアプリケーションtoDoリストアプリケーションFroteはこちら[9]になります。 おわりに 超簡単という感じでは無かったですが、ちゃんと調べればデプロイは手軽に出来ると思います。ただ自分の真剣に作ったアプリケーションをherokuにデプロイしようとはちょっと思えませんでしたね。アプリケーションの修正とCI/CDだけしたらAWSに移行しようと思います。 参考文献 [1]:heroku [2]:君に届け [3]:The Heroku CLI [4]:Herokuコマンド　アップデート [5]:Heroku コマンド を最新バージョンにアップデートする方法 [6]:HerokuにReactjsアセットを使用してLaravel8Webサイトをデプロイする [7]:マイグレーション実行によってHeroku上に作成されたテーブルを消して、再度マイグレーションする方法 [8]:(Laravel) migrationやり直しコマンドあれこれ [9]:Frote [10]:Laravelをherokuにデプロイする方法・手順の解説（MySQL使用）〜コマンドを使わず、Herokuのサイト上で設定するよ！〜

マイグレーションファイルの作成 $ php artisan make:migration create_comments_table --create=comments comments_table.php public function up() { Schema::create('comments', function (Blueprint $table) { $table->increments('id'); $table->unsignedInteger('article_id'); $table->unsignedInteger('user_id'); $table->text('content'); $table->foreign('article_id')->references('id')->on('articles')->onDelete('cascade'); $table->foreign('user_id')->references('id')->on('users'); $table->timestamps(); }); } 説明 符号なしINTカラム コメントを postに紐付ける $table->unsignedInteger('article_id'); 外部キー制約 foreign('article_id') references('id') どこの→idarticles onDelete() cascade→articleが削除された時に関連するコメントも一気に削除 モデル作成 $ php artisan make:model　Comment Comment.php <?php namespace App; use Illuminate\Database\Eloquent\Model; class Comment extends Model { protected $fillable = ['content']; public function article() { return $this->belongsTo('App\Article', 'article_id'); } public function user() { return $this->BelongsTo('App\User', 'user_id'); } } Article.php //追加 public function comments() { return $this->hasMany('App\Comment'); } マイグレーション $ php artisan migrate シーダーファイルの作成 $ php artisan make:seeder CommentsTableSeeder CommentsTableSeeder.php public function run() { for ($i = 0; $i < 30; $i++) { $faker = Faker\Factory::create(); $param = [ 'content' => $faker->paragraph(), 'created_at' => Carbon::today(), 'updated_at' => Carbon::today(), 'article_id' => $faker->numberBetween(1, 10), 'user_id' => $faker->numberBetween(1, 10), ]; DB::table('comments')->insert($param); } } シーダーを実行する順番を追加 DetabaseSeeder.php //最後に追加 $this->call('CommentsTableSeeder'); シーダーの実行 $ php artisan db:seed ルート web.php Route::resource('comment', 'CommentsController', ['only' => ['']]); コントローラー ファイルの作成 $ php artisan make:controller CommentsController view detail.php <div class="card w-50 mx-auto m-5"> <div class="card-body"> <div class="pt-2"> <p class="text-muted font-weight-bold h4 border-bottom border-secondary pb-3">コメント</p> </div> @if($articles->comments->isNotEmpty()) @foreach ($articles->comments as $comment) <div class="border-bottom border-secondary pt-2"> <p class="text-muted mx-3 pt-1">{{ $comment->user->name }} が{{ $comment->created_at->format('Y年n月j日') }}に投稿</p> <p class="text-muted mx-3">{!! nl2br(e($comment->content)) !!}</p> </div> @endforeach {{-- TODO:↓コメント入力欄、コメントボタンの設置--}} @else <p class="text-center pt-2">コメントはまだ投稿されていません。</p> @endif </div> </div> </div>

priorityを変更する 例えば、rulesets/codesize.xmlのルールを読み込みつつ、特定のルールだけ変更したい。 rulesets/codesize.xmlを読み込み、変更したいルールを除外する 改めてrulesets/codesize.xml/xxxxで個別にルールを読み込み、設定を変更する phpmd.xml <?xml version="1.0"?> <ruleset name="change priority" xmlns="http://pmd.sf.net/ruleset/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd" xsi:noNamespaceSchemaLocation=" http://pmd.sf.net/ruleset_xml_schema.xsd"> <description> change prioriy </description> <!-- ルールセットを読み込む --> <rule ref="rulesets/codesize.xml"> <!-- プライオリティを変更したいルールを除外 --> <exclude name="ExcessivePublicCount"/> </rule> <!-- 改めてルールを読み込んでプライオリティを変更 --> <rule ref="rulesets/codesize.xml/ExcessivePublicCount"> <priority>5</priority> </rule> </ruleset>

APIで月次データを取得しているPHPプログラムがエラーを吐くようになりました。 ログ file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed {"exception":"[object] (ErrorException(code: 0): file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed at /var/www/html/xxx.php:35) エラーはfile_get_contents()でAPIを叩いている箇所で起こっています。 PHP $json = file_get_contents("https://example.com/api/v1/get/$code", false, $context); 同じことをcurlで行うと成功するので、API提供元の不具合では無さそうです。 curl -s https://example.com/api/v1/get/999 以下のようにして、サーバ証明書の検証をしないことで回避できそうですが、これは最後の手段としたいです。 PHP $context = stream_context_create([ 'ssl' => [ 'verify_peer' => false, 'verify_peer_name' => false ] ]); $json = file_get_contents("https://example.com/api/v1/get/$code", false, $context); まず疑うべきは証明書の有効期限切れです。 API提供元は Let's Encrypt を使っています。 そういえば、Let's Encrypt が使用しているルート証明書が9月30日に期限切れになっていたことを思い出しました。 このAPIは月末近くに発動するので、今回その影響を受けた可能性が高いです。 そこでca-certificatesパッケージを最新にしたところ、解消されました！ CentOS7 yum -y update ca-certificates

ラジオボタンで入力値を残すには <div> <input class="form-check-input" type="radio" name="status" id="status1" value="未読" <?php echo ($review['status'] === '未読')?'checked':'';?>> <label for="status1">未読</label> </div> valueの後にcheckedを入れることによって初期状態でチェックをいれておくことができる。 それと三項演算子を組み合わせる。 ・三項演算子 (比較条件)?'TRUEの場合に返す値':'FALSEの場合に返す値' ($review['status'] === '未読')?'checked':'' 入力された値が未読ならばchecked、そうでなければnull ↓　　　　　　　　　　↓　　　　　　　　　　　↓ これで未読のラジオボタンにチェックを入れると、次遷移しても初期状態でチェックが入るようになる。 未読のラジオボタンにチェックがはいっていなければnullを返すのでチェックは入っていない状態になる。