PHP関連

セッションの保持時間は意外に短い

デフォルトのphp.iniの設定では、セッションの保持時間は24分だそうです。

さらにセッションが削除されるタイミングは100分の1だそうで、100回アクセスに1回のタイミングで24分すぎたセッションファイルを削除するとのこと。

長時間セッションを保持しなければならないようなプログラムの場合は注意しなくては。

php.iniに以下を設定

session.gc_maxlifetime = 14400
session.gc_divisor = 1000
session.gc_probability = 1

これで1000分の1の確率で、240分過ぎたファイルを削除するようになる。

 

参考サイト

ガベージコレクション(GC)をCakePHPで試してみる | Structured-P

 

総合管理者 | 2017年01月06日 | コメント(0) | トラックバック(0) | PHP関連

Search Console(ウェブマスターツール)でインデックス数が激減

このサイトのURLを

http://www.nandani.sakura.ne.jp/

から

http://nandani.sakura.ne.jp/

に変更しました。(wwwなし)

理由はwwwあり・なし両方でアクセスできるとSEO的に良くないのが1点(いまさら)

もう1つは、さくらインターネットのサブドメイン(○○○.sakura.ne.jp)でSSLが使えるのが、www無しのみだったので、http://nandani.sakura.ne.jp/をメインURLとしました。(httpsの方がSEO的に良いらしいので。さくらインターネット特有のくせで、記事ページにhttpsでアクセスするとおかしくなるため、まだ変えてませんが。)

そうしてみたところ、Search Consoleのインデックス数が激減。

まあ当たり前です。

これまでは「http://www.nandani.sakura.ne.jp/」で登録されていたのに、wwwなしになったわけですから。

しばらくしたら治るだろうと思っていたのですが、一向に増える気配はなく、何ならどんどん減っていきます。

ただでさえ減ってたのに!

なんで?と思い、よくよくSearch Consoleに送っているsitemap.xmlを見てみたら、そこに記述されているURLが「http://www.nandani.sakura.ne.jp/」になっているではありませんか。

サイトマップ書き出しには「Google XML Sitemaps」を使っているのですが、どうやらキャッシュっぽい感じで残っており、それが送信されてたらしい。

通りで全然インデックスされないわけだ。

ということで、設定>XML-Sitemapから設定を更新したら、無事「http://www.nandani.sakura.ne.jp/」で出力されるようになりました。

 

インデックスが減っていたとはいえ、あんまりアクセス数は変わってないんですよね。

メインの流入はGoogleからのはずなんだけどなぁ。

総合管理者 | 2016年01月20日 | コメント(0) | トラックバック(0) | CMS関連 | PHP関連 | SEO関連

商品ページの変数【EC-CUBE】

かなり雑にメモ。

EC-CUBEの商品ページ用のテンプレートで、商品情報が入っている「$arrProduct」の中身は、以下のキーで取得できます。

■product_id
■name
■maker_id
■status
■comment1
■comment2
■comment3
■comment4
■comment5
■comment6
■note
■main_list_comment
■main_list_image
■main_comment
■main_image
■main_large_image
■sub_title1
■sub_comment1
■sub_image1
■sub_large_image1
■sub_title2
■sub_comment2
■sub_image2
■sub_large_image2
■sub_title3
■sub_comment3
■sub_image3
■sub_large_image3
■sub_title4
■sub_comment4
■sub_image4
■sub_large_image4
■sub_title5
■sub_comment5
■sub_image5
■sub_large_image5
■sub_title6
■sub_comment6
■sub_image6
■sub_large_image6
■del_flg
■creator_id
■create_date
■update_date
■deliv_date_id
■plg_giftpaper_noshi
■product_code_min
■product_code_max
■price01_min
■price01_max
■price02_min
■price02_max
■stock_min
■stock_max
■stock_unlimited_min
■stock_unlimited_max
■point_rate
■deliv_fee
■maker_name
■price01_min_inctax
■price01_max_inctax
■price02_min_inctax
■price02_max_inctax

取得例:商品IDを取得する場合

<!--{$arrProduct.product_id}-->

総合管理者 | 2015年12月11日 | コメント(0) | トラックバック(0) | CMS関連 | PHP関連

あぁ勘違い ー パーミッションについて

自分はこれまで、パーミッションについて

  • 実行:4
  • 書き込み:2
  • 読み込み:1

だと思っていました。

だって、PHPは644(または604)で動くんだもの。

実行権限がついているのは当然でしょ、と思っていたわけです。

しかし実際は皆さんもご存知の通り

  • 読み込み:4
  • 書き込み:2
  • 実行:1

と間逆!

ドヤ顔で説明していたところに、違いますと指摘されたものだからこれは恥ずかしい・・・

では、なぜPHPは644(または604)で動作するのか。

答えはこのブログに書かれていました。

PHPでパーミッション(実行権)の設定が必要ない理由 | ちほちゅう

なるほど、PHPはapacheモジュールで、apache内で実行されるから、apacheが読み込みさえできれば動作するということですね。

・・・でも待てよ。

PHPにはCGIモードなるものもあったはず。

PerlなどのCGIは755・705で動作するから、CGIモードだと755・705か?

いやしかし、運用している専用サーバのPHPはCGIモードにしていて、644で動いていたはず。

・・・そういえば。

と、専用サーバを設定する際に、suEXECという設定を行ったことを思い出しました。

suEXEC サポート - Apache HTTP サーバ

[引用]
suEXEC 機能により、Apache ユーザは Web サーバを実行しているユーザ ID とは 異なるユーザ ID で CGI プログラムや SSI プログラムを実行することができます。CGI プログラムまたは SSI プログラムを実行する場合、通常は web サーバと同じユーザで実行されます。

なるほど、だからか。

所有者権限の実行でありながら、CGIプログラムを実行することが出来るわけですね。

だから所有者が読み込みさえできればよいと。

 

総合管理者 | 2015年10月17日 | コメント(0) | トラックバック(0) | PHP関連

PHPでアップロードできる上限は2GBまで!【POSTの場合】


<form action="hoge.php" enctype="multipart/form-data" method="POST">
<input name="hogefile" type="file" />
<input type="submit" value="送信" />
</form>

PHPを使用して、このような形式でファイルをアップロードする場合、アップロードされるファイルサイズの上限はphp.iniで設定されています。(正確には.htaccessやPHP自身でも設定できますが。)

php.iniには、アップロードファイルの上限を設定する箇所が3つあります。

  • memory_limit(使用できるメモリの上限設定)
  • post_max_size(POSTされるデータの上限設定)
  • upload_max_filesize(アップロードされるファイルサイズの上限設定)

です。

それぞれ

memory_limit >= post_max_size >= upload_max_filesize

という関係になっています。

つまり、「upload_max_filesize」をいくら増やしても、「post_max_size」で設定されているサイズ以上のファイルはアップロードできないし、「post_max_size」を増やしても、「memory_limit」で設定されているサイズ以上のファイルはアップロードできないというわけです。

例:

memory_limit = "128MB"
post_max_size = "512MB"
upload_max_filesize = "1G"

この場合、アップロードできるファイルサイズの上限は128MBとなります。

memory_limit = "128MB"
post_max_size = "1G"
upload_max_filesize = "1G"

この場合でも同様。

もちろん、memory_limitは、サーバのメモリサイズ(仮想メモリ含む)の上限を超えることはできません。

つまり、

memory_limit = "2G"
post_max_size = "2G"
upload_max_filesize = "2G"

こう設定したとしても、実際のサーバのメモリ(+仮想メモリ)が1GB分しかなければ、1GBまでしかアップできないということになります。(他にもメモリ使ってるだろうから実際はもっと低い)

では、サーバのメモリを12GBくらい積んで

memory_limit = "4G"
post_max_size = "4G"
upload_max_filesize = "4G"

とした場合、4GBまでアップロードできるようになるか?

答えはNoです。

この原因は、apacheにあります。

apacheの設定に、「LimitRequestBody」というものがあり、これの上限は2GBとなっています。

「LimitRequestBody」はその名の通り、HTTPリクエストのボディ部分のサイズ限界です。

いくらPHP側の設定で、2GB以上を迎え入れる準備をしたところで、HTTPリクエストの方で限界を迎えるわけです。

まあ、2GB以上をアップすることは中々ないとは思いますが、大容量のファイル共有サイトなどを作ろうと思ったりした場合は、注意が必要ですね。(FTP接続の方式にすればうまくいくかも。)

 

参考サイト

総合管理者 | 2015年10月16日 | コメント(0) | トラックバック(0) | PHP関連

メニューをカスタマイズ(WordPress)

WordPressの外観>メニューで作ったメニューは、wp_nav_menu関数で簡単出力されます。

階層も反映されてて便利なのですが、どうしてもこの関数は実現できないことが発生したため、独自に関数を作ることにしました。

メニューをデータを取得するには、wp_get_nav_menu_itemsを使用して配列で取得します。

ただし階層構造にはなってません。

なので、以前の記事「WordPressのサイトマップを作る【プラグインなし】」を参考に、階層構造で作り直して出力します。


function my_wp_nav_menu($menu_type, $menu_item_parent = 0, $ul_use_flag = 0){
	
	$return = "";
	$menu_items = wp_get_nav_menu_items('main_navi');
	$menu_trees = array();
	
	if($menu_items){
		$exist_flag = 0;
		foreach($menu_items as $menu_item){
			
			//親が引数($menu_item_parent)と同じもののみ
			if($menu_item_parent == $menu_item->menu_item_parent){
				if($exist_flag == 0){
					if($ul_use_flag == 1) $return .= '<ul class="sub-menu">'."\r\n";
					$exist_flag = 1;
				}
				
				//リンクの開き方
				$target = '';
				if($menu_item->target){
					$target = 'target="_blank"';
				}
				
				//class
				$class = 'menu-item';
				if($menu_item->classes[0]){
					$class .= ' '.implode(" ", $menu_item->classes);
				}
				
				//title要素
				$attr_title = '';
				if($menu_item->attr_title){
					$attr_title = 'title="'.$menu_item->attr_title.'"';
				}
				
				$return .= '<li class="'.$class.'"><a href="'.$menu_item->url.'" '.$target.' '.$attr_title.'>'.$menu_item->title."</a>";
				
				$return .= my_wp_nav_menu($menu_type, $menu_item->ID, 1);
				
				$return .= '</li>'."\r\n";
			}
		}
		if($exist_flag == 1){
			if($ul_use_flag == 1) $return .= '</ul>'."\r\n";
		}
	}
	
	return $return;
}

使用する場合は以下の通り

<ul>
	<?php echo my_wp_nav_menu('main_navi'); ?>
</ul>

これで大体wp_nav_menu関数の標準設定と同じ挙動となります。

再帰のたびに、wp_get_nav_menu_itemsで全部取りなおすので、あんまり効率は良くないですが、とりあえずこれで改造し放題です。

総合管理者 | 2015年07月08日 | コメント(0) | トラックバック(0) | CMS関連 | PHP関連

ZipArchiveのextractToで日本語ファイルが解凍できない【PHP】

zip圧縮自体はうまくいってるのだけれど、ZipArchiveのextractToで解凍すると日本語部分が消えてしまう問題が発生しました。

たとえばファイル名が

サンプル-1.jpg

という場合、解凍すると

-1.jpg

となってしまいます。

調べたところ、ZipArchiveはPHPで設定されているlocaleに依存するとのこと。

ZipArchiveで日本語ファイル名を扱えない場合があって困った話 - Qiita

ということであれば、同じプログラム内で事前にlocaleの設定を変えればいいんじゃね?と思い、ZipArchiveをインスタンス化する前に、下記を追記しました。


if (setlocale(LC_ALL, 'ja_JP.UTF-8') === false) {
error_log('Locale not found: ja_JP.UTF-8');
exit(1);
}

参考:PHPのロケールに関するまとめ - hnwの日記

日本語ファイルでもうまく解凍できるようになりました!

nandani | 2014年12月19日 | コメント(0) | トラックバック(0) | PHP関連

管理画面の投稿やカテゴリー(カスタムタクソノミー)画面でも並び替えを反映させる【WordPress】

カテゴリーおよびカスタムタクソノミーの並び替えを簡単に行えるプラグイン「PS Taxonomy Expander

フロントエンドでは、get_termsやwp_list_categoriesの"orderby"を"order"にすることによって、並び替えた順に並んでくれます。

しかし管理画面の「新規投稿を追加」や「投稿を編集」のカテゴリー選択リスト、および「カテゴリー」画面のカテゴリーリストでは並び順が反映されていません。

Category Order and Taxonomy Terms Order」というプラグインもあって、これを使用すると管理画面内の並び順も反映されるんですけどね。

こっちを使ってもいいし、「PS Taxonomy Expander」のまま、functions.phpに下記を追加しても構いません。


function my_get_terms_orderby($orderby){
  if(is_admin()){
    return "t.term_order";
  }else{
    return $orderby;
  }
}
add_filter('get_terms_orderby', 'my_get_terms_orderby', 10);

これで管理画面内のカテゴリーの並び順は強制的に、Term Orderで設定した並び順に並びます。

※必ず一度は並び替えの保存を行ってください。未保存のままだとカテゴリーリストが表示されなくなります。

しかしフック機能の便利さには舌を巻きますね。何でもできる気分になりますw

nandani | 2014年12月02日 | コメント(0) | トラックバック(1) | CMS関連 | PHP関連

ページのスラッグからデータを引き出す方法【WordPress】

get_page_by_path("スラッグ名");

で、そのスラッグ名のページ(固定ページ)を取得できます。

第3引数をpostとすれば、「投稿」から取得できます。

get_page_by_path("スラッグ名", "OBJECT", "post");

なお、固定ページで、親ページが設定されている場合、親ページのスラッグも含める必要があります。

get_page_by_path("親ページのスラッグ名/スラッグ名");

だから、やっぱり正確にはスラッグ名ではないんですね。

 

参考サイト

get_page_by_path:WordPress私的マニュアル

nandani | 2014年11月24日 | コメント(0) | トラックバック(0) | CMS関連 | PHP関連

WordPressでTinyMCEの入力フィールドを作る場合

任意の場所に、Wordpressの内容入力フィールドと同じようにリッチテキストエディタ(TinyMCE)を設置する方法は、

wp_editor( "(内容)", '(ID)');

で、設置できます。

第3引数に細かい設定ができますが、(ID)をnameと同じにしていればこれだけでもOKです。

プラグインなしでカスタムフィールド作ってた際(functions.phpに直書き)どうやったらリッチテキストエディタになるのか、かなり苦戦したのでメモ。

参考サイト

wp_editor:WordPress私的マニュアル

 

nandani | 2014年11月12日 | コメント(0) | トラックバック(0) | CMS関連 | PHP関連

Copyright(c) 2010 - 2017 ダリの雑記