WPのContactForm7が文字化けする

スマイルサーバのver4に移動してから、WordpressのContactForm7で送ったメールが文字化けするという現象が起こりました。

正確には、メールフォームで入れた項目が「????」という文字化けをし、そのほか設定した文字(たとえば、「このメールは●●サイトのお問い合わせから送っています」などのテンプレートの文字)は文字化けしていません。

ContactForm7の文字化けについては、いろいろと記事がありましたが、そのうちの

Contact Form 7で送るメールの文字化けが直らない

php.iniのmbstring.encoding_translation = OnをOffにしたら文字化けしなくなりました。

が参考になりました。

実際に、phpinfoでサーバ情報を見ると、「mbstring.encoding_translation」は「On」でした。

ただ、その設定をするとうまくいくのですが、「On」になっていたのを「Off」にするのは少々抵抗があります。

そのほか見ていて、

mbstring.encoding_translationが原因で文字化け

での設定がよさそうです。

スマイルサーバの「php.ini」は「.user.ini」である必要があるので、そのファイルに

mbstring.http_input = UTF-8

mbstring.internal_encoding = UTF-8

mbstring.substitute_character = "?"

を記入して、文字化けは防げました。

スマイルサーバプラン移行後、allow_url_includeがOnできなくなったら

スマイルサーバがver2,3からver4にプラン移行するにあたり、データを移行してくれたのですが、includeを利用して表示していた画面が表示しなくなりました。

単純にソースを書き出したphpをincludeして表示させていた仕組みで、今更アウトプット部分の処理を変更するのも、面倒なので、今までのようにincludeを使えないかと調べました。

php.iniでallow_url_includeをOnにしてみる

まずは、php.iniを利用して、allow_url_include = ONにしようと思ったのですが、今までのサーバでは「data」フォルダに「php.ini」を入れるだけでいけていました。

しかし、今回は「.user.ini」というファイル名を入れなければならないようです。しかも、allow_url_include = ONはできない(※スマイルサーバに問い合わせていただいた回答です)

includeの代替案

参考URLを教えてもらったので、
allow_url_fopen と allow_url_include
試しましたが、うまくいきませんでした。

どちらかというとうまくいったのは

PHPのallow_url_includeでinclude()の代替案

でした。cURL関数を利用しました。

 

WordPress4.8にアップデートしたらFailed to load content css: (省略)editor-style.cssと出る件

WordPress4.8から、テーマとブラウザによっては、投稿用のビジュアルエディターにしたときに

「Failed to load content css: (省略)editor-style.css」と出るようになった。

ビジュアルエディターにスタイルシートを効かせたい場合、function.phpに

add_editor_style(‘editor-style.css’);

と記述して、適応させるthemeのフォルダにいれたeditor-style.cssを読み込ませたり、「tinymce-advanced」の設定で「editor-style.css」を読み込ませたりしていたのだけども、それがどちらの方法でも引っかかる。

また、ブラウザはGoogleChromeのときに出るような気がしている。

手っ取り早い解決方法として、「editor-style.css」に「import」を利用して、相対パスで別のcssファイルを読み込ませていたので、それを絶対パスに変更した。

ブラウザやサーバやテーマの作り方によって出たりでなかったりするというところは、まったく解決していないが、とりあえず。

Geolocation APIで現在地が取得できない

geolocationで現在地が取得できずに困っていました。

大きな原因からいって「SSLの環境下でないと現在地を使わせないOSが増えてきた」「なぜかgeolocationが定義されてないっぽい」でした。

1.GooglechromeやiOSのブラウザ、Macのsafariでhttp接続のページから現在地を取得を禁止する仕様に変わってきた

今までは「位置情報取得をon」や「ブラウザが位置情報取得を許可しているか」などを確認してもらっていたけど、そういうの関係なく「禁止」になっている。

Webブラウザで現在地情報を正しく取得できない場合の原因と対策 (参考記事)

iOSはバージョン10以降(iPhone7はプリインストール)

2.geolocationが定義されていないっぽい?

alertとかを加えて、javascriptが動いているか、どこで動かなくなるかを検証していたところ、どうもgeolocation自体が動いてないっぽい。

navigator.geolocation.getCurrentPosition から navigator.geolocation.watchPositionに変えてみたりしたけど動かない。

Android で現在地を Geolocation API で取得できないとき (参考記事)

を参考に{enableHighAccuracy: true}をオプションにいれてみたけど、動かない。

最終的には

第3回 位置情報を取得してみよう(後編)(参考記事)

を読んで、try catchを入れて、geolocationが定義されてなかったら「使えません」と謝る機能を追加した。

なぜ「geolocation」が使えないかは謎です。

 

あとやはり基本的な知識が足りないなぁ……反省。

Geolocation の利用

Warning: proc_open() has been disabled for security reasons

サーバ側で、proc_open()の使用が禁止されているようです。

sakuraのサーバだとすんなり行ったので、油断してました。

ちなみに利用したのはSpeeverのサーバです。

検索にひっかかったのはDrupalのページだけど

proc_open() has been disabled for security reasons in /home/ahbekker/public_html/drupal/includes/image.imagemagick.inc

php.iniで制御できるっぽい。

 

wordpressでスラッグからページのURLを取得する

function.phpに以下を追加

function slugtourl($slugname){
	//固定ページのスラッグからページを取得
	$page = get_page_by_path($slugname);
	//ページIDからURLを取得
	return get_permalink( $page->ID );
}

URLを表示したいところに以下を追加

<?php echo slugtourl('access');?>

echoを付けるかつけないかの判別を入れてもよかったけど……。
それ自体は難しくないので……。

function slugtourl($slugname,$display = 1){
	//固定ページのスラッグからページを取得
	$page = get_page_by_path($slugname);
	//ページIDからURLを取得
	$url = get_permalink( $page->ID );

	if($display){
	   echo $url;
	}else{
	   return $url;
	}
}

という感じでしょうか。

javascriptの関数で変数にデフォルト値を入れていたらIEで動かなくなった件

PHPのノリで、javascriptのfunctionの変数にデフォルト値を以下のように入れていたのですが。

function example(aaa,bbb,ccc=600){

これで、IEの表示だけまったく動かなくて、3時間近く奮闘してた。
GoogleもFirefoxも動くんだもん。

いや、もしかしたら、他のいろんな要素が邪魔をしてと思ったんだけど……。

なんでか絶対、私の見落とした、アホみたいな理由があると思うんだけど……。

とりあえず、追跡はまた今度にして、ひとまず今日はここまでにしておく。

いや、動いてよかったんだけど。「なんでー!!!!」ってなりました。


jqueryのバージョンは、1.10.2でも3.1.0でも動作は同じだった。
IEのバージョンは11

参考になりそうな記事を発見。この時は、Googlechromeだと動かないと書いてある。

JavaScript関数で引数で=を使ってのデフォルト引数

古いIEだったら動くのかなとテスターとかつかってみるけど、動かない。とりあえずまたじっくり時間が取れたら少し追ってみようと思う。

EC-CUBEで顧客情報と受注情報のみ移動させるときの注意

2度目にやったときに見事に忘れていたので、メモ代わりに。

[ec-cube] 顧客情報、受注情報をインポートした際の注意点

わかりやすいまとめでした。ありがとうございます。

要するにシーケンス番号の書換えに注意ってことですが、私はこの「シーケンス」という言葉ごと忘れるので注意が必要。

dtb_customer を移行。そして、シーケンス dtb_customer_customer_id_seq も注意

dtb_order と dtb_order_detail を移行。そして、シーケンス dtb_order_order_id_seq と dtb_order_detail_order_detail_id_seq も注意。

WADAXサーバにてDNS切替後500エラー発生

WADAXの共用サーバにEC-CUBEをインストール。
初期ドメインではうまく動いていたEC-CUBEが、DNS切り替え後、どこを触っても500エラー。
ただのindex.htmlを入れても、500エラー。

原因は、パーミッションでした。

しかし、WADAXにEC-CUBEをインストールしたときに、
EC-CUBE側から言われた通りにパーミッションを変えました。
でないと、ドキュメントルートのフォルダに777なんて……普通やるはずがない。

WADAXのQA「パーミッションの設定はどうすればいいの?」
http://faq.wadax.ne.jp/wdx5569/web3765/faq/Detail.aspx?id=33&isCrawler=1

ドキュメントルートのパーミッションを「755」に設定すれば、ひとまず動き出しました。

あとは、user_dataフォルダ以下とか、EC-CUBEのインストール時に「777」にしたフォルダを「755」や「707」に、新規ページ作成などで自動で作成されたphpなどは「705」に変更していけば、一通り動くように。

初期ドメイン時に作成した「user_data」に格納される新規ページのphpなどは、所有者が「web」などになってパーミッションが変更できなかったため、一旦ファイルをダウンロードし、削除、再度アップロードすることで所有者を変更。その後、パーミッションを設定しました。

ただ、この状態でも、新しくページ追加などをすると、phpのパーミッションが666とかになり、500エラーがでますので、そこは注意です。

なんで、DNSを切り替えたら、こんなエラーが出るのか? WADAXには問い合わせ中です。

こんなに面倒なサーバだったかしら……。WADAXさん、好きだったのに。
DNS切り替えは初めてだから、何かが違うのかなぁ。

【追記】
WADAXからの回答は、「事前確認用アドレスと、ドメイン表示用ではパーミッション設定の権限が異なりますためそうなりました」というような回答。
パーミッション設定を変えたら回避できるとか言われても、そんなことは重々承知。
私的には、なんで「事前確認用アドレス」のくせに、「ドメイン表示」と環境が変わるのか、そっちのほうが重要。
なんのための「事前確認用アドレス」なのか。

私が「他のサーバーでこんなことなったことないから」って書いたのが悪かったのかもしれないけど、
ご丁寧に「他社サーバーの仕様は弊社ではわかりかねます」とか返事してこられたのには、ちょっとびっくりしました。
まぁ、そうでしょうけど。

こんな「事前確認用アドレス」があてにならないサーバは初めてで、まったく説明になってない返事をもらったのもなんだかです。

昔は、WADAXさんなら大丈夫と思ってたけど、やっぱりいろいろと変わるもんですねぇ。

CKEditorのハイパーリンクのOKボタンが押せなくて

XOOPS内で、CKEditorモジュールを使用。
IE11で使用中に、ハイパーリンクが下図のような表示になって、OKもキャンセルも押せなくなります。hyperlink

通常は、
hyperlink2
こんな感じ。

IEで出ていたエラーは

SCRIPT5: アクセスが拒否されました。
ファイル: dnserrordiagoff.htm、行: 1、列: 1

この現象に関しては、

Issue found in IE11 and IE9 – Insert Hyperlink does not work

にある通り、4.3よりもバージョンが低い場合に起こるようなので、バージョンをあげてやればいいのだけども……。

でも、IE11でもちゃんと動いている環境があり、その差は、「テンプレートの追加を読み込んでる場合」と「読み込んでない場合」だった。

一度起こる様になったら、テンプレートの追加を切っても、起こる様になりましたので……不思議。
でも、javascriptのキャッシュも絡んでいて、なんだか、本当にちゃんと出ていた原因がそれだったのかも切り分けにくく。

そして、CKEditor4をバージョンアップしたら、投稿画面のエディターでなくなったし。

もー、前に何したか思い出さなきゃ……。