WordPress用の注釈プラグインWP-Footnotes、最終アップデートが2010年8月と更新が止まっていますが、便利なプラグインです。
FootNotes に日本語を使いたい場合、管理画面で文字化けを起こしてしまいますが、footnotes.phpの以下を修正すればOKです。
217行目と261行目
htmlentities → htmlspecialchars
ICT実践記事
- オンライン学習を早期実現しなければコロナ世代の学力低下は不可避
新型コロナウイルスで休校中の学生を持つ親として学力の低下を懸念。 オンライン学習の早期実現に向けて、素案やZoomに代わるオンラインミーティングツールを独自の視点で考えます。
- 無観客で行われる小学校の運動会を複数カメラでライブ配信したい
無観客で開催されることになってしまった小学校の運動会。一所懸命な姿を家族に見てもらうために複数カメラを使ってライブ配信できないか、多くの制約の中で試行錯誤しています。
- ConoHa VPSリニューアル後のプランに移行する方法
ConoHa VPSが2020年1月29日からSSD容量と料金が改訂されましたが、放っておいても既存のサーバーには適用されません。 適用させるには以下の手順が必要になります。 旧サーバー停止 ※自動バックアップを設定している場合には不要 旧サーバーのイメージ保存 ※自動バックアップを設定している場合には不要 新サーバー追加（保存イメージから） 旧サーバー削除 これで新契約の内容となります。 料金が重複してしまうのではと思い、問い合わせをしてみたところ以下のような回答をいただきました。 ConoHaのサービスについては1時間毎の課金となりますので 料金についてはご任意のタイミングで削除し1時間後に新たに サーバーを追加することで料金の重複は発生しないものとなります。 1時間毎の課金ですが、上限を超えると固定（1か月料金）となるため、その場合は「旧サーバーの1か月分＋新サーバーの時間課金」になると思われます。 新サーバー追加後すぐに旧サーバーを削除すれば、多くても5日分増える程度ですね。 契約自体は上記で移行されますが、SSD容量が50G → 100Gになったとしても、パーティション操作等をしなければ意味がありません。 また、IPアドレスが変更になるためネームサーバーのIPアドレス変更も必要になります。 FreeBSDのパーティション拡張については下記の記事をご参照ください。 https://www.ii-sys.jp/notes/2211
- Google AdSenseで広告が表示されたりされなかったり
ページ内に複数の広告がある場合には、広告コードの1行目にある<script>～</script>は1回で良いそうです。 ページ上に複数の広告コードがある場合、各広告ユニットに <script async src=”//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js”></script> を含める必要がありますか？ 非同期タグでしたので何も考えずに最後の方（</body>直前）に書いたのですが、どうやらそれが原因で広告が表示されたりされなかったりしていました。 プラグイン等の外部ファイルにAdSense表示部分が書かれている場合には、非同期での読み込みが間に合って表示されるようで、インラインで書かれている場合だけが不安定でした。 Nginx（Webサーバ）のFastCGI（キャッシュ）も影響していたようで、気が付くまでに時間がかかってしまいました。 <head>～</head>の間に記述して安定しました。 <head> ・ ・ ・ <script src=”https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js”></script> <script async src=”//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js”></script> </head> ・ ・ ・ <ins class=”adsbygoogle” data-ad-client=”ca-pub-XXXXXXXXXXXXXXXX” data-ad-slot=”XXXXXXXXXX”></ins> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script>
- Googleが独裁者になっていくのは寂しい
世界中でGoogleを知らない人はいないといっても過言ではないほどの巨人。 インターネット黎明期の20年程前は利益を考えないベンチャーとして不気味な魅力がありましたが、最近は大きくなりすぎてしまった弊害が目立ちます…。資本主義の限界なんでしょうか。 Googleの主要サービス 検索エンジン 翻訳サービス 地図サービス メールサービス 広告サービス カレンダー YouTube Google Play Googleに踊らされている人たち 世界地図から住宅地図の尺度まで自在に表示できるGoogleMap、それも無料で使えるとあって多くのWebサイトやシステムにも導入されてきました。 私も例外ではなく、過去に制作してきたコンテンツの多くにGoogleMapを利用させてもらってきました。 ある時規約が変更され、登録しないと表示されない仕様＆表示上限が設けられ、さらに規約変更が重ねられて、今では1,000回表示で7ドルに。 今やネット上の情報を検索するにはGoogleに登録されていなければ、砂漠のド真ん中にお店を開店したようなものです。 検索エンジン大手もほとんどが独自システムの開発をやめてしまい、Googleのシステムに頼っている一強の前で、検索アルゴリズムが変更されるたびに為すすべもなく、阿鼻叫喚の巷と化しています。 無料提供されてきた翻訳APIが有料化になったこともありました。 一部の国ではGmailの有料化。 もうある意味「神」ですね。生かされているので何も言えない。 検索エンジンの初期から一貫して「競合を圧倒したサービスを無料提供して、ライバルを撤退もしくは吸収したうえで市場を独占して、十分なアドバンテージができたところで有料化」という完璧なビジネスモデル。 なんかgifやmp3と似てるんですけどね。 世界中を敵にまわして事実上敗北してしまったUNISYS社らとの大きな違いは、企業として巨大化するまでじっくり待ったのと、エンドユーザからは徴収しないという方針でしょうか。 その気になれば規約やアルコリズムをちょいちょいと変更して、自社に都合の悪い情報を抹消する事なんて簡単なわけですし。 スマホは現在Apple（iPhone）が対抗していますが、勢いがなくなってしまったら次はAndroidですよね。 Androidに乗っかっている日本企業、大丈夫でしょうか。 Gma […]
- Photoshopなんていらない！フォトショップを見据えた無料ペイントソフト
習得したスキルがAdobe Photoshopでも生かせそうな無料ペイントツールを、実際に使った独自の感想です。【小学校のパソコン講座にも導入しました】
- WP-PageNaviで2ページ目以降が404エラー【解決】
最近すっかりWordPressから離れていたんですが、良くも悪くも情報量が豊富ですね。 WordPressは10年以上前（WordPress MEの頃）からいじってますが、どんどん複雑化してきて最近はhome.phpやらfront-page.phpやらindex.phpやらと、テンプレート構造を理解するのさえ大変です。 時間があったので何年か前に構築したサイトを手直ししていたところ、トップページのページネーションが効かなくなってしまいました。 100個近いカスタムフィールド・300超えのカテゴリ・function長すぎなコンテンツで、どのタイミングで表示されなくなったのか不明なまま、ネット上の情報を頼りにあれこれ試して半日が過ぎ、ようやく解決しました。 固定ページ用WP-PageNavi対策コード function.php function pagenavi_home($wp_query) { if (!is_admin() && $wp_query->is_main_query() && $wp_query->is_home()) { $wp_query->set(‘cat’, 5); $wp_query->set(‘post_type’, ‘iisys’); $wp_query->set(‘posts_per_page’, 12); } } add_action(‘pre_get_posts’, ‘pagenavi_home’); 3行目のcatはカテゴリーID5を指しています。不要であれば行ごと削除。 4行目のpost_typeはカスタム投稿タイプを指定。iisysは一例で、通常の投稿であればpostになります。 両方を指定したい場合には配列にします。 $wp_query->set(‘post_type’, array(‘post’, ‘iisys’)); 5行目のposts_per_pageは表示件数。記事数よりも多い数にするとページネーションは表示されません。 上記を書いたうえで、該当テンプレート（私の場合はindex.php）のquery_posts等を消してください。 以下は私の環境では効果ありませんでした。 管理画面の表示設定にある「1ページに表示する最大投稿数」を1件にする pa […]
- 【Google公認】reCAPTCHA v3のバッジ（ロゴ）をコピペで簡単に非表示
WordPressのContact Form 7に対応しているreCAPTCHAがv3になってから、バッジ（ロゴ）が邪魔な場所に表示されてしまうようになりました。 これはContact Form 7の問題ではなく、Googleが出力しています。 Googleにしてみれば謙虚に右下を選んだのかもしれませんが、右下は多くのサイトで「トップに戻る」アイコンが表示される大事な場所です。 （もっともGoogleがそれを知らないはずもないので、注目させたかったのでしょうか。） スタイルシートのposition: absolute; をJavaScriptで追加すれば好きな位置に移動できますが、親要素を変えられないのであまり実用的ではありません。 JavaScriptでgrecaptcha-badgeクラスをappendChildしてみたりしましたが、トークンの発行がうまくいかなくなったり不安定でしたので断念しました。 ネットで検索すると、海外でも多くの議論がされていました。 display: hidden; で非表示にしてしまうとスパム防止が効かなくなるそうです。 reCAPTCHA v3のバッジをGoogle公認の方法で非表示にする よく探せばGoogleのFAQにありました。 以下の表示をすればバッジを非表示にしても構わない This site is protected by reCAPTCHA and the Google <a href=”https://policies.google.com/privacy”>Privacy Policy</a> and <a href=”https://policies.google.com/terms”>Terms of Service</a> apply. コンタクトフォームを表示させるページごとに入れるのも面倒ですし、のちのち別のページにフォームを追加することになった時にはきっと忘れてしまっているので、コンタクトフォームの送信ボタン下に1行で書き込みました。 <p class=”recaptcha_policy”>This site is protected by reCAPTCHA and the Google<a href=”https://policie […]
- 緊急でリニューアルが必須なWebサイト
Webサイトが「スマホに対応していない」「SSLに対応していない」「Flashなどの古い技術を使用している」に該当していたら至急リニューアルを検討してください。
- WordPressのTheme（テーマ）選びは大切
紺屋の白袴とでもいいましょうか、いろいろと問題の多いOneToneというWordPressテーマを当コンテンツでは使用しています。 一般的なサイトでの使用はおすすめしません。 私がOneToneを選んだ主な理由 このテーマを使う以前は、ホームページ全面にFlashを多用したコンテンツとなっていて、早急な改善の必要性に迫られていた。 海外のWordPressテーマサイトで上位にランキングされていた。 OneToneのインパクトが強く一目惚れしてしまった。 SEOで検索結果上位を狙う気はあまりなかった。 コンテンツ移行に（サーバー移行も含めて）1時間程度しか掛けたくなかった。 また自社サイトでしかできない、お客様には提案できないような（爆弾を抱えた）テーマを試してみたかったという部分も大きいです。 悪い点 独自に作りこまれているためカスタマイズがしにくい。 プラグインも必要となり、ページ読み込み速度が遅い。 ランディングページ向きに設計されていて、WordPressのページという概念がほとんどない。 タグが微妙（h2タグがフッタータイトル等）でSEOに弱い。 英文フォント仕様なので、スタイルシートの変更が結構必要。 トップ動画等に一部不具合あり。 良い点 見た目のカッコよさ。 基本的に1カラムのレスポンシブなので、PCとスマホで同じイメージを提供できる。 jQuery盛りだくさんで、昔ホームページビルダーで「アニメーションgifで画像が動く」「音楽が流れる」というコンテンツを好んで作られていた方には受けが良いかもしれません。 時代に逆行している感は否めませんが、もうしばらくOneToneを少しずつカスタマイズして使ってみようと思います。 まずはフッター周りですね。 「関連サービス」 「リリース」 「障害情報」 で検索エンジンに働きかけても意味ないですし。
- PukiWikiをWordPressに移行する方法に困って半手動で実施
Windows XP関連のFAQを10年以上前にPukiWikiで公開していたのですが、最近は限られたアクセス数となっていたため、Webサイト全体を常時SSL化した際にバッサリと切り捨ててしまいました。 ですが、Google Search Consoleのクロールエラーが気になり、整備をした手順です。 プラグインで簡単にPukiWiki→WordPressにできないかと探しましたが、現行バージョンのWordPressで動作するものを見つけられませんでした。 コンテンツも100程度とそんなに多くなかったので、それぞれのページを手動で変換できればいいやと思い、PukiWiki記法をHTMLに変換してくれそうなツールを探したのですがこれも見つからず。 考えてみれば、PukiWikiの該当ページをプラウザで表示させてソースをコピーすれば良い訳なので普通は利用しないですよね。 ですが私の場合すでにPukiWiki環境が無く、そのためだけに環境を構築するのも非常に面倒でしたので…。 （WebサーバーをNginxに移行したのでさらに億劫になりました。Apache環境が手近にある方はPukiWikiを動かしたほうが早いかもしれません） PukiWiki記法をなんとかして別の表記に PukiWiki表記からMarkdown表記に変換してくれるサービスをなんとか見つけることができました。 非常に精度の良い素晴らしいツールで完璧に変換してくれます。 左側にPukiWiki記法のソースコードを貼りつければ、右側にMarkdown記法に変換されたものがリアルタイムで表示されます。 ここで一つ問題が発生。 Markdownには<dl> <dd> <dt>といったdlリストの記法が存在しません。 幸い上記の変換サービスでは行の先頭にdt ddと残してくれます。 これを使ってテキストエディタ（秀丸）で全置換を行いました。 検索：dt (.+)\ndd (.+)\n 置換：<dl><dt>\1</dt><dd>\2</dd></dl>\n ※正規表現です これでMarkdown記法＋HTMLタグになりました。 MarkdownをHTMLに変換 MarkdownをHTMLに変換するサービス […]
- Apache 2.4でバーチャルホストを実際に運用する際の参考記事
Apache 2.4でバーチャルホスト設定をすると403 Forbinddedが表示される原因はディレクティブを見直してみましょう。実際に運用していくうえでディレクティブに毎回記述しないで良いための設定方法。
- 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の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）をベースに以下のようなカスタマイズをしたのですが、要望があれば時間を見つけて記事 […]
- サーバーのバックアップで過去18年間に遭遇した問題点
サーバーを運用してきた18年間に遭遇したバックアップ・リストアの具体的な問題と改善策をまとめてあります。