Q&A
>変更されません
どのように確認されたのでしょうか。
また、レンタルサーバーは何でしょうか。
前提・実現したいこと
レンタルサーバーにてセッションの有効期限を変更しようとしました
ベンダーに確認したところ、ini_set関数で直接記述すれば変更可能との事でしたので、
下記のように記述しましたが、変更されません
書き方が間違っている部分はありますでしょうか？
該当のソースコード
PHP
1session_name('PHPSESSIONID'); 2if(isset($_COOKIE["PHPSESSIONID"])){ 3session_id($_COOKIE["PHPSESSIONID"]); 4}else{ 5setcookie("PHPSESSIONID",session_id(),time() + 365*24*3600,'/'); 6session_id($_COOKIE["PHPSESSIONID"]); 7} 8session_start(); 9ini_set( 'session.gc_maxlifetime', 604800 ); 10ini_set( 'session.cookie_lifetime', 604800 ); 11ini_set( 'session.gc_probability', 1 ); 12ini_set( 'session.gc_divisor', 100);
確認した手法はphpinfo()を実行した際のsession.gc_maxlifetimeの値と、
Googleクロームにてセッションの有効期限を確認しました(ブラウザ終了時までとなっており変わりありません)
レンタルサーバーはマイナーな海外のサーバーです
phpinfo()はあくまでphp.iniの設定取ってきます。
プログラム内に書かれた場合はあくまで「その実行セッション内」と思ってください。
ただ、レンタルサーバーだと他のユーザーも同じサーバー内にいるわけですから、影響を加味して変更できないこともあるようです。
サーバー運営に問い合わせるかマニュアル確認してみてください。
かしこまりました
ベストアンサーとさせていただきます
質問に対して応えたわけではなく、確認してもらってその結果を追記してもらいたかったのですけど。（確実なことが言えないので回答にできないと思ってます）
現在問い合わせ中でして回答待ちでございます
失礼しますが、もう1点いいでしょうか
私の制作中のサイト、iframeを多用しております
多用されたiframeのページ全てにini_set関数の記述をするんでしょうか
それともiframeの親であるトップページのみに1回記述すればいいんでしょうか
URLで呼び出されるので親ページの影響は受けないはずです。
というかそもそもini_set()を多用しなければならない設計に問題があると思いますけど。
＞URLで呼び出されるので親ページの影響は受けないはずです。
回答ありがとうございます
＞というかそもそもini_set()を多用しなければならない設計に問題があると思いますけど。
逆説ですがどのような設計が多用しなければならないのでしょうか
「多用しなければならない設計」は思い浮かびません。
というかプログラム個別にini_set()を何回も書かなければならない状況ってないんじゃないでしょうか。サーバー負荷なども加味すると、設計的にはわざわざ別途指定しなくても良い範囲でするべきと思います。
１個だけ長い処理があって（バッチとか）そこにだけあてるならまだしも、あらゆるところにあらゆる指定をしようとしているように見えるので。
どうしても何か所も書きたい、そして同じような指定である
ならそれ指定用のphpファイル用意しておいて冒頭でincludeすれば良いとは思います。
＞URLで呼び出されるので親ページの影響は受けないはずです。
すみません、今一度考えなおしたら、どっちなんでしょうか
親ページにini_set関数が記述されていても子ページに反映されないといった意味でしょうか？
＞プログラム個別にini_set()を何回も書かなければならない状況ってないんじゃないでしょうか。
答えが出ました。ありがとうございます
このご時世にiframeを使ったページ切替サイトって終わってますでしょうか？
個人的にはAjaxを使うまでもないと考えたページ構築の場合にiframeが非常に便利なのですが。
>終わってますでしょうか？
要件次第です。
本当の意味で「終わる」のは要素自体が非推奨から廃止になった時です。
使えるなら使って構わないと思いますし、他の手段は考えられますけど、
ユーザーからしたら使えればそれでいいので、レイアウトの崩れや機能の失効がない、パフォーマンスが担保されているなら、中身の構成は関係ないと思います。
Ajaxのほうが用途が自由なのは確かですけどね。
もし「共通のテンプレートとして」ならiframe使うよりPHPで使えるテンプレートエンジン使った方が良いとは思います。
Ajaxの場合Scriptファイルの実行には再同期が必要ですよね？
iframeの場合不要ですよね
膨大なScriptファイルがあった場合、個々に再同期するプログラムを書くのかと思ったら、
iframeを選んでしまいます
iframeにしろAjaxにしろ、最低1回はリクエストを投げるという点ではサーバーへの負荷は同じですよね
すみません、Ajaxの場合は必要なところだけとってくるって考えたら受信Byteに変わりはありました
サーバーへの通信は最低1回は発生するのは同じですよねという意味で申し上げました
「共通のテンプレートとして」＝includeですか？
私はtableタグでレイアウトを組んだりもしてたのですが(今は違います
＞ユーザーからしたら使えればそれでいいので、レイアウトの崩れや機能の失効がない、パフォーマンスが担保されているなら、中身の構成は関係ないと思います。
この考え方からみたら、別にtableでレイアウトを組むのも問題ないんでしょうか？
要件次第です。
何が適切かは中身の仕組みを考える設計者・エンジニアの仕事です。
あなたの回答
tips
プレビュー
