最近すっかりWordPressから離れていたんですが、良くも悪くも情報量が豊富ですね。 WordPressは10年以上前（WordPress MEの頃）からいじってますが、どんどん複雑化してきて最近はhome.phpやら […]
IT実践
WP-PageNaviで2ページ目以降が404エラー【解決】
表示されない
IT実践
Google AdSenseで広告が表示されたりされなかったり
ページ内に複数の広告がある場合には、広告コードの1行目にある<script>～</script>は1回で良いそうです。 ページ上に複数の広告コードがある場合、各広告ユニットに <script […]
ICT実践記事
- Let’s EncryptでSSL証明書の発行・更新・トラブル
Let’s Encryptから「証明書の期間があと20日で切れますよ」という英文メールが届きました。 cronで定期的にrenewをかけて自動更新しているのですが、何か設定がおかしいのかなと思い、複数のssl証明書を管理しているサーバにログインをしてみました。 原因が良くわからなかったので、該当ドメインを登録し直すために現在の更新情報ファイルを削除しました。 rm /usr/local/etc/letsencrypt/renewal/DOMAIN.conf 上記が正しいコマンドですが、深夜のせいか使い慣れないマウスのせいか、 rm /usr/local/etc/letsencrypt/renewal ん？ディレクトリだから消せないよと英文メッセージ。 confなのにディレクトリなのか。と深く考えもせずRオプション追加。 rm -R /usr/local/etc/letsencrypt/renewal （￣▽￣||| … Enter押して1秒後に気付きました。 renewalディレクトリごと消してしまった…。 全てのドメインのssl更新ファイルが消失しました。 Unix系のOSにはWindowsのようなゴミ箱はありません。 復旧ツールもあるみたいですが、稼働中サーバにいきなり入れてみるのも気が引けたので、潔くあきらめて手動で復旧させる事にしました。 私の環境では/usr/local/etc/letsencryptですが、/etc/letsencryptの場合も多いようですので、読み替えてください。 またcertbotコマンドはcertbot-autoになっているようですので、そのあたりも読み替えてください。 Let’s Encryptの登録をやり直す ドメインごとの情報ファイルを削除 以下を消します。 /usr/local/etc/letsencrypt/live/DOMAIN_DIR /usr/local/etc/letsencrypt/renewal/DOMAIN.conf /usr/local/etc/letsencrypt/archive/DOMAIN_DIR ここでも注意。 ※真似るな危険！ ↓↓↓ rm -r /usr/local/etc/letsencrypt/archive DOMAIN_DIR として、今度はarchiveディレクトリまで消 […]
- WordPressの新エディタGutenbergは待ち望んでいたUI
WordPress 5.0から採用された新エディタGutenbergですが、WP 5.2を導入して本格的に触ってみました。 ネット上の意見は賛否両論のようです。 （否定派が圧倒的に目につきますが、声を上げるのは決まって反対派が多数ですので…。） 追記：Classic Editorプラグインのダウンロード数（5,000,000以上）と評価を見る限り、以前のエディタの人気が伺えます。 NetCommonsのようなUI NetCommonsというCMSをご存知でしょうか。 今から10年以上前になるのですが、各学校で簡単にWebサイトを管理できるように、NetCommonsを使ったシステム提案を教育委員会に行った覚えがあります。（スルーされたと思っていたら翌年には似たようなシステムが導入されていましたが…） WordPressは「文章を書く」のに対して、NetCommonsは「ブロックを配置」するのに特化していたため、HTML知識が無い方でもコンテンツの書き換えや追加時に、それなりの見た目が維持できるという利点がありました。 複数の学校の先生がそれぞれの担当枠を書き換えたり、毎年担当者が変わるることを考えると、WordPressでは書く人によって、見た目に大きな差が出てしまうのです。 ページ更新・追加・削除のたびに数千円～数万円をWeb制作会社に支払って更新依頼するという形態は、現在は稀なケースだと思います。 WordPress等のCMSが主流になり、クライアント自身が好きなタイミングでコンテンツの更新を行うように移り変わりました。 ですが、制作時にどんなに頑張ってCSSを用意しておいても、更新する人が適切なHTMLタグやショートコードを使わなければ、素っ気ないページに仕上がってしまいます。 素っ気なさすぎるからと、ホームページビルダーで作ってHTMLを貼り付けたり、WordやExcelから貼り付けたり、スペースで文字を揃えたりと、なんだか悲惨なページになってしまったりもします。 更新者のスキルに左右されにくいブロックエディタ ブロックエディタの強みは、見栄えの良いページが直感的に作れるので、HTML・CSSを何も知らない人が更新やページの追加をしていっても、あまり酷い結果にはなりにくいという部分です。 私は制作時に、クライアントのWeb担当者スキルに合わせて管理 […]
- PukiWiki 1.5.2対応XMLサイトマッププラグイン
平成も終わろうとしているこの時代に相変わらずPukiWikiをカスタマイズしています。 Google Search Consoleに登録するためにサイトマップを出力したかったのですが、過去に配布されていたプラグインはサイトが閉鎖されてしまっていて、インターネットアーカイブからもダウンロードすることができませんでした。 しばらく探したところ、上記のサイトマッププラグインとは別のものと思われますが、こちらのサイトで現在も配布されていました。 非常にシンプルながらも、プライオリティ設定もしたければできるというすばらしさ。 試しにそのままPukiWiki 1.5.2のプラグインディレクトリに入れてみたところエラーもなく動作しました。 ただどういうわけか私の環境ではトップページがリストに載りませんでしたので一部手を加えさせていただきました。 PukiWiki 1.5.2用サイトマップ出力プラグインのダウンロード 配布元サイトからダウンロードして下記の修正を加えるか、修正済みファイルをダウンロードしてください。 必須sitemap.inc.php（PukiWiki用サイトマップ出力プラグイン） Download 配布元 修正済み（当サイト） トップページ（FrontPage）をpriority1.0として出力する修正箇所（当サイトからダウンロードされた方は修正済みです） // <url> $urls = ”; // sio $front_page_date = gmdate(‘Y-m-d\TH:i:s’, get_filetime(‘FrontPage’) + ZONETIME) . ‘+00:00’; $urls .= ” <url>\n”; $urls .= ” <loc>$script</loc>\n”; $urls .= ” <lastmod>$front_page_date</lastmod>\n”; $urls .= ” <priority>1.0</priority>\n”; $urls .= ” </url>\n”; $count = PLUGIN_SITEMAP_MAXSHOW; foreach ($pages as $page=>$time) […]
- Windows 10 バージョン1903（19H1）はいい感じ
Windows 10 May 2019 Update（バージョン 1903、19H1）がリリースされて1ヶ月程が経ちました。 Windowsの大型アップデートでは毎回トラブルに見舞われるのですが、今回は個人的には良いOSだと思っています。 Windows 10 April 2018(1803)の時には不具合が多く、ディスクドライブを疑いSSDを買い替えてしまいました。 今回は、数台の予備パソコンで試してみて特に不具合が無かったので、先日メインマシンも手動で導入しました。 以下はあくまでも個人的な感想です。 Windows Updateが軽くなった印象です。 全体的な動作がOSインストール直後のパソコンといった感じでキビキビしています。 Windows 10 1903(19H1)へのアップデート方法 Windows 10 May 2019 Update（バージョン 1903、19H1）は、まだ自動配信はされていないようです。 2019年6月上旬からWindows Updateの手動確認で更新ができるようになりましたが、Microsoft Windows 10のダウンロードからもダウンロードできます。 Windows 10 1903は不具合も多数ある模様 以下、Impress Watchさんの情報です。 調査中の問題 ディスプレイの明るさを調整できない “Dolby Atmos”ヘッドフォンおよびホームシアターでオーディオが機能しない ユーザープロファイルディレクトリに表示されるフォルダーとドキュメントが重複する 緩和策のある問題 外付けUSBデバイスまたはメモリカードを接続してアップデートしようとするとエラーが発生する Bluetoothデバイスを検出もしくは接続できない 夜間モードが適用されない 「Intel Display Audio」がバッテリーを過剰に消費する 「カメラ」アプリが起動できない Wi-Fi接続が断続的に失われる AMD RAIDドライバーの非互換性問題 D3Dアプリケーションおよびゲームが回転ディスプレイで全画面モードに入らない 古いバージョンの「BattlEye」アンチチートソフトとの非互換性問題 Windows 10 1903の目玉「Sandbox」 目玉と言われているサンドボックスですが、以前Hyper-Vを試した際にホストの設定をあれこ […]
- 偽サイトに嵌って防衛手段を検証する
公開しているメールアドレスは、最近トレンドなフィッシングメールをピックアップで紹介したように、フィッシングメールが毎日山ほど届きます。せっかくなので訪問してみました。 フィッシングサイトに嵌ってみました 最近のブラウザはデフォルト設定で注意喚起してくれます。 Chromeの場合 Firefoxの場合 Firefoxのほうがキッパリと言い切っていてかっこいいですね。 どのブラウザも、うっかり誤クリックで進んでしまわないように「無視して進む」というボタンが無いインターフェイスになってますが、頑張って先に進んでみました。 仮想PC・ブラウザをプライベートモード・LAN切り離し・IPアドレス変更等を行ったうえでの検証です。アクセスするだけで様々な情報を抜かれる恐れがありますので、安易に先に進むようなことはしないようにしてください。 APPLEっぽいサイトが表示されました。 一見APPLE公式のように見えますが、中央の入力フォーム以外はリンクすらされていない張りぼてです。 ですが疑いの目を持って見ない限り、偽サイトだということに気づかないと思います。 フィッシングサイトの見抜き方 騙されないためにはアドレスバーに表示されているURLをよく見てください。まずこの習慣をつけましょう。 見るのは最初に現れるスラッシュ「/」よりも左側です。それよりも後（右側）は一切気にしないで大丈夫です。 http://cert-protection-account-appleid-apple.com ブラウザによっては cert-protection-account-appleid-apple.com とhttp://（またはhttps://）が省略されて表示されます。 以下のような場合にはさらに注意が必要です。 apple.example.com/rmd_nid_vcss… google.example.com/rmd_nid_vcss… ドメイン名「example.com」の前にドット「.」が入っている場合、それより左側はドメインの保有者が自由に好きな文字を設定できるサブドメインと呼ばれます。 一番最初に知っている名前が入っているからといって絶対に信用してはいけません。 itunes.apple.com これはitunesがサブドメインですが、その右側を見るとドメイン名がapple. […]
- ある日を境にWEBサイトへアクセスできなくなった
数か月くらい前に取得して製作途中だったサイトが、いつからかアクセスできなくなっていました。 アクセスできない問題の切り分け サーバーの確認 IPアドレスを指定したsshやsftpなどではサーバーへアクセスできました。 Webサーバー（Nginx）の確認 正常に動作していた時から設定を変更していませんが、念のため見直しました。問題なさそうです。 DNSの動作確認 $ host my.domain Host my.domain not found: 3(NXDOMAIN) DNSの設定に問題がありそうですが、少し前までは正常に引けていて、それ以降設定は変更していません。 $ ping my.domain PING my.domain.work(xxx.xxx.xxx.xxx): 56 data bytes 正引きできないのに、設定した覚えがないホストに向かっています。（xxx.xxx.xxx.xxxは心当たりがないIPアドレス） そもそもドメインの最後にworkがついているのは何故…。 resolv.confを書き換えてみたり、hostsに書き込んでみたり、別のDNSサーバーに設定を移してみたり、半日格闘しましたが解決せず。 レジストラ（Value Domain）に問い合わせ Value Domainの問い合わせフォームにチャットでの問い合わせがあったので、初めてクリックしてみました。 運が良かったのだと思いますが、待ち時間6秒！ 非常に手際よくドメインの状態を調べてくれて、2分後には的確な回答をいただきました。 (06:55:30) *** MYNAME joined the chat *** (06:55:30) MYNAME: ドメインが参照できません（DNS） (06:55:34) ※自動メッセージ: お問い合わせありがとうございます。只今込み合っております。お急ぎの場合はフォームよりお問い合わせいただきますようお願い申しあげます。 (06:55:36) *** Chat Support joined the chat *** (06:55:39) Chat Support: お問合せありがとうございます。担当の 【***】 と申します。 どうぞ、よろしくお願いいたします。 (06:55:44) MYNAME: よろしくお願いいたします。 (06:55:4 […]
- 無観客で行われる小学校の運動会を複数カメラでライブ配信したい
無観客で開催されることになってしまった小学校の運動会。一所懸命な姿を家族に見てもらうために複数カメラを使ってライブ配信できないか、多くの制約の中で試行錯誤しています。
- XMLサイトマップをGoogle Search Consoleに準拠
インデックス登録されましたが、サイトマップに送信していません Google Search Consoleのカバレッジで緑色の有効（インデックスに登録されている）になっているものの、「インデックス登録されましたが、サイトマップに送信していません」という詳細情報が気になりました。 クリックしてみると「例」としてURL一覧が表示されます。 そのURLをさらにクリックすると、UTF-8でエンコードされたURLが表示されます。 送信しているXMLサイトマップもUTF-8でエンコードをしていますし、URLの正規化も済んでいるのになぜ？ じっくりと見比べてみると、XMLサイトマップのURLはスラッシュが「%2F」にパーセントエンコーディングされているのに対して、Googleでは「/」のままです。 サイトマップを出力しているphpソースを見てみると、PATH_INFOをrawurlencodeでエンコードしています。 rawurlencodeはRFC3986にもとづいて「-_.~」とアルファベット以外をすべてエンコードするようですので妥当なはずです。 Google独自仕様？と思ったのですが、RFC3986の3.4章に「スラッシュ (“/”) と疑問符 (“?”) の文字はパーセントエンコーディングする事を避けるほうがユーザビリティのためにはよい。」という記述がありました。 スラッシュはパーセントエンコードしないように修正 GoogleもRFCもスラッシュはパーセントエンコードしないと提唱しているのであれば、これに合わせるべきだと思い以下のように修正しました。 $r_page = rawurlencode($page); $r_page = str_replace(‘%2F’, ‘/’, $r_page); 修正後、XMLサイトマップの出力とGoogle Search ConsoleのURLを比較するとマッチしていましたので、これで解決です。
- WordPressテーマXeory Extensionのナビメニューを修整する
WordPressテーマXeory Extensionの「グローバルナビ」と「プライマリーナビ」メニューを表示順や見出しをカスタマイズしてUI的に使いやすくする方法。
- 「Easy Table of Contents」で長い見出しが改行されても行頭を揃えるコピペ用CSS
WordPressに目次を自動挿入するプラグイン「Easy Table of Contents」をカスタマイズして表示を最適化したCSSを配布。
- PukiWikiのURLをNginxで正規化【index.php非表示】
10年以上ぶりにPukiWikiをいじっているんですが、昔の情報は豊富にありますが最近の情報が乏しいですね。 PukiWikiの全盛期は、Nginxが誕生したばかりでしたので仕方ないのかもしれませんが。 PukiWikiのindex.php無しでURLを統一する URLの正規化としてまず、 http://example.com/ http://www.example.com/ https://www.example.com/ これらをhttps://example.comに301リダイレクトしました。 これについては各所に載っているようにserverディレクティブを追加して、return 301～といった感じです。（ここでは詳細は割愛します） これで完璧！と思いつつGoogle Search Consoleを眺めているとindex.php有りと無しが…。 pukiwiki.ini.phpの設定でindex.phpを表示しないという項目があります。 // Shorten $script: Cut its file name (default: not cut) //$script_directory_index = ‘index.php’; コメントアウトを外して試してみましたが、何かが違う。 確かに表示はされなくなりました。 index.php有りの膨大なURLがすでにGoogleにインデックスされているので、index.php有りで404エラーになると困るのですが、結果はindex.phpを入れたURLでもちゃんとページが表示されました。 しかしindex.phpが表示されたままの状態。ステータスコードは200。index.php有りと無しの両方のページが存在した状態です。 ということでNginxの設定を変更しました。 server { if ($request_uri ~* “^(.*/)index\.php(.*)$”) { return 301 $1$2; } } 上記のようにdefault serverディレクティブに書き加えて、 nginx -s reload で完了です。 PukiWikiネタってまだ需要あるんでしょうか。 今回PukiWiki 1.5.2（utf8）をベースに以下のようなカスタマイズをしたのですが、要望があれば時間を見つけて記事 […]
- 常時SSL化（https）後に旧サイトのアクセスが減らない
最近SSL化したサイトで旧サイト（http）へのアクセスが一向に減らないという現象が発生しました。 httpへのアクセスを301リダイレクトでhttpsへ遷移。 Google Search Consoleのプロパティにhttpsサイトを追加。旧サイトも削除せずに監視。 これで安心してしまっていたのですが、1ヶ月経っても、Google Search Consoleで旧サイト（http）の表示回数が減らない。（一時的に減少しましたが、盛り返してきている）平均掲載順位に至っては上昇している。 どうもおかしいと思い調べたところ、もともとHTTPヘッダとしてcanonical属性を出力していたのですが、スキンをカスタマイズした際に書き出されなくなってしまっていたようです。 これはChromeのデベロッパーツールを使って以下のように確認しました。 HTTPレスポンスヘッダ・リクエストヘッダの確認方法 Chromeを開き[F12]を押してデベロッパーツールを開く。 Networkタブを選択しておく。 HTTPヘッダを確認したいページを開く。 Nameの一番上（AdSense等がある場合は2番目以降になっている場合があります）にある該当ページをクリックする。 Headersタブをクリックするとレスポンスヘッダやリクエストヘッダが確認できます。 全てのページで<link rel=”canonical” href=”ページURL”>を<head>～</head>内に出力するように修正して完了です。 ※ページURLには各ページのURLを正確に書きます。
- 【Zoom代替ツール無料で公開中】オープンソースのJitsiは学校でも会社でも使える
Zoomに代わるオンライン会議ツールを無料で公開しています。 登録不要でブラウザからもすぐに利用できますので検証としてご活用ください。
- WordPressリダイレクトプラグインで日本語を扱えるように修正
WordPressに301リダイレクトを設定するSimple 301 Redirectsというプラグインを導入しました。 PukiWikiで運用していた旧コンテンツをWordPressに引き継いだ後に、Google Search Consoleのクロールエラー対策＆SEO対策です。 PukiWikiからのデータ移行については下記の記事をご覧ください。 https://www.ii-sys.jp/notes/716 WordPress用プラグイン Simple 301 Redirects 必須WordPress用プラグイン Simple 301 Redirects Download WordPress公式サイト Simple 301 Redirectsというプラグインですが、phpファイル1つだけで構成されていて、管理画面もURLを設定するだけという名前の通り非常にシンプルです。 Google Search Consoleでクロールエラーが出ているURLをコピーしてRequest欄に貼り付け、リダイレクト先のURLをDestination欄に貼り付けて「変更を保存」ボタンをクリック。 しかし挙動を確認するまでもなく、Request欄に貼り付けたはずのURLが一部消えてしまいます。 どうやらURLエンコードされている部分が消失してしまっているようです。 ソースコードを追いかけてみると、保存する前にWordPressの関数sanitize_text_fieldが呼ばれていました。 WordPress関数リファレンスを見ると、 オクテット（’%’ に続く 2 桁の 16 進数）を除去します。 と明記されています。 これは日本語を含むURLの場合は致命的で、それ以外にも「/」を「%2F」にエンコードするような仕様でも困ったことになります。 プラグイン「Simple 301 Redirects」のカスタマイズ セキュリティ的なリスクを承知の上で、wp-simple-301-redirects.phpの188行目と189行目にあるsanitize_text_field関数を削除しました。 wp-simple-301-redirects.php 変更前 for($i = 0; $i < sizeof($data[‘request’]); ++$i) { $request = […]
- Apache 2.4でバーチャルホストを実際に運用する際の参考記事
Apache 2.4でバーチャルホスト設定をすると403 Forbinddedが表示される原因はディレクティブを見直してみましょう。実際に運用していくうえでディレクティブに毎回記述しないで良いための設定方法。