接続が切断されました: 送信時に、予期しないエラーが発生しました。。

.Net 4.5 で組んでいるアプリから、サクラインターネットのwebサーバーにあるAPIに、HTTPS通信するようにしていたシステムが、ある日突然

「接続が切断されました: 送信時に、予期しないエラーが発生しました。。」

とエラーをだすようになりました。

証明書の期限切れかと思ったのですが、それは問題なかった。

結局、エラーをキーワードに調べまわって、やっとわかったことがTLS1.0、1.1の廃止に伴うものでした。。

https://qiita.com/tanj/items/31a0fd6b188952886de5

確かに、さくらインターネットからの発表がありましたね。エラーが発生し始めた時期的にもビンゴです。

https://qiita.com/tanj/items/31a0fd6b188952886de5

というわけで、TLS1.2に対応できるように次のコードを付け加えました。

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

参考:https://blogs.technet.microsoft.com/jpieblog/2015/04/07/net-framework-tls1-1-1-2/

0

カスタムタクソノミーのアーカイブページやカスタム投稿ページを非表示にする

WordPressで、カスタム投稿のシングルページ(個別ページ)を出力させたくないときがあります。たとえば、「よくある質問」のように、コンテンツが数百文字でおわってしまうような場合です。その場合、シングルページは寂しい内容になってしまうので、それならいっそ、アーカイブにタイトルとコンテンツを、並べて表示させたほうがいい、という場合です。

対策としては、noindexを入れて、どこからもリンクが発生しないようにすればいいかもしれませんが、どうしても亡きものにしてしまいたいときは、リライトで404にしてしまえ。という方法がこれです。

add_filter( 'faqs_rewrite_rules', '__return_empty_array' ); 

faqs_rewrite_rules の faqs のところがカスタム投稿のスラッグです。

これを、function.phpなどにいれて、リライトルールをフラッシュすればOKです。
リライトルールのフラッシュは、管理画面の設定→パーマリンク設定→[変更を保存]をクリックするか、次のコードを1回だけ実行させます。

function flushRules(){
	global $wp_rewrite;
   	$wp_rewrite->flush_rules();
}
add_filter('init','flushRules');		

また、カスタムタクソノミーのアーカイブページを出力したくないときは、

add_filter( 'area_rewrite_rules', '__return_empty_array' ); 

をいれます。areaの部分がカスタムタクソノミーのスラッグです。

他にも、投稿ページや固定ページ、カテゴリーページなど表示させない、というハードボイルドな使い方もできます。

//投稿のシングルページを404に
add_filter( 'post_rewrite_rules', '__return_empty_array' ); 

//固定ページを404に
add_filter( 'page_rewrite_rules', '__return_empty_array' ); 

//カテゴリーページを404に
add_filter( 'category_rewrite_rules', '__return_empty_array' ); 

//投稿者アーカイブを404に
add_filter( 'author_rewrite_rules', '__return_empty_array' ); 

//検索結果ページを404に
add_filter( 'search_rewrite_rules', '__return_empty_array' ); 

詳しくは、関数リファレンスの、WP Rewriteのプラグインフックの項目にあるのですが、日本語版にはカスタム投稿やカスタムタクソノミーについては記載がありません。

ので、英語版の方をみてみると、

「Filter: {$permastruct}_rewrite_rules - Can be used to create or modify rewrite rules for any custom permastructs, such as taxonomies or custom post types.」

というのが見つかります。

もちろん、このフィルターフックは、ページを404にするためだけに存在しているのではなく、たとえばカスタムタクソノミーのアーカイブページにだけ、リライトルールを自作する、といったときにつかうことも出来るようです。

いろいろ調べ回って、突破口になりました。→初期状態のWordPressで作られるページ

ありがとうございます!

0

[MySQL]SELECTで取得したデータをカンマ区切りで横に並べる

MySQLで、SELECTするときに、取得したデータをカンマ区切りで横に並べて取得したいとき、GROUP_CONCATを使います。

まずはサンプルデータを作成。

CREATE TABLE member (group_id int , name varchar(20) , age int(3)); 
INSERT INTO member VALUES 
(1 , 'TANAKA' , 22 ) , (1 , 'HONDA' , 21 ), (1 , 'YOSHIDA' , 25 ), 
(2 , 'HIROSE' , 26 ), (2 , 'YAMADA' , 25 ), (2 , 'IKEDA' , 29 ), 
(3 , 'HARADA' , 28 ), (3 , 'OKUDA' , 22 ), (3 , 'OOTA' , 24 );

で、SELECTでデータを取得。 

SELECT group_id , GROUP_CONCAT(DISTINCT age SEPARATOR ',') FROM member GROUP BY group_id;

すると、こんな感じで取得できます。

1 22,21,25
2 26,25,29
3 28,22,24

DISTINCT  age で、ageをまとめます。

SEPARATOR ',' で、カンマ区切りとしています。

GROUP BY group_id で、group_id別でまとめるようにしています。

 

WHEREをつかえば、特定のgroup_idだけを取得できますね。

SELECT group_id , GROUP_CONCAT(DISTINCT age SEPARATOR ',') FROM member WHERE group_id=1
0

[WordPress]サイトアドレスの設定を間違えてログインできなくなった

WordPressの設定→一般設定

で、WordPress アドレス (URL)とサイトアドレス (URL)を間違えて設定してしまうと、管理画面に入れなくなって大変焦ります。慣れてしまうとどうってことないのですが、不慣れな人にとっては恐怖の設定です。

というわけで、WordPressにログインできなくなって、大変焦ったときの対処法。

FTP接続ツールは必須

まず、かならずファイル内容が編集できる手段(FTP接続等)が必要です。WordPressの管理画面しか設定手段がないとお手上げです。なので、WordPress管理者ではあるけれど、インストールは業者さんなどの別の人がした、という場合は、すみやかにその人にお願いするか、FTP接続できる手段を提供してもらうべきです。

もしくは、レンタルサーバーの「簡単インストール」のような機能を使ってインストールしたのなら、レンタルサーバーのファイルマネージャーをつかう方法もあります。

いずれにしても、WordPressをインストールしているディレクトリ(フォルダ)にある、config.phpを編集できることが必須です。

config.phpにWP_SITEURLとWP_HOMEを書き加える

アドレス (URL)とサイトアドレス (URL)をまちがって設定してしまった場合の対処方法を検索すると、この2つを「config.phpに書き加えましょう。」とあります。

define('WP_SITEURL', 'http://****.com');
define('WP_HOME', 'http://****.com');

ひとまずこれで解決しますが、defineを使うと、設定→一般設定 からアドレス (URL)とサイトアドレス (URL)を設定できなくなります。しかも、書き加えたdefineを消すと、もとに戻ってしまうので、根本的な解決にならないことがあります。(逆に、不用意に設定を変えられなくなるので安全とも言える)

なぜ、そんなことになるかというと、アドレス (URL)とサイトアドレス (URL)の設定そのものはデータベースに保存されているからです。defineは定義という意味で、データベースの内容そのものを書き換えるコマンドではありません。

update_optionでsiteurlとhomeを書き換える

なので、設定そのものを元に戻したかったら、update_optionを使ったほうが便利です。

update_option( 'siteurl', 'http://****.com' );
update_option( 'home', 'http://****.com' );

ただし、config.phpに書き込むときには、require_once(ABSPATH . 'wp-settings.php'); と書いている部分より下に書き込んでください。(つまり、config.phpの最後に書き加えればOK。)

正常にもどったら、書き込んだ update_option はもういりません。消しても大丈夫です。update_option は、データベースに保存されるWordPressのサイトオプションを上書きするからです。

 

0

[WirdPress]PHP7.1でエラーが発生「Exec-PHP」を修正

レンタルサーバーの設定を変えて、PHPのバージョンを7.1に変更すると、突如エラーが発生しました。

Parse error: syntax error, unexpected 'new' (T_NEW) in /xxxx/wp-content/plugins/exec-php/exec-php.php on line 22

これは、投稿記事内でPHPのコードを実行出来るようにするプラグイン「Exec-PHP」がPHP7.1以降に対応していないためのエラーです。
PHP7.1では、変数にクラスの参照代入ができなくなったためだそうで、プラグインのソースコードそのものに問題があることを示しています。

対策として、代わりのプラグインも試しましたが、同様にエラーが出たり、古すぎてWordPressの管理画面からは探せなかったりしてイマイチ。

ということで、ひとまず、Exec-PHP のコードそのものを変更して対処することにします。
プラグインのコードを変更するにはFTPクライアントなどから直接ファイルを開きます。
まずは、エラーの出ている、exec-php.phpを編集。

/wp-content/plugins/exec-php/exec-php.php

このファイルの22行目に、

$GLOBALS['g_execphp_manager'] =& new ExecPhp_Manager();

とありますので、 =& の &を削除します。

$GLOBALS['g_execphp_manager'] = new ExecPhp_Manager();

でも、これをしてもまた新たなエラーが発生します。

Parse error: syntax error, unexpected 'new' (T_NEW) in /xxxx/wp-content/plugins/exec-php/includes/manager.php on line 36

こんどは、manager.phpに問題があるようです。
/wp-content/plugins/exec-php/includes/manager.php
を開くと、36,37,38,39行目に同様に=&があります。

$cache =& new ExecPhp_Cache();
 $this->m_ajax =& new ExecPhp_Ajax($cache);
 $this->m_runtime =& new ExecPhp_Runtime($cache);
 $this->m_admin =& new ExecPHP_Admin($cache);

これも&を削除します。

$cache = new ExecPhp_Cache();
 $this->m_ajax = new ExecPhp_Ajax($cache);
 $this->m_runtime = new ExecPhp_Runtime($cache);
 $this->m_admin = new ExecPHP_Admin($cache);

他にも、

/wp-content/plugins/exec-php/includes/cache.php の22行目、39行目
/wp-content/plugins/exec-php/includes/ajax.php の64行目

にそれぞれ &= となっているところがあるので修正します。

これでエラーは出なくなります。

 

0

[BackWPup]エラー「ステップを中止: 回数が多すぎます!」の解決策

WordPressでデータを定期的にバックアップする、便利なプラグインBackWPupですが、あるサーバーで運用中のWPで、バックアップを実行した処、こんなエラーが出ました。

エラー: MySQLi 拡張モジュールが見つかりませんでした。それをインストールしてください。
エラー: ステップを中止: 回数が多すぎます!

原因は「PHPのMySQLi拡張モジュールがないから」。

なので、MySQLi拡張モジュールを導入すればいいのですが、多くのレンタルサーバーではそういう操作はできません。ただし、PHPのバージョンを上げることで対策できる場合もあるようです。

たとえば、ロリポップなら管理画面の「PHP設定」で変更できます。もし、バージョンが5.3以下だったら、それ以上のバージョンに上げると解決します。

ロリポップ管理画面のPHP設定でバージョンを変える。

ただし、中にはPHPのバージョンを上げることができない、不便なレンタルサーバーを利用している場合や、スペックの低い専用サーバーを使い続けざるを得ない、なんてこともあります。

そんなときは、BackWPupの設定を変えます。

BackWPupのジョブタクス設定

データベースの内容そのものではありませんが、記事やコメントなど主要な情報が復元できるので、ひとまずこれで対処できます。

 

0

Contactform7 でinputタグにautofocusを追加する

Contact form 7 で、出力されたinputタグに autofocus を追加する方法です。

現時点(2017年11月)では、Contact form 7には、autofocus属性を指定する方法はないようです。

正攻法では、なかなかいい方法がありません。そこで、class名にautoforcusを指定すると、autoforcus属性が追加されるようにします。

まずは、function.phpに以下を追記します。

add_filter( 'wpcf7_form_elements', 'my_wpcf7_form_elements' );
function my_wpcf7_form_elements( $content ) {
 $str_pos = strpos( $content, 'autofocus"' ) + strlen('autofocus"');
 $content = substr_replace( $content, ' autofocus ', $str_pos, 0 );
 return $content;
}

このコードでやっていることは、class="wpcf7-form-control wpcf7-text wpcf7-validates-as-required autofocus" などと表示される部分の 「autofocus"」を見つけて、その後ろに「 autofocus 」を挿入しています。かなり強引ですが。。。

使い方ですが、たとえば、

[text* your-name class:autofocus]

のようにつかいます。

もし、他にclassを指定しているのなら、autofocusが最後になるようにしてください。

例:[text* your-name class:hogehoge class:autofocus]

 

0

[WordPress]CSSとJSファイルを更新したらすぐに反映させるようにする

CSSファイルやJSファイルの中身を書き換えても、クライアントでキャッシュされていて、すぐに反映されないことになります。

スーパーリドード(ChoromeだとCtrl+F5)でキャシュは解消されて変更が反映されますが、すでに運用中などサイト閲覧者にもすぐに反映されるようにしたい場合はどうすればいいか、という話。

通常、スタイルシートの指定は、

<link rel='stylesheet' id='style-css' href='http://hoge.jp/wp-content/themes/sample/style.css' type='text/css' media='all' />

のようにしますが、ファイル名の指定のところで、?var=20171116のようにクエリを追加することで、別ファイル扱いとなり、キャシュされ直される、みたいなことのようです。

<link rel='stylesheet' id='style-css' href='http://hoge.jp/wp-content/themes/sample/style.css?ver=20171116' type='text/css' media='all' />

ということでCSSファイル名にバージョンをクエリで追加することになるのですが、いちいちバージョン名を書き換えるのは面倒なので、ファイルの更新日をfilemtime()関数で取得して追加することにしました。

こんな感じで。

function my_scripts(){
	//style.cssのファイル更新日を取得
	$date =  date("Ymd" , filemtime(get_stylesheet_directory() . '/style.css'));
	//style.cssを「?ver=日付」つきで出力
	wp_enqueue_style( 'style', get_stylesheet_directory_uri().'/style.css',false,$date);
	//responsive.jsのファイル更新日を取得
	$date =  date("Ymd" , filemtime(get_stylesheet_directory() . '/responsive.js'));
	//responsive.jsを「?ver=日付」つきで出力
	wp_enqueue_script( 'responsive-jquery', get_stylesheet_directory_uri() . '/responsive.js', array(), $date, true );
}
add_action( 'wp_enqueue_scripts', 'my_scripts', 10 );
0

Auto Post Thumbnail でjpeg画像が対応しない

どうも、Auto Post Thumbnail が機能しない。

あれこれ試していた結果、どうもJPEGを認知しないらしい。
この問題はすでに気がついている方がたくさんいて、主に2つ解決策があります。

対策1 古いバージョンに戻す

2017/11現在、最新バージョンは3.4.1ですが、その一つ前3.3.3では、JPEG問題は発生しません。そこで、3.3.3にもどして使う、という解決策。

古いバージョンは、https://ja.wordpress.org/plugins/auto-post-thumbnail/advanced/ にあって、「以前のバージョン」のところからダウンロードできます。ダウンロードしたファイルを、「プラグイン」→「新規追加」→[プラグインのアップロード] で追加します。

Auto Post Thumbnail バージョン 3.4.1だと自動アイキャッチ投稿が出来ない

WPプラグイン Auto Post Thumbnail が機能しなくなったぞい!

 

対策2 function.php にコードを追記する

で、なにが問題なのか調べてみると、

最新の3.4.1では、auto-post-thumbnail.php に、次のような箇所が追加されています。

//Fix for checking file extensions
$exts = explode(".",$filename);
if(count($exts)>2)return null;
$allowed=get_allowed_mime_types();
$ext=pathinfo($new_file,PATHINFO_EXTENSION);
if(!array_key_exists($ext,$allowed))return null;

どうやら、拡張子を使って、WordPressで対応している画像かどうかをチェックしているようです。対応していない画像を投稿すると問題が起きるのでしょう。(試してないのでわかりませんが)

記述されている、get_allowed_mime_types() ですが、この関数で取得できるのは、利用できる画像タイプの配列なのです。print_r(get_allowed_mime_types()); などとして配列の中身をみてみると、 JPEGに関しては、[jpg|jpeg|jpe] => image/jpeg  となってます。

Auto Post Thumbnail の3.4.1では、jpg|jpeg|jpe と、拡張子である jpeg などが一致しているかどうかをarray_key_exists を使って調べていますが、jpg と jpg|jpeg|jpe では文字として完全一致しないので、ここで return null となって、止まってしまいます。

一方で、JPEG以外の、たとえばPNGとかGIFとかなら、array_key_exists で取得した配列が、[gif] => image/gif  、[png] => image/png なので、Auto Post Thumbnail 3.4.1 でも問題なくサムネイル画像に設定できるはずです。

この問題について、こちらで解決策が紹介されています。

https://loumo.jp/wp/archive/20170703060006/

以下をfunction.phpに追記します。

function split_combined_mimes_for_apt( $mime_types ) {
    foreach ( $mime_types as $regex => $mime_type ) {
        if ( false !== strpos( $regex, '|' ) ) {
            $keys = explode( '|', $regex );
            foreach ( $keys as $key ) {
                $mime_types[ $key ] = $mime_type;
            }
        }
    }
    return $mime_types;
}
add_filter( 'mime_types', 'split_combined_mimes_for_apt' );

get_allowed_mime_types関数に、フィルターフックを使って、[jpg] => image/jpeg 、[jpeg] => image/jpeg 、[jpe] => image/jpeg の3つを追加するようにしています。これで、Auto Post Thumbnail でも、jpegに対応できるようにしています。

対策3 Auto Post Thumbnail を改修する

もしくは、Auto Post Thumbnail3.4.1 を直接書き換えます。

    //Fix for checking file extensions
    $exts = explode(".",$filename);
    if(count($exts)>2)return null;
    $allowed=get_allowed_mime_types();
    $ext=pathinfo($new_file,PATHINFO_EXTENSION);
    //if(!array_key_exists($ext,$allowed))return null;
    if ( !preg_grep("?".$ext."?",array_keys($allowed)) ) return null;

if(!array_key_exists($ext,$allowed))return null; を消して(コメントアウト)、if ( !preg_grep("?".$ext."?",array_keys($allowed)) ) return null; を追加します。

これで、JPEGにも対応出来るはずです。

まとめ

  1. 古いバージョン3.3.3に戻す(ただし、対応しない画像タイプで問題が起きる可能性あり)
  2. フックで対応。function.phpにコードを追記する。(get_allowed_mime_types を使っている他のプラグイン等に影響を与えるかも?)
  3. Auto Post Thubmnail 3.4.1  のコードを書き換えて改修する。(今後プラグインがアップグレードされると消えてしまう)

 

0

[WordPress]海外からの不正アタックを止めるIP制限

WordPressの乗っ取り。くらうと復帰が大変です。

ということで、やっぱり防御が一番大切。
アカウントとパスワードはしっかり管理することは当然ですが、セキュリティ対策として出来ることはするべきです。

WordPressのセキュリティプラグインはSiteGuardさんがおすすめ。

SiteGuard WP Plugin

なにがいいって、開発元が日本国内で設定画面を含め、日本語であるところ。そして、ログイン画面にひらがなの文字承認がつけられるのもいいですね。

そして、SiteGuardには、ログイン履歴を見ることも出来るのですが、ある日こんなことになっていました。

DDoSアタックだか、ブルートフォースアタックだか知りませんが、数分おきにアタックされてます。やめてくれ!って感じです。

セキュリティプラグインのお陰で、ブロックもしてくれるようですが、それでも心配だしサーバーにムダな負担をかけているようで気になります。

ということで、これらの変なアクセスをブロックしてしまいます。IPアドレスの場所を見ると、ほぼ海外からのアタックですので、国内以外のIPからは管理画面のログイン画面を含め、XMLRPCなどアタックの対象になるものをブロックします。

ブロックするのは、wp-admin、wp-login.php、xmlrpc.php、wp-cron.php の4つ。
WordPressの設置ディレクトリにある、.htaccessの最後に以下を追記します。(最後に追記するのは、あまりにも行数が多いから。)

<FilesMatch "wp-admin|wp-login\.php|xmlrpc\.php|wp-cron\.php">
order deny,allow
deny from all
allow from 1.0.16.0/20
allow from 1.0.64.0/18
allow from 1.1.64.0/18
     ・
     ・
     ・
allow from 223.223.164.0/22
allow from 223.223.208.0/21
allow from 223.223.224.0/19
</FilesMatch>

allow from のところに、アクセスを許可するIPアドレスを入れておきます。が。国内のIPアドレスすべてを入れるので、かなりの行数になります。

国内のIPアドレスは、こちら→http://www.cgis.biz/tools/access/
で教えていただけます。

 

 

0