The post WordPressのログイン画面・wp-adminを隠すには？完ぺきなやり方 first appeared on Fukuro Press.
]]>
WordPressのセキュリティの話。
こういう対策をしたい人向けの記事です。
- ログイン画面を外部から隠したい
- wp-adminをアクセス不可にしたい
そういう時はプラグインの力を借りましょう。
とても便利で使いやすいのも見つけたので、
導入方法をとても分かりやすく解説します。
これでセキュリテイ対策は万全です！
ログイン画面・wp-adminを隠すべき理由
WordPressログイン画面は誰でもアクセス可能。
例えば以下のブログドメインがあるとします。
↓ とあるブログのURL
URL : https://my-blog.com/
このログイン画面を開く方法は２つです。
↓ 次のURLにアクセスすればいい
URL : https://my-blog.com/wp-login.php
URL : https://my-blog.com/wp-admin
もう全世界から丸見えなんです。
攻撃者はログイン画面にすすめるか確認し、そこからパスワードを総当たりなどして不正アクセスします。とても怖い
だからログイン画面／wp-adminは隠すべきですね。
対策は Login Rebuilderプラグインの導入
根本的な対策はログイン画面を隠すことです。
でも技術的なことは素人には難しすぎます。
そこで登場が Login Rebuilderプラグイン
↓ こちらのプラグイン
このプラグインを使えば次のことができます。
- wp-login.phpへのアクセスを防げる
- wp-admin ⇒ ログインへのリダイレクト防止
- カスタムのログイン画面URLを作成できる
デフォルトのログイン画面を無効化できます。
そして wp-login.php のようなログインURLの代わりに、自分で任意のログインURLを作れちゃうという代物です。つまりログイン画面にたどり着けるのはあなただけ！
ある意味最強のセキュリティ対策と言えます。
１．Login Rebuilderプラグインを有効化
それではプラグインをインスト・有効化します。
プラグインの新規追加を開き、
そこで「login rebuilder」を検索してください。
↓ Login Rebuilderプラグインが出てくるはず
手動インストールする場合は次ページから
URL : https://ja.wordpress.org/plugins/login-rebuilder/
インストールが終わったら「今すぐインストール」ボタンが「有効化」ボタンに変わるので、最後にそれも押して有効化しておきましょう。
これでログイン画面を隠す準備ができました。
２．新しいログインURLを作成する
それではログイン画面を隠す作業に入ります。
プラグインの設定画面を開いてください。
↓「設定」⇒「ログインページ」とクリック
↓ このような画面が出てくる
※ 操作はまだ何もしないでください！
この時点ではログイン画面は隠されてません。
初めに以下設定項目に注目です。
↓ 「新しいログインファイル」の項目
この名前が新しいログイン画面のURLになります。
デフォルトだと your-login.php になってますね。
それだと簡単に推測されるので・・・
次のように複雑なログインファイル名にしておきます。
名前を付けるときは以下の点に注意が必要です。
- 半角英数字ならなんでも使ってOK
- 日本語など全角文字は使ってはダメ
- ハイフンなどの記号も含めてはダメ
- 最後に必ず「.php」を付けること
そして名前を絶対にメモしください！
あるいは画面ごとスクショするのでも良いです。
メモしましたか？？ＯＫなら次に進んでください。
最後にステータスを「稼働中」に切り替えましょう。
↓ このように切り替えする
そして設定画面下の「変更を保存」を押してください。
……はい、これでログイン画面が完全に隠されました。
３．隠しログイン画面にアクセスできるか確認
今設定したカスタムログイン画面、
そこに正常にアクセスできるか確かめてください。
↓ 例えば以下の隠しログイン画面を設定したなら…
↓ 次のURLから隠しログインページに入れる
URL : https://my-blog.com/login2O23O7lllOl6.php
↓ いつものログイン画面が開かれる
これでログイン画面・wp-adminを隠すことに成功です。
旧ログイン画面・wp-adminは403で隠される
ちなみにwp-login.php、wp-adminは403になります。
↓ 攻撃者はログイン画面にたどり着けない
ブログ管理者がログインURLを忘れなければOK
これでセキュリティが飛躍的に向上しました。
もし新しいログインURLを忘れたら？
ここからはトラブルシューティングの時間。
次のトラブルが起きてしまった場合です。
- 設定前に新ログインURLのメモを忘れた…
- 新しいログインURLを忘れてしまった…
こういう事態に陥っても大丈夫です。
その場合はプラグインを無効化しましょう。
「いや管理画面に入れないと無理では…？」
そう思うかもしれませんが、原始的に無効化できます。
- レンタルサーバーなどでFTP接続
- プラグインディレクトリを探す
- フォルダ login-rebuilder を探す
- それを __login-rebuilder に改名
より詳しい方法は以下の記事でも紹介しました。
技術に自信のある人はこの方法を試してください。
もしサッパリ意味不明という方は…
私自身がWordPressトラブル解決相談を実施してます。
お困りなら一度ご相談ください。（割引特典あり）
※ ただし依頼は一律価格でないことに要注意
平日休日祝日に関係なく対応できます。
セキュリテイを強めるための関連記事
WordPressセキュリテイの関連記事です。
↓ WPセキュリティを高める６つの対策
| WordPressはブログ作りに必須のツールと言っても過言ではありません。でもそれだけ広く普及していてからこそセキュリティの穴をついて不正ログインしようとする攻撃者が多いのが現実不正ログインされてしまうとブログを乗っ取られたり、他サイトへの攻撃の踏み台にされ加害者にもなってしまうこともあります。ここではその被害を防ぐためのWordPress向けセキュリティ対策をまとめました。不正ログイン防止の６つの対策不正ログイン防止のために "絶対" しておきたいのが次の対策１．ログインパスワードを使いまわさないここ... WordPressの不正ログインを防止してセキュリティを高める６つの対策 - Fukuro Press |
セキュリテイ意識はどれだけ高くても損しません。
過剰なくらいに対策するのが丁度いいです。
ということでログイン画面・wp-adminを隠す方法でした。
The post WordPressのログイン画面・wp-adminを隠すには？完ぺきなやり方 first appeared on Fukuro Press.
]]>The post ロリポップでPHP(WordPress)のメモリ不足が発生！解決方法の解説 first appeared on Fukuro Press.
]]>
ロリポップでこんなトラブルに遭遇しました。
- ブログをWordPressで動かしている
- プラグインもそこまで多く入れてない
- なのにPHP側でメモリ不足が発生…(困)
このPHPメモリ不足の原因と解決策。
ロリポップで修正する方法を解説します。
※ WordPressに限らずPHP全般でも有効
「サイトに重大なエラー」が発生しまくる
私自身のブログで発生した事件ではありません。
ある方からトラブル依頼を受けていました。
管理画面で何かしらの操作したとき、
↓ 以下のエラーが頻発していたそうです。
サイトに重大なエラーがありました。
WordPressでのデバッグをさらに詳しく見る
↓ 次の操作をすると確率的にエラーになる
- 管理画面のいずれかのページを開く、
- 投稿記事の編集ページだったり、
- メディア一覧ページだったり、
- コメントの管理ページだったり、
とにかく管理画面でエラーが発生してます。
厄介なのは必ず発生するのではなく、
数回に１回の頻度でランダムに起こることです。
原因はロリポップのPHPメモリ不足と判明
それで原因を色々調べることにしました。
調査していくと、↓こんなエラーが出てたと判明します。
Backend fatal error: PHP Fatal error: Allowed memory size of bytes exhausted (tried to allocate 40960 bytes) in /home/hogehoge/public_html/wp-includes/option.php on line 281
この「Allowed memory size of 134217728 bytes exhausted」というのは「メモリ足りない。メモリ不足」という意味です。具体的には134MBのメモリを消費してました。
最初はプラグインが原因かなと思ったんですよね。
でも結局はロリポップのメモリ設定に問題がありました。
WordPressが必要とするメモリ量が少なすぎたんです。
メモリをWP_MAX_MEMORY_LIMITで拡張したが…
WordPressでは、以下フラグでメモリ上限を変えれます。
WP_MAX_MEMORY_LIMIT
WP_MEMORY_LIMIT option allows you to specify the maximum amount of memory that can be consumed by PHP. This setting may be necessary in the event you receive a message such as “Allowed memory size of xxxxxx bytes exhausted”.
引用元 : https://developer.wordpress.org/apis/wp-config-php/#increasing-memory-allocated-to-php
これに必要なメモリ容量を代入するだけです。
具体的にはWordPressのwp-config.phpを開き、
最後あたりにメモリ容量を増やすコードを追加します。
↓ 具体的なwp-config.phpのコード修正例
/* メモリ上限の拡張 */
define('WP_MAX_MEMORY_LIMIT', '512M');
/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */
/** Absolute path to the WordPress directory. */
if (!defined('ABSPATH')) {
define('ABSPATH', dirname(__FILE__) . '/');
}
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');このように /* 編集が必要なのはここまでです...*/ の前に記述します。この例ではWP_MAX_MEMORY_LIMITに対して512M = 512メガバイトを割り当てました。
ところがPHPメモリ不足は解決せず・・・
別な方法を探すことにしました。
サーバーの.htaccessでPHPメモリ上限を変更
根本的な解決策は.htaccessで上限設定することです。
ロリポップでは以下の方法で上手く行きました。
１．php_value,php_flagを有効にする
初めにphp.iniでphp_value, php_flagを有効にします。
↓ メニューから「PHP設定」を開く
↓ 対象サイトの「php.ini」⇒「設定」をクリック
↓ 開いたら一番下の項目をOnにする（画像参照）
このようにphp_value, php_flagを利用可能にします。
そうすると.htaccessの設定が優先されます。
２．php_value memory_limit からメモリ上限変更
そしたら.htaccessを編集していきます。
↓ ロリポップFTPを開く
↓ .htaccessの最後に以下の命令を追加
## メモリ上限を512MBに拡張
php_value memory_limit 512M↓ 具体的にはWordPress設定の後に書く
# BEGIN WordPress
# "BEGIN WordPress" から "END WordPress" までのディレクティブ (行) は
# 動的に生成され、WordPress フィルターによってのみ修正が可能です。
# これらのマーカー間にあるディレクティブへのいかなる変更も上書きされてしまいます。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
## メモリ上限を512MBに拡張
php_value memory_limit 512Mここでは512MBまでメモリ上限を拡張してます。
その値は必要に応じて変更すればOKです。
これで.htaccessを保存してください。
PHPのメモリ上限が反映されたか確認
PHP側でメモリ上限の反映を確認します。
↓ .htaccessと同じフォルダにtest.phpを作成
<?php
echo ini_get('memory_limit');↓ そのtest.phpにブラウザからアクセス
上記のように.htaccessにて設定した php_value memory_limit の値が表示されれば成功です！あとはWordPressでメモリ不足が解決されたか確認してください。
もしメモリ不足が解決しないなら…
さらにPHPのメモリ上限を増やしてみてください。
トラブル解決にお困りならご相談を…
今回みたいなトラブルを解決したい、
でも技術的な知識がなくてトホーに暮れている…
そういう人の為にトラブル解決相談もやってます。
↓ ココナラで次のサービス運営中
お困りなら何でもご相談ください。
基本的にいつでも作業代行できます。
The post ロリポップでPHP(WordPress)のメモリ不足が発生！解決方法の解説 first appeared on Fukuro Press.
]]>The post WordPressで目次をプラグインなしで表示…具体的手順を解説 first appeared on Fukuro Press.
]]>
WordPressでの目次表示。
普通はTOC+プラグインを使うと思います。
※ TOC = Table of Content
でも自分で目次表示したい人もいます。
- 極力プラグインを使いたくない
- 目次程度なら自力で表示したい
そういう変わった人のために、
プラグインなしで目次表示の方法を解説します。
ここで行う目次実装の概要と注意点
大まかな手順はこのようになってます。
- 記事内の各見出しに自動でidを割り振る
- その見出し＋idを元に目次を自動生成
- 目次内から見出しにスクロールもできる
こういう実装を目指すことにします。
当たり前だけど初心者向けではありません。
ギリギリ中級者向けかなという程度の内容です。
だから次の人は試さないでください。
- WordPressの仕組みを理解してない
- PHPコードを読めない書けない
そういう人がこの記事に手を出すと、
間違いなくトラブルの原因になります。
もし目次表示のカスタマイズが必要なら…
▼ こういうサービスもあるのでご相談を
警告しておきました（念押し）
１．使用中テーマのfunctions.phpを開こう
ここでは使用中テーマを編集していきます。
具体的にはfunctions.phpに対する編集作業です。
▼ 外観 ⇒ テーマファイルエディタを開く
▼ テーマファイル ⇒ functions.php を開く
これは本当に重要なファイルです。
この内容を編集して構文エラーが起きたなら、最悪ブログがダウンします。もっとも最近のワードプレスなら更新前に警告してくれますが…
だからここからは慎重に作業してください。
ここまでで２回も念押ししました。
２．見出しに自動でidを振るコード追加
見出しとはh2～h6タグまでのこと
その見出しに自動生成したidを割り当てます。
具体的にはfunctions.phpに以下を追加します。
▼ このようなPHPコード追加
function auto_id_to_headings( $content ) {
$content = preg_replace_callback(
'/(\<h[1-6](.*?))\>(.*)(<\/h[1-6]>)/i', function( $matches ) {
if ( ! stripos( $matches[0], 'id=' ) ) {
/// 見出しにidがないなら自動生成
$matches[0] = $matches[1] . $matches[2]
. ' id="' . sanitize_title( $matches[3] )
. '">' . $matches[3] . $matches[4];
}
return $matches[0];
}, $content );
return $content;
}
add_filter( 'the_content', 'auto_id_to_headings', 10 );ポイントは見出しのタイトルから自動的にidを設定していることです。連番とか使う方法もあるけど、ここではこの方法を採用しました。
具体的には sanitize_title() によりタイトルから無効文字を除外し、idに使っても問題ない形式にしてます（参考記事 : https://elearn.jp/wpman/function/sanitize_title.html）
例えばこういう感じになるはず
<h2>Hello, I'm h2 tag</h2>
↓ 変換後 ↓
<h2 id="hello-im-h2-tag">Hello, I'm h2 tag</h2><h2>こんにちは、見出しです</h2>
↓ 変換後 ↓
<h2 id="%e3%81%93%e3%82%93%e3%81%ab%e3%81%a1%e3%81%af%e3%80%81%e8%a6%8b%e5%87%ba%e3%81%97%e3%81%a7%e3%81%99">こんにちは、見出しです</h2>※ 日本語はエンコードされる
自動でタイトルからidが割り振られます。
３．目次(TOC)を自動生成・表示するコード追加
いよいよ目次(TOC)を生成・表示してみます。
ここでは最初の見出し前に表示してみました。
▼ その具体的なPHPコード
function collate_toc_row($depth, $anchor, $heading) {
$level = substr($depth, 1);
if ( $anchor ) {
return ["<a href='#{$anchor}' class='{$depth} toc-link'>{$heading}</a>", $level];
} else {
$slug = sanitize_title($heading);
return ["<a href='#{$slug}' class='{$depth} toc-link'>{$heading}</a>", $level];
}
}
function add_toc_before_1st_heading( $content ){
/// 目次を自動生成して最初の見出し前に表示
preg_match_all('/<(h\d*)(?: id="(.*?)")?>((.*?))</',$content,$matches);
$levels = $matches[1];
$anchors = $matches[2];
$headings = $matches[3];
if ( $headings ) {
/// 見出しが１つ以上あるなら目次表示
$toc = '<div class="toc_container">';
$toc .= '<div class="title">Table of Contents</div>';
$collated = array_map('collate_toc_row', $levels, $anchors, $headings );
$previous_level = 2;
$toc .= '<ol class="toc-list">';
foreach ($collated as $row) {
$current_level = $row[1];
if ( $current_level == $previous_level ) {
$toc .= '<li>' . $row[0];
} else if ( $current_level < $previous_level ) {
$toc .= str_repeat('</ol>', $previous_level - $current_level) . '<li>'. $row[0];
} else {
$toc .= '<ol><li>' . $row[0];
}
$previous_level = $row[1];
}
$toc .= str_repeat('</ol>', $previous_level) . '</li></ol>';
$toc .= '</div>';
$content_parts = preg_split("/(<h\d*)/", $content, 2, PREG_SPLIT_DELIM_CAPTURE);
$content = $content_parts[0] . $toc . $content_parts[1].$content_parts[2];
}
return $content;
}
add_filter( 'the_content', 'add_toc_before_1st_heading', 11);長すぎるから細かな解説はしません。
記事内のすべての見出し（h1～h6）をスキャンし、それを元に目次を自動生成。最初の見出しの前にTOCを挟み込んでるだけです。
見出しが１つもない記事には目次表示されません。
４．目次のレイアウト用にCSSを追加
できあがった目次は質素な見た目です。
だからレイアウトを整えます。
具体的には次のようなCSSコードを追加しました。
▼ 目次に適用したCSSコード例
.toc_container{
overflow: auto;
padding: 10px;
background: #f9f9f9;
border: 1px solid #aaa;
}
.toc_container .title{
text-align: center;
padding-top: 10px;
}
.toc-list{
list-style: none;
font-size: 20px !important;
margin: 0;
padding: 10px;
float: left;
position: relative;
left: 50%;
transform: translateX(-50%);
}
.toc-list ol{
list-style: none;
}
.toc-list a{
font-size: 16px;
}ここまで読み進められる人なら「このCSSどこに追加すればいいの？分からないよ～(泣」なんてバカなことは言わないはずです。
好きなようにCSSは改変してください。
こんなビジュアルの目次ができた！
できあがった目次はこんなビジュアルです。
見てわかる通り、レイアウトは完全にTOC+プラグインのそれです。あと目次リンクをクリックすると各見出しにスクロールもしてくれます。
まだ未完全だけど目次としては機能してます。
WordPressでプラグインなしでの目次の作り方は以上。
チャレンジ精神のある人は試してみてください。
The post WordPressで目次をプラグインなしで表示…具体的手順を解説 first appeared on Fukuro Press.
]]>The post カスタム投稿を月別アーカイブ・カテゴリー一覧に表示させる方法 first appeared on Fukuro Press.
]]>
WordPressでカスタム投稿タイプを作りました。
次みたいなプラグインを使うのが簡単ですよね。
↓ Custom Post Type UIプラグイン
https://wordpress.org/plugins/custom-post-type-ui
カスタム投稿を作ったまでは良いですが、
どうしてか以下の一覧ページに表示されません。
- 日別・月別アーカイブ
- カテゴリー一覧ページ
- タグ一覧ページ
- トップページの記事一覧
この対処法について私が解説します。
CPT UIプラグインでカスタム投稿を作った
私は次のようなカスタム投稿を作りました。
▼ 実際のCPT UIプラグインの設定画面
※ 英語表示なのは気にしないでください
「Online Tool」というカスタム投稿を作りました。
↓ そしてタクソノミーにもチェック済です。
これで一覧に表示されると思ったんですが…
↓ こういう厄介な現象が発生した
- カスタム投稿がカテゴリー一覧に表示されない
- カスタム投稿がタグ一覧に表示されない
- カスタム投稿が月別アーカイブに表示されない
- あらゆる一覧にカスタム投稿が表示されない
カスタム投稿は個別投稿（post）とは切り離された存在です。
だからカテゴリー・タグ・月別一覧などでは認識されないという訳です。
だからWordPress挙動に手を加える必要があります。
カスタム投稿を一覧に表示させる修正方法
以下のような手順でうまくいきます。
ただしWordPressテーマを直接修正します。
※ だから自己責任で行ってください
※ WPバックアップも取っておいてください
１．カスタム投稿でアーカイブを有効にする
初めにCPT UIプラグインを開きます。
設定画面を開いたら「Add/Edit Post Types」＝＞（編集したいカスタム投稿を選択）＝＞「Settings」と進んでください。
そして「Has Archive」をTrueに変更します。
↓ 以下の画像を参照
デフォルトだとFalseだと思うんですよね。
だからTrueに変更しておきます。
２．使用テーマのfunctions.phpにコード追加
次に使用中のWordPressテーマを修正します。
ただし以下に当てはまるなら試さないでください。
- WordPressの仕組みを理解していない
- PHPコードを読めないし書けもしない
- トラブルが起きても自分で対処できない
そういう人にはリスクが高すぎる方法です。
リスクを理解したうえで次を試してください。
やることはfunctions,phpへのコード追加です。
add_action( 'pre_get_posts', function ( $query )
{
if ( !is_admin() // 管理画面では無効化
&& $query->is_main_query() // メインクエリ限定
&& (
$query->is_category() /// カテゴリー
||
$query->is_tag() /// タグ
)
) {
$query->set( 'post_type', ['post', 'online-tool'] );
}
});このコードではpre_get_postsアクションフックにより、一覧の取得挙動をカスタムしています。ただし管理画面以外・メインクエリ限定という条件です。
また今回はカテゴリー・タグ一覧に表示させたいので、絞込みとして $query->is_category() || $query->is_tag() という条件も追加しています。
そして重要なのが次のコード
/// このコードだけ抜き出し
$query->set( 'post_type', ['post', 'online-tool'] );これで投稿一覧に online-tool というカスタム投稿タイプも表示されるように改良しています。ここは各自の投稿タイプに置き換えてください。
もし以上を読んでチンプンカンプンなら…
絶対に興味本位で試さないでください！！
※ もし壊れたら私に相談してください ※
上記コードで月別アーカイブにも対応させる
上記はカテゴリー・タグだけに対応してます。
月別アーカイブへのカスタム投稿タイプの表示…
それには以下のコードを使用してください。
↓ さらに改良したコード例
add_action( 'pre_get_posts', function ( $query )
{
if ( !is_admin() // 管理画面では無効化
&& $query->is_main_query() // メインクエリ限定
&& (
$query->is_category() /// カテゴリー
||
$query->is_tag() /// タグ
||
$query->is_month() /// 月別アーカイブ
)
) {
$query->set( 'post_type', ['post', 'online-tool'] );
}
});条件分岐タグで色々な一覧アーカイブに対応できます。
↓ 詳しくは以下リファレンスを参照のこと
URL : https://wpdocs.osdn.jp/条件分岐タグ
何度も言いますが、自己責任で行ってください。
もし自分一人で解決できないなら…
最後にアドバイスです。
上記作業はWordPressの仕組みを知っていて、
なおかつPHPコードも書ける人向けの方法です。
自分一人では解決できない人も多いでしょう。
↓ そういう時はサービスを使ってみてください。
特に修正代行依頼したいなら１番目のサービスが一番
そこで 《Webサイト制作・Webデザイン》
から依頼してみてください。
ちなみに・・・私もそこでサービスを開いてます。
WordPress経験の長さだったり、
トラブルを自力解決した経験だったり、
それを武器にWPトラブル解決相談をやってます。
お困りなら気軽にご相談ください。
The post カスタム投稿を月別アーカイブ・カテゴリー一覧に表示させる方法 first appeared on Fukuro Press.
]]>The post プラグインなしでWordPressページをリダイレクトする方法【PHPコード例】 first appeared on Fukuro Press.
]]>
WordPressで次のような処理が必要でした
- 投稿ページを個別にリダイレクト
- ある規則に沿ってページリダイレクト
- ただしプラグインは使いたくない
本当はプラグインを入れるのが確実だけど、どうしてもプラグインなしでリダイレクト（Redirect）したい場面があります。（PHPコードでどうにかしたい）
そんなマニアックな悩みへの解決策です。
ただし自己責任で行ってください。
個別ページごとにリダイレクトする方法
例えばこんなケースを考えてみましょう。
↓ リダイレクトさせたいWP投稿ページURL
https://example.com/hoge/post-1234
↓ これを次のURLにリダイレクトさせたい
https://example.com/hoge/jikosyoukai
後から投稿URLを変えたいパターンです。
WordPress投稿画面では記事作成すると post-1234 みたいなスラッグが自動生成され、それに気づかないで記事投稿することがあります。そんな時に個別URLだけリダイレクトさせたいみたいな…
※ より正確に書くなら 自動生成されたスラッグで公開 ⇒ Googleにインデックスされる ⇒ 検索流入でアクセスがある ← こういうスラッグを手動変更できない状況を想定
そんな時は次の手順でリダイレクト可能です。
１．使用してるテーマのfunctions.phpを開く
ここではPHPコードで何とかします。
だから初めにテーマのfunctions.phpを開きましょう。
↓ 外観 -> テーマファイルエディター を開く
↓ 右のファイル一覧から function.php オープン
ただし親テーマを直接編集するのは良くありません。
念のために子テーマを作っておいてください。
▼ プラグインによるWP子テーマの作り方
なくてもいいけど親テーマを更新したら親テーマへの変更はすべて消えちゃいます。それを防ぐために子テーマという仕組みがあるんですね。
とりあえずfunctions.phpを開ければヨシ
２．リダイレクト用のPHPコードを追加する
ここでは次のリダイレクトをします。
- リダイレク元ページURL
https://example.com/hoge/post-1234
- リダイレクト先ページURL
https://example.com/hoge/jikosyoukai
その場合はfunctions.phpにこんなコードを追加します。
↓ 個別にリダイレクトさせるコード例
function redirect_page() {
if (isset($_SERVER['HTTPS']) &&
($_SERVER['HTTPS'] == 'on' || $_SERVER['HTTPS'] == 1) ||
isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
$_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https'
) {
$protocol = 'https://';
}else {
$protocol = 'http://';
}
$currenturl = $protocol.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
$request_uri = $_SERVER['REQUEST_URI'];
switch ($request_uri) {
case '/hoge/post-1234':
$urlto = home_url('/hoge/jikosyoukai');
break;
default:
return;
}
if ($currenturl != $urlto)
exit( wp_redirect( $urlto ) );
}
add_action( 'template_redirect', 'redirect_page' );何してるかは大まかに分かりますよね？
分からないなら手を出さないでください。
リダイレクトを正規表現的に行うPHPコード例
ここからはさらに応用的な話です。
もっと汎用的なリダイレクト処理をしてみます。
例えば次のリダイレクトルールを考えます。
- リダイレクト前 : 投稿日時が含まれるURL
https://example.com/2022/11/19/my-post
- リダイレクト後 : 日時を含まないURL
https://example.com//my-post
初めはスラッグ規則を「投稿日時＋投稿名」にしていたけど、あとからパーマリンク設定を変えて「投稿名」だけにしたケースです。
その場合、汎用的なリダイレクトで対処可能です。
↓ より汎用的なリダイレクトPHPコード例
function redirect_page() {
if (isset($_SERVER['HTTPS']) &&
($_SERVER['HTTPS'] == 'on' || $_SERVER['HTTPS'] == 1) ||
isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
$_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https'
) {
$protocol = 'https://';
} else {
$protocol = 'http://';
}
$currenturl = $protocol.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
$request_uri = $_SERVER['REQUEST_URI']; //wp_make_link_relative($currenturl);
$redirect_pattern_1 = '/[0-9]{2}\\/[0-9]{2}\\/[0-9]{2}/i';
if(preg_match($redirect_pattern_1, $request_uri) !== 0){
$urlto = home_url(preg_replace($redirect_pattern_1, '', $request_uri));
}else{
return;
}
if ($currenturl != $urlto)
exit( wp_redirect( $urlto ) );
}
add_action( 'template_redirect', 'redirect_page' );かなり分かりにくいですね…
本当に原始的にリダイレクトルールを定義してます。
普通にリダイレクトプラグイン使うのが確実
身もふたもないけど次の結論に至りました。
《《 普通にプラグイン使う方が楽 》》
だって自分でPHPコードを書いてしまうと、
- リダイレクトの度にコード追加が必要
- WordPress構成を破壊するリスクがある
- 不具合が出たらすべて自己責任になる
ここまでリスクを取る価値はあるのか…
リダイレクト規則が１つか２つなら問題ないかも
でも複数のリダイレクトルールが必要なら、
大人しくプラグインを使うのが賢いと思います。
▼ この記事のRedirectionプラグインが優秀！
プラグインを使うのが確実ですね。
The post プラグインなしでWordPressページをリダイレクトする方法【PHPコード例】 first appeared on Fukuro Press.
]]>The post WordPressに独自のMySQLテーブル作成・読み書きする正しい方法とは？検証結果 first appeared on Fukuro Press.
]]>
WordPressへのMySQLテーブル作成
これをググってみたところ…
- どの情報が正しいのかサッパリ分からない、
- ブログごとに試している方法がバラバラ、
- オマケに公式では説明すらされていない
そういった事態に遭遇しました。
MySQLテーブルの作成とかレアケースだし、
読み書きするなんて普通はしないですからね(困)
そこで何が正しいのか検証してみました。
ググるとdb.phpの情報とか色々出てくるが……
ググってみたら色々情報は出てきます。
↓ いくつか例を挙げるなら以下の通り
- https://qiita.com/fuku_up/items/28e7540cac7cfc1602f1
こちらでは独自テーブル作成後に /wp-includes/wp-db.php に追加テーブルを登録している。方法としてはかなりリスクが高いと思う
- https://blog.at-human.com/2021/06/wp-original-tables/
こちらでは wp-db.php を編集する方法を批判しつつ、より安全度の高い /wp-content/db.php にDB設定を上書きする方法を採用している
特に前者の方法がググると山ほど出てきます。
だからwp-db.phpの編集が必須と思い込んでました。
ところが実際に検証していくと「ん？」と思うようなこともあったし、どうやら検索トップの情報は正しくないみたいです。（ ← SEOを学んでいくと気づく事実）
また後者のdb.phpの方法も違和感があります。
だから実際に検証してみました。
まずphpMyAdminから検証用テーブルを作ってみた
初めにphpMyAdminから適当にテーブル作成します。
WordPressではテーブル名に接頭辞を付けます。
デフォルトだと wp_ が標準的に使われるみたいです。
↓ まずは接頭辞ありのテーブル作成
CREATE TABLE wp_test (
id mediumint(9) NOT NULL AUTO_INCREMENT,
name tinytext NOT NULL,
UNIQUE KEY id (id)
)↓ つぎは接頭辞なしのテーブル作成
CREATE TABLE test (
id mediumint(9) NOT NULL AUTO_INCREMENT,
name tinytext NOT NULL,
UNIQUE KEY id (id)
)↓ テストレコードを挿入
ひとまずこの２つをテスト用に用意しました。
なんとwp-db.phpの編集なしでも読み書きできた！
それでは実際に読み書きしてみます。
ググって出てくる情報によると wp-db.php を編集しろと書いてあったり、db.php でデータベース構成を上書きしろとか書いてあるって話でした。
ここではそれらをすべて無視します。
↓ そして以下コードを試してみました。
add_action('wp_footer', 'my_test_custom_tables');
function my_test_custom_tables(){
global $wpdb;
/// 接頭辞ありのレコード取得
$results = $wpdb->get_results( "SELECT * FROM wp_test");
print_r("wp_test : " . json_encode($results));
/// 接頭辞なしのレコード取得
$results = $wpdb->get_results( "SELECT * FROM test");
print_r("test : " . json_encode($results));
}↓ どちらも問題なく取得できてしまった…
wp_test : [
{"id":"1","name":"山田太郎"},
{"id":"2","name":"山田花子"}
]
test : [
{"id":"1","name":"山田太郎"},
{"id":"2","name":"山田花子"}
]もちろん書き込みについても同様です。
なんの問題もなく警告も出ずにできました。
ググった情報は何だったのかというレベル
ちなみに検証に使用したWordPress環境について
もちろん全WordPressバージョンで検証はしてません。
↓ 検証に使用したWordPress/サーバー環境
- WordPress5.6.9
- phpMyAdminが使用可能
少なくとも5.6.9以降なら問題ないかと
本当にwp-db.phpの編集も必要なかったです。
WordPress5.6以前ではdb.phpの編集も必要かも
ただしWordPress5.6未満では保証できません。
↓ 独自MySQLテーブルには以下の設定が必要かも
- /wp-includes/wp-db.phpにて構成編集
- /wp-content/db.phpを作ってDB構成上書き
もしWordPress4.*.*以下を使っているなら…独自テーブルの読み書きに上記行為が必要になる可能性があります。そこは各自の環境次第です。
私自身はこれ以上の検証はしません。
ひとまずver5.6.9以降の結果が分かれば満足です。
The post WordPressに独自のMySQLテーブル作成・読み書きする正しい方法とは？検証結果 first appeared on Fukuro Press.
]]>The post WordPressからsmtpでメール送信する２つの設定方法を解説 first appeared on Fukuro Press.
]]>
WordPressからsmtpでメール送信
これにはいくつか方法があります。
- コード(PHP)から設定してメール送信
- プラグインから設定してメール送信
もし技術的なことがしたいなら前者の方法、
単純にsmtpでメール送信したいなら後者の方法です。
それぞれを出来るだけ分かりやすく解説します。
前提．初めにsmtp設定をサーバー側でやっておこう
ここは具体的には解説しません。
なぜならメール送信するのが目的だからです。
サーバーでSMTP設定済みの前提で説明していきます。
SMTPでメール送信する方法はサーバーごとに違うので、
設定してないなら次の公式ページを参考にしてください。
↓ 各レンタルサーバーごとの設定手順
- さくらのレンタルサーバー
メールソフトの一般的な設定をしたい : https://help.sakura.ad.jp/mail/2114/?article_anchor=js-nav-0
- エックスサーバー
- ロリポップ
各種メールソフトの設定方法 : https://lolipop.jp/manual/mail/mail-set/
- スターサーバー
メールソフトの設定内容について : https://www.star.ne.jp/manual/mail_setting.php
- Conoha WING
メールクライアントソフトを設定する : https://support.conoha.jp/w/mailclient/
どのレンタルサーバーでも 独自メールアドレスを作成 ⇒ サーバーごとのSMTP接続情報を確認 という手順は変わりません。
独自メルアドを作るのも数分あればできるし、手間もかからないです。サーバーごとに手順は少し異なるので、そこは各自でなんとかしてください。
SMTP接続情報については確認済みという前提で……
方法１．PHPコードからSMTP設定してメール送信
この方法は次のような上級者向けです。
- PHPコードがそれなりに書けて読める
- 自前でコード追加するリスクを理解している
- 自分の責任でコードを管理できる
とにかく自己責任でやってください。
もしWordPress初心者・中級者、
あるいはメール送信をしたいだけの場合……
絶対に後者の方法を使うのがマストです。
それでは具体的な方法をこれから教えます。
１．使用中テーマのfunctions.phpにコード追加
まず使用中テーマのfunctions.phpを開きます。
管理画面から「外観」＝＞「テーマの編集」をクリック
そのあとfunctions.phpを開けばいいだけです。
開いたら次のようなコードを追加します。
↓ これは例なので各自の環境で変えること！
add_action("phpmailer_init", "send_smtp_email");
function send_smtp_email( $phpmailer ) {
$phpmailer->isSMTP();
$phpmailer->Host = "[SMTPサーバー]";
$phpmailer->SMTPAuth = true;
$phpmailer->Port = 465;
$phpmailer->SMTPSecure = "tls";
$phpmailer->Username = "[メールアドレス]";
$phpmailer->Password = "[パスワード]";
$phpmailer->From = "[送信元アドレス]";
$phpmailer->FromName = "[送信者名]";
}↓ 上記コードの各オプションの意味
- $phpmailer->Host
使用しているSMTPサーバーのアドレス。例えばエックスサーバーなら sv***.xserver.jp のような形式。これはサーバー側のSMTP接続情報から確認できる
- $phpmailer->SMTPAuth
SMTP認証を使うかどうか。当然ながら true にする
- $phpmailer->Port
SMTP送信する時に使うポート番号。SMTP+SSLで送信するなら 465 、SSLを利用しないなら 587 と設定すればいい。（特別な事情がなければ 465 にする）
- $phpmailer->Username
独自メールアドレス。例えば hogehoge@fukuro-press.com のようにドメイン名まで含めたメールアドレス全体を渡す。
- $phpmailer->Password
各レンタルサーバーで独自メルアドを作るときに設定したパスワード。必ず設定するので忘れたなんてことはないはず
- $phpmailer->From
送信元のメールアドレス。これは $phpmailer->Username と同じ独自メルアドを設定しておけばOK
- $phpmailer->FromName
送信先にメールが届いたときに表示したい送信者名。パット見たときに「あの人(ブログ)(サービス)か！」と分かる名前にするのがベター
難しそうに見えるけど、設定項目は多くありません。
こういう感じで設定しておいてください。
２．テストメールをwp_mail()から送信してみる
ここまでの設定が正しければ届きます。
実際のメール送信は次コードで試してください。
↓ WordPress標準のメール送信APIを使う
wp_mail(
"fukuropress@gmail.com",
"届きましたか？",
/// => サブジェクト（件名）
"このメールが見れたなら設定は完ぺき！"
/// => ボディ（メール内容）
);届いたなら設定はすべて上手くいっています！
お疲れさまでした。
方法２．プラグインから設定してSMTPメール送信
この方法は誰でも簡単に設定できる方法です。
特別な事情がないなら、次のプラグインを使って下さい。
１．FluentSMTPプラグインをインストール
プラグインの新規追加画面を開きます。
そこで「FluentSMTP」と検索してください
↓ こういうのが出てくるのでインストール＆有効化
プラグインURL : https://ja.wordpress.org/plugins/fluent-smtp/
インストールしたら有効化するのも忘れずに。
２．設定画面からSMTPでメールアドレスを追加する
次はメールアドレス送信の設定です。
↓ WP管理画面で「設定」＝＞「Fluent SMTP」をクリック
メールプロバイダの接続設定画面が表示されます。
↓ その中から「Other SMTP」を選ぶ
↓ メール送信者の設定
↓ SMTP・メールアドレスの設定
赤枠のところに注目！！
↓ そこには以下内容を入力していきます。
- 送信者メールアドレス
メールを受け取った相手に表示されるメールアドレス。これはレンタルサーバーで作成したメルアドをそのまま入力すればOK
- 送信者名
送信先にメールが届いたときに表示したい送信者名。パット見たときに「あのブログだ！」「あのサービスかな？」とすぐ分かる名前にするのがベター
- SMTP Host
メール送信するSMTPサーバーのアドレス。例えばXサーバーなら sv***.xserver.jp のような形式。これはサーバー管理画面などから確認できる
- SMTP Port
ここはSMTPを使ってるなら 465 にしておけば間違いない。もしSSLを使わないなら 587 でもいいけど、特別な事情がなければ 465 にしておく
- Encryption
普通に「SSL」を選択しておく
- SMTP Username
サーバー側で作成した独自メールアドレスを入力する。例えば hogehoge@fukuro-press.com のようにドメイン名まで含めたメールアドレス全体
- SMTP Password
サーバー側で作成した独自メールアドレスのパスワード。作成時にかならず設定しているので、忘れたとか言わないこと
あとは「接続設定を保存」のボタンを押すだけです。
少し大変だけど頑張って入力設定してください。
３．SMTP設定が正しいかテストメール送信する
最後にテストメールを送信してみます。
プラグイン画面の「Email Test」から送信可能です。
↓ このような画面からテスト送信できる
設定画面の「From」には独自メールアドレスを、「Send to」にはテスト送信先のメルアドを入力します。HTMLはON/OFFどっちでもいいです。
そしたら「Send Test Email」を押して送信
メールが届いたなら設定は完ぺきです！
お疲れ様でした。
The post WordPressからsmtpでメール送信する２つの設定方法を解説 first appeared on Fukuro Press.
]]>The post 「syntax error, unexpected ‘?’」が出た時のWordPress対処法 first appeared on Fukuro Press.
]]>
WordPress管理画面にログインした時のこと…
真っ白画面にこんなエラーが表示されました。
Parse error: syntax error, unexpected '?'
少し厄介なエラーではありますが、
自力で解決することも不可能ではありません。
この解決方法には２種類があります。
※ ただしセルフ解決するなら自己責任！！
その原因・解決策とかを色々解説していきます。
なぜか syntax error, unexpected '?' がログイン画面で発生
WordPressにログインしようとした時
なぜか次のホワイトスクリーンに遭遇しました。
▼ 全ＷＰユーザーが恐れるあの画面
Parse error: syntax error, unexpected '?' in /home/hogehoge/hogehoge.com/public_html/wp-content/plugins/jm-twitter-cards/admin/views/settings/settings.php on line 61
簡単に説明すると Syntax error = 「構文エラー」のこと、そして原因は unexpected '?' = 「予期せぬはてなマークあるよ」とエラーメッセージは伝えています。
分からない人からしたら厄介すぎる問題です。
原因はプラグインの入れすぎ＆不用意に最新アプデしたこと
実はログイン前に次を試したんですよね。
- 未更新のプラグインがあるのを気づく
- それを最新にアップデート
プラグインのどれかがエラー排出したようです。
なぜ分かったかは先ほどのエラーに書いてあったから
↓ この短いエラーにたくさんのヒントが隠れている
Parse error: syntax error, unexpected '?' in /home/hogehoge/hogehoge.com/public_html/wp-content/plugins/jm-twitter-cards/admin/views/settings/settings.php on line 61
↓ jm-twitter-cardsプラグインのsettings.phpが原因
/home/hogehoge/hogehoge.com/public_html/wp-content/plugins/jm-twitter-cards/admin/views/settings/settings.php
このようにWordPressでは pluginsフォルダにプラグイン全てが格納されていて、その中のフォルダ名（ここではjm-twitter-cards）がプラグイン名をあらわしてます。
その中のsettings.phpが構文エラーを吐いていた……
こういう風にエラーメッセージから色々推理できます。
これは使える知識なので知ってて損はないです。
問題のプラグインPHPファイルを開いて確認した
次にエラー原因のプラグインファイルを調べました。
↓ 以下の場所に問題があった
[
'name' => 'twitterImage',
'label' => esc_html__('Image Fallback', 'jm-tc'),
'type' => 'file',
'default' => $opts["twitterImage"] ?? "",
],↓ エラー行だけを抜き出すとココ
'default' => $opts["twitterImage"] ?? ""ここが syntax error, unexpected '?' の原因。
なんとPHP7以上でしか動かない構文なんです。
でもPHPコードとしては正しい真っ当なコードです。
- 自分の環境はPHP5で動いていた
- だからPHP7の最新構文には対応してない
- 結果としてエラー発生(泣)
こういう理由だったと分析で判明しました。
この ?? = はてな2つ はnull合体演算子という構文
この構文はnull合体演算子と呼ばれる構文です。
↓ null合体演算子のシンプルな例
$opts = ["name" => "Fukuro"];
$name = $opts["name"] ?? "Unknown";このコードだと $opts["name"] がnullでなかったらその値を採用し、もしnullだったら右の値 "Unknown" が評価されるって感じです。
PHP7以前の書き方なら次と同じになります。
↓ null合体演算子はPHP5以前ならこう書ける
$opts = ["name" => "Fukuro"];
$name = isset($opts["name"])
? $opts["name"] : "Unknown";プログラマーは冗長さを嫌うそうです。
だからできるだけ短くムダなく書きたい。
その願望を叶えるのがnull合体演算子という訳です。
それがエラーの原因とは皮肉ですね……
このsyntax error, unexpected '?'のWordPressでの解決策
まあWordPressに限った話ではないです。
次のどちらかの解決策を試してください。
１．PHPバージョンを思い切ってPHP7に切り替える
初めに思いつくのはPHP7に切り替えること
そもそも古いPHPを使ってるのが原因です。
だからPHPバージョン7に切り替えるのがベスト
ところがリスクもあるから気を付けてください。
- 互換性のないコードによるエラーリスク
→ PHP5以下では動いてたけどPHP7以降では動かないコードがプラグイン・テーマに紛れてるかも。そういうリスクを覚悟すべき - 古いWordPressだとPHP7と互換性がないリスク
→ 断言できないけどWordPressバージョン（ver3以下？）ではPHP7・PHP8などと互換性がないケースがある。そういうリスクを覚悟すべき
このリスクを受け入れるなら試してください。
以下はWordPress + PHPバージョンアップの関連記事
▼ WordPressサーバー応答時間を短縮する効果的な方法
▼ PHPバージョンアップでWordPresエラーの対処法
相当リスクがあるので自己責任でお願いします。
PHPコードが書けてWordPresも理解している……
そういう人は自力解決に挑戦してみてください。
２．古いPHPと互換性のあるコードに修正する
この syntax error, unexpected '?' エラー
そもそも古いPHPと互換性がないから問題です。
それなら古いPHPと互換性のある書き方に直せば解決
↓ 例えば先ほどのプラグインコード例（×）
[
'name' => 'twitterImage',
'label' => esc_html__('Image Fallback', 'jm-tc'),
'type' => 'file',
'default' => $opts["twitterImage"] ?? "",
],↓ このコードなら次のように修正する（○）
[
'name' => 'twitterImage',
'label' => esc_html__('Image Fallback', 'jm-tc'),
'type' => 'file',
'default' => isset($opts["twitterImage"])
? $opts["twitterImage"] : "",
],地道にnull合体演算子が使われているプラグイン・テーマのコードを修正していってください。あるいは使わないなら停止するか・削除するでもＯＫです。
とにかくnull合体演算子を使わないコードにする
もちろん自己解決するなら自己責任でお願いします。
WordPress初心者・中級者なら詳しい人に相談しよう
以上の方法はWP初心者には難易度高すぎです。
- 最低でもPHPコードが書けないといけない
- エラー箇所を自分で修正しないといけない
- PHPバージョンアップもリスクが大きい
問題をさらに悪化させることもあります。
少なくともWordPress初心者にはムズすぎです。
もし自力解決できずに困っているなら……
迷わず次の場所で相談した方がいいですよ。
特に修正代行依頼したいなら１番目のサービスが一番
そこで 《Webサイト制作・Webデザイン》 から依頼してみてください。
ちなみに、私自身もそこでサービス出品してます。
WordPressブログ経験歴の長さ。
トラブルに遭遇して自力解決した経験。
それを武器にWPトラブル解決相談をやってます。
もしお困りならお気軽にご相談ください。
The post 「syntax error, unexpected ‘?’」が出た時のWordPress対処法 first appeared on Fukuro Press.
]]>The post 「WordPressの次」はいらないし求められてもいない理由【Newtの件】 first appeared on Fukuro Press.
]]>
つい最近、面白そうな記事を発見
▼ WordPressの次を担うサービスを作る
| 私達は、2021年4月に創業したスタートアップ企業です。現在は、東京都の有楽町を拠点に3名のメンバーでヘッドレスCMS「Newt（ニュート）」を開発しています。 WordPressの次を担うサービスを作る - www.newt.so |
※ 本当はリンクすら張りたくない (-_-;)
なにやらWordPressの次と豪語されています。
もちろん記事全文を読みました。
その上でWPユーザーとして思った率直な感想です
- WordPressの次なんていらない
- そもそも次なんて求めてもいない
- Newtというサービスの無意味さ
そのことを建前・ポジトーク無しで語ります。
NewtとはWordPressの次を担うサービスらしい…
冒頭でも書いたように豪語されてました。
私たちのミッションは 「Creating the Next WordPress（次のWordPressをつくる）」です。
その言葉の通り、私たちはWordPressを置き換えることのできる新たなプロダクトを作り出し、現在のWordPressのように世界中で広く利用されるものへと成長させたいと考えています。
恐らく、これはかなり難易度の高いミッションで、実現に至るまでにどれほどの時間と労力を要するのか、私達自身も分かっていません。少なくとも10年はかかるでしょうか。
うんうん、なるほど
恐らく世の中を変えたいという強い情熱を持った人たちと信じます。いや、むしろここまで豪語するなら絶対にそうであってほしいです。
なにしろ世界中で使われているWordPressを「いらない」と断言し、自分たちのCMSが世界を席巻すると信じているんですから…
理想はどれだけ高くても困らないですね
Newt開発者が提示しているWordPressの問題点
そしてWordPressの問題点について
Newt開発者は次のように考えられてるようです
- JavaScriptシフトについていけないこと
- ノーコードとヘッドレスCMSの台頭
- WordPress構築にPHP・MySQLが必要なこと
記事を読む限りではWordPressは使っている技術も古いし、イケてない技術ばっかりだよね、ということが延々と書かれていました。
私自身も少し同意することはあります
確かにサーバーサイドでPHP・MySQLを強要されるのは事実であり、プラグイン・テーマ開発者はPHP・MySQLを学んでいることが前提になってます。
私もWordPressプラグインの開発を行ったことがあり、WordPress特有の仕組み（データベース構成・アクションフック・アクションフィルター）に悩んだこともありました。
それをNewtが解決すると信じているみたいです。
※ 少なくとも本人たちは本気で思ってるはず
残念ながら技術はWordPressの歴史には勝てない
技術者・開発者はこう考えがちです
- いいものを作れば使ってもらえるはず
- 技術さえよければ勝手に広まっていく
- 技術こそすべて、技術 is ナンバーワン！
残念ながらそうではないんですね…
それがこの世界の非情さでもあります。
技術力の結晶のようなサービス・商品だったり、職人がこだわりぬいて作ったモノ・・・
それは世間から見向きもされないことが多々あります。
他より頭１つ抜き出ていてもです。
例えば異分野で考えてみる - ビットコインの例
ここでWordPress／Newtから少し脱線します。
CMSでない異分野で考えてみましょう。
分かりやすいのが仮想通貨・ビットコインの例です
※ 仮想通貨に興味がない人はごめんなさいm(__)m
ビットコインとは現在の仮想通貨のトップです
▼ ビットコインの歴史
- 2009年に初めて生まれた仮想通貨
- 2022年で13年の歴史を持つ古参
- 今まで何度も大暴落を経験してきた
仮想通貨・ブロックチェーンが生まれた2009年から今までトップを走り続けてます。2017年にも話題になったように、何度も大暴騰・バブル崩壊を繰り返してきました。
そしてご存知の人も多いはずですが、ビットコイン自体は技術的にはポンコツです。いやポンコツはさすがに言いすぎか(笑) 他の仮想通貨と比べてポンコツって意味です。
- 送金取引に1時間ほどかかる
- 送金手数料も1回数千円ほど
- 技術のアップデートも遅い
こんな技術に疎いビットコインですが、今までトップの座を譲り渡したことはありません。それどころか近年はますます勢いづいてます
ここで閑話休題
このように仮想通貨という「テクノロジー重視！」みたいな分野であっても、長年培ってきた歴史には勝てないんです。それはCMS分野でも同じです
WordPressは１つのブランドを確立している
そしてWordPressの強さは歴史のみではありません
もはや１つのブランドとして定着しています
例えばレンタルサーバーの場合…
ほぼどこでもWordPressインストール機能があります
▼ WPインストール機能がある代表的なサーバー
- エックスサーバー
- さくらサーバー
- ロリポップ
- Conoha WING
- mixhost・他いろいろ
これらレンタルサーバーはWordPress運営から頼まれてインストール機能を導入したわけではありません。利用者のニーズを考えて導入しただけです。
いまやAWSですらWordPressをサポートしている
あのAWSですらWordPressをサポートしてます。
※ AWS = Amazon Web Services
私はWebサービスなどを作る時にAWSを利用させてもらってますが、まさかAWSにもWPインストール機能があるとは思っていませんでした。
だってAWSは開発者向けのサービスだからです。
そこですらWordPressに対するニーズを理解し、WPインストール機能をサポートしています。それだけのブランド力があるのがWordPressという存在です。
一方のNewtの場合はどうか・・・
- 歴史については１年程度
- CMSとしては中途半端な立ち位置
- ブランド力はゼロであり皆無
別にNewtをけなす意図はないです
問題は「WordPressの次」と主張していること
本当に次を目指しているなら、歴史の時点で負けてます。
そして中途半端に技術を盲信し、WordPressがなぜ使われるのか・なぜ代替が出てこないのか思考することを放棄しています。
というかWordPressができて何年たってるの？って話です。2003年から20年もの歴史があります。もしWordPressに問題があるなら、とっくの昔に代替CMSが出現してオワコンになっていたでしょう
ユーザーはどこの国で生まれたサービスかは気にしない
そしてNewt紹介の記事の最後あたり
こんな数文がありました。
私はふとした時、自分が日常的に使っているWebサービスや開発のためのツール、プログラミング言語からライブラリに至るまで、そのほぼ全てが日本国外で作られたものであることに、悔しさに近い感情が込み上げてくることがあります。そして同時に、それをさも当然のことであるかのように受け止め、それらを一方的に使っているだけの自分の存在にも気づかされるのです。
世界には、英語圏以外の国で開発されていながらも世界中で広く利用されているWebサービスが沢山あります。しかし、日本発のサービスで世界中で使われているものはほとんどありません。何故でしょうか？確かな答えは分かりませんが、案外私達自身が「そういったサービスを日本から生み出すことはできない」と勝手に思い込んでしまっていただけなのかもしれません。
私たちNewtは、特別な経験やコネクションを持ったチームではありませんが、プロダクトを作ることに対するこだわりや情熱を持っています。そして、最高のプロダクトは言語や国境の壁を越えられると信じています。私達は最高のプロダクトを作ることで、この大きな目標を達成したいと思っています。
もはや苦笑しかできない…笑
技術は素晴らしいのかもしれないですが、どうも私情が多い気がします。ここを読んで「本当にユーザーのこと考えてるのかな？」と思ってしまいました。
CMSを選ぶユーザーは目的（ブログを作ったり、サイトを構築したり）があるわけで、そのCMSがどの国で作られたかなんて一切気にしません。
私もWordPressが必要だから使ってるだけです。
Newtが次世代WordPressを目指すのは迷惑
私が本当に危惧するのは次のことです
- メディアがNewtを次世代WordPressと持ち上げる
- いくらかの人が本気でそれを信じてしまう
- WordPressから乗り換える人が出てくる
- ブログ・サイト運営の労力増大／疲弊／後悔
もう一度はっきりと書きます。
NewtはWordPressの次ではない！！
Newt発明者たちは「技術的なカスタマイズがWPよりしやすい」を売りにしてますが、もし独自のサービスを作りたいならAWSなどを使えばいいだけです。
そして単純にブログ・サイトを運営したいだけならWordpress以外にも無料ブログなどいくらでも手があります。
メディアにはNewtを「WordPressの次」などと宣伝してほしくないです。WordPressというブランドにただ乗りしているに過ぎません。
そしてNewt開発者に少しでも善意が残っているなら・・・「WordPressの次」というパワーワードを使わず、「newt」というブランドだけで勝負すればいいと思います。
以上、私が 次世代WordPress（自称）に感じたことでした。
NewtはWordPressの次でも何でもありません。
The post 「WordPressの次」はいらないし求められてもいない理由【Newtの件】 first appeared on Fukuro Press.
]]>The post データベース接続確立エラーの原因はBackWPupかも【WordPress】 first appeared on Fukuro Press.
]]>
このエラーは本当に厄介ですね。
>> データベース接続確立エラー <<
原因は一口にこれとは断言できないです。
でも1つの可能性としてWPBackupかもしれません。
このBackWPupプラグインに限らず、
バックアッププラグインには要警戒です！
突然にデータベース接続確立エラーが起こった
これは私自身が体験した話ではありません。
とある方からご依頼を受けたときのことです。
その方はVPSを使ってWordPressを運営されていました。
サーバーの簡単インストールなどの機能も使わず、手動で必要なソフトなどをインストールしてWordPressを導入されたらしいです。
そしてあるとき・・・管理画面で操作を誤ってログインができなくなったとのこと。最悪なのはVPSサーバーを再起動してしまったことでした。
↓ その結果、DB接続確立エラーが発生
ヒントとしてこんなこと書いてありますね。
- ユーザー名とパスワードに間違ってないか?
- 正しいホスト名を入力できているか ?
- データベースサーバーは稼働しているのか?
そもそもWordPressでは記事タイトル本文・プラグイン設定・メタデータ……こういうの全部をMySQLデータベース上に保存しています。
つまりデータベースがやられたらアウトな訳ですね。
そこで原因を探ってみることにしました。
まずはwp-config.phpのDB接続情報が正しいか確認
まず初歩中の初歩の確認をしました。
wp-config.phpのデータベース設定の確認
↓ wp-config.phpのこの部分に注目！
/** WordPress のためのデータベース名 */
define( 'DB_NAME', 'db_name' );
/** MySQL データベースのユーザー名 */
define( 'DB_USER', 'user_name' );
/** MySQL データベースのパスワード */
define( 'DB_PASSWORD', 'password' );
/** MySQL のホスト名 */
define( 'DB_HOST', 'localhost' );このように設定されてるデータベース名・ユーザー名・パスワードが正しいか入念に確かめてください。どれか１つでも間違っているとDB接続確立エラーになります。
あとwp-config.phpは最重要ファイルなので編集前にバックアップを忘れずに。もし「wp-config.phpって何？どこにあるの？」というレベルなら、自力解決とかは試さないでください。
これは今回のケースでは問題なしでした。
そこでまた別の原因を探ることに…
原因は意外なことにBackWPupプラグインだった
そして原因がようやく判明
原因だったのはBackWPupというプラグイン
WordPress全体のバックアップが取れるプラグインです
- １つ１つのバックアップ容量が大きい
- 具体的には１つあたり2GBを超えていた
- それらがSSDディスク容量を圧迫
- MySQLサーバーが起動できなかった模様
↓ BackWPupが作るバックアップの例
１つのバックアップが3.36GBとか (-_-;)
これがSSD容量が50GBしかない所にゴロゴロと作られていました。そして次第にSSD容量を圧迫していき、最終的にMySQLが起動できないレベルになったようです。
こういったバックアッププラグインは保険にもなるんですが、容量が様々なトラブルを引き起こすこともあります。（実際そういう例が多い）
そこで古いバックアップをコマンド経由で5～6個ほど消してみました。そうするとSSD容量に10GBほどの空きが作れました
SSD容量を確保したあとにMySQLを再起動させた
そしてVPSからSSH接続してMySQL再起動です。
↓ 一旦MySQLを停止させる
sudo service mysql stop↓ MySQLを起動させる
sudo service mysql startMySQLが正常に起動！
ブログも管理画面も元通りにアクセスできました。
ただしこの操作は普通のレンタルサーバーではできません。VPSは自由度が高いのでMySQLサーバーの再起動もできるという話です。
今回のケースでは迂闊にVPSサーバーを終了してしまったため、MySQLサーバーが落ちてしまい、そこにSSD容量不足が追い打ちをかけた形ですね。
これはレアケースだけど可能性としてありえます。
他にもあるWordPressのトラブル事例
他にもWordPressトラブル関連でこんな記事も書いてます
↓ PHPバージョンアップでWordPresエラーの対処法
↓ httpsにならない・鍵マークが出ない…５つの対処法
↓ 管理画面にリダイレクトループで入れない時の対処法
もしお困りな時はこういった記事が役に立つかも
ただし自力解決は一定の技術がある人向けです。
ココナラでWPトラブル解決相談を実施中
そして私自身もトラブル解決相談を行っています。
↓ ココナラで次のようなサービスを運営中
もしお困りならご相談ください。
以上、DB接続確立エラーとBackWPupの話でした。
The post データベース接続確立エラーの原因はBackWPupかも【WordPress】 first appeared on Fukuro Press.
]]>