ベースシステム
- Nginx
- MySQL
- WordPress
主な制作項目
- サーバー設置・SSL証明書設定
- CMS設置設定
- コンテンツ制作
- 管理画面のUIカスタマイズ
- 予約システム組み込み
- クレジットカード決済組み込み
- 簡易SEO
自社・自宅サーバーをVPSに移行するための有力候補3サービス
highlight.jsに「強調表示」を追加する拡張CSS
小中学校のZoom授業を「安全」「簡単」にできるQRコードの作り方と予定表フォーマット公開
Windows 10 バージョン1903(19H1)はいい感じ
フレッツ光を新規契約する人はプロバイダ申請に注意
小中学校「1人1台タブレット」いよいよ導入【豊後高田市】
「Easy Table of Contents」で長い見出しが改行されても行頭を揃えるコピペ用CSS
PukiWikiをWordPressに移行する方法に困って半手動で実施
人柱:Windows 10 v1803(RS4)更新プログラムKB4100403 (17134.81)
WordPressの引越しプラグイン『Duplicator』の正しい使い方
東芝dynabookはWindowsのクリーンインストールに対応していない
光ネクストへ切り替わったのでルータ新調で下り320Mbps
Apache 2.4でバーチャルホスト設定をすると403 Forbinddedが表示される原因はディレクティブを見直してみましょう。実際に運用していくうえでディレクティブに毎回記述しないで良いための設定方法。
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担当者スキルに合わせて管理 […]
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に変換するサービス […]
小中学校のiPadやChromebookでバッテリー持ちが悪い端末をモバイルバッテリーを使って延命させる、GIGAスクールサポーターの実体験。
出典:経済産業省 商務・サービスグループ 商取引監督課 ペイメントアプリケーションの改ざんとは、オンラインでクレジットカード情報を入力する時に、悪意のある人がその入力フォームをこっそり変えてしまうことです。これによって、ユーザーが入力した大事な情報が盗まれるのです。 2024年10月3日、タリーズコーヒーが発表したところによると、約5万3000件のクレジットカード番号やセキュリティコードが漏れてしまった可能性があるとのこと。この事件の原因も改ざんでした。 この手口は10年以上前からあるのに、最近でも被害が後を絶ちません。私たちも、オンラインでカード情報を入力する時は、特に注意が必要です。大切なお金や情報を守るために、しっかり気をつけましょう。 ↑ AIに生成させてみた文章です。 ↓ 人間が書いてます。 漏洩した可能性がある情報は以下のように非常に深刻なものです。 漏洩した可能性がある情報 個人情報 ・氏名 ・住所 ・電話番号 ・性別 ・生年月日 ・メールアドレス ・ログインID ・ログインパスワード ・配送先情報 クレジットカード情報 ・クレジットカード番号 ・カード名義人名 ・有効期限 ・セキュリティコード 今回のタリーズオンラインショップ程のECサイトであれば、私も安心してカード情報の入力をしてしまうと思います。 利用者が自己防衛をするのはかなり難しいです。 かといってECサイト側での対応も難しいのが現状です。 例を挙げますと、つい先週になりますが楽天市場で買い物をした際に、不正アクセスを疑われたようで「注文キャンセル&アカウントロック」をされてしまいました。 ここ何年も利用していなかったのに5万円程度のものを立て続けに購入したというのがAIに犯罪の可能性を疑われ、仕事で必要なものを買っただけなのにこれでは別の意味で信頼を失ってしまいます。 楽天市場ほどの規模にもなると、一定のスコアで黒扱いにするというシステムにするしか方法は無いのかもしれませんが、厳しくすれば善良なユーザーに迷惑が掛かり、緩くすれば悪意を持ったユーザーがすり抜けるという難しさがあります。 迷惑メールのフィルタリングや、警察による職務質問などにも言えることなんでしょうが。 また、タリーズから発表があったこの文章が気になります。 既に弊社では、クレジットカード会社と連携し、漏洩した可能性のあるク […]
2018-05 x64 ベース システム用 Windows 10 Version 1803 の累積更新プログラム (KB4100403) Windows Updateカタログ 飛びつこうと思ったんですが、先週のトラブルが嘘のように、サウンドドライバの更新をして以来とても安定していまして。(詳しくはこちらの記事の下のほうをご覧ください) 「魔の1週間よ再び」ってなりたくないしな~。 今回の更新ですが、Microsoft気合入れてきてますね。 ビルド17134.81(0.80も上がった~) 430MBってサービスパックレベルですね。 しかし、今回ばかりは人柱お願いします。 m(__)m まあ、週が明けたらやってみますね。 追記:その後KB4100403インストールして動作検証しました。
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サイトが「スマホに対応していない」「SSLに対応していない」「Flashなどの古い技術を使用している」に該当していたら至急リニューアルを検討してください。
Webコンテンツの適正画像サイズをディスプレイ解像度の利用者統計データを元に検証します。 ホームページに載せる適正画像サイズをデータで検証という記事から11年も経ってしまいましたので2018年版を載せました。 (StatCounterによる統計データを元にしています。) 2018年版が確定したのでデータおよびグラフを修正しました。 2019年版も(確定版ではありませんが)掲載しました。 Webコンテンツに使用する画像サイズ結論 掲載データが多くなってしまいましたので、結論を先に書いておきます。 パソコンのモニター幅いっぱいの可変サイズの画像(ヘッダ等)を想定するのであれば、(w)2,000ピクセルは必要。これくらいあれば(w)2,560ピクセルで表示したとしても耐えられるクオリティ。10年前に比べると回線環境は良くなったとはいえ、画像サイズが大きくなれば読み込みに時間がかかり、またスマホユーザーに無駄なデータ通信量を消費させてしまう。 記事に添える画像は300~800ピクセル程度のサムネイルを表示して、高解像度が必要であれば元画像にリンクを張る。 レスポンシブデザインの場合、表示サイズと同等にリサイズされた画像が表示される工夫が必要。(CSSにwidthを書いても元画像が同じであればデータ量は変わらず、w320のスマホユーザーにw2,000の画像を送り付けるという事態に。) jQueryで端末サイズに応じて読み込む画像を振り分けるのが今のところ良さげ。 下記のようなメディアクエリーを書いても読み込む画像が増えるだけで逆効果。 <img class=”w1920″ src=”../img_1920.png” /> <img class=”w480″ src=”../img_480.png” /> .w1920 { display: block !important; } .w480 { display: none !important; } @media only screen and (max-width: 480px) { .w1920 { display: none !important; } .w480 { display: block !important; } } 2018年ディスプレイ解像度利用者率Best10(世界) 1366 […]
サーバーを運用してきた18年間に遭遇したバックアップ・リストアの具体的な問題と改善策をまとめてあります。
Webコンテンツをシルバーファーストで Web制作において「パソコンで表示する文字サイズはvwを使ってmax-widthは1920pxまで対応するべき」という話。 最近は年配の方でも自宅でネットを楽しんでいますが、小さい文字が読みにくいためブラウザを最大化にしている姿をよく見かけます。 残念なことに、有名どころを含めてほぼすべてのサイトで文字は大きくならずに、左右の空白が増えるのみ。 「Ctrlを押しながらマウスホイールで拡大」すれば大抵のブラウザでは拡大されますが、そんな技を使っている一般高齢者を見たことがありません。 パソコンのディスプレイサイズは昔と比べて大きくなりましたが、それと共にディスプレイの高精細化も進んできたため、「目が悪くなってきたから大きなディスプレイを買うかのう」は期待を裏切られる結果となってしまいます。 一般的にWeb制作の現場では、幅1920px以上で見る人向けに作ってしまうと、小さいディスプレイ(解像度の低い)を使っている人や、ブラウザを最大化しないで使用している人には表示がはみでてしまうため、幅1000~1200pxで見た時に最適になるように制作されています。 少し前まではタブレットやスマホはこれよりも画素数が少ないものが多かったため、レスポンシブデザインという表示サイズによって可変のデザインが主流になりました。 しかし可変とは言っても通常はモバイル対応がメインです。画素数の大きい端末での全画面表示は基本的にあまり考慮されず、大きすぎる端末から見た場合にデザインが崩れるのを嫌がり、上述のように幅1000~1200pxを超えた場合は、それ以上には広がらずに左右の余白だけが広がるというのが現状です。 高齢化時代のWebスタンダートに max-width は最低でも1920px、4Kが主流になることを考えると4000px程度までは欲しいです。 メニューやヘッダ・フッタ等以外のコンテンツ部分のフォントサイズは、vwで指定。 これでサイトを作ってみたところ閲覧が非常に楽でした。 椅子にふんぞり返ったままでも、ブラウザを最大化すれば楽に文字が読めます。 あいにく当サイトはまだ着手できていませんので下記サイトをご覧ください。 ブラウザを最大化もしくは幅を広げると、デザインが崩れない範囲で文字も大きくなります。 現在主流のディスプレイ解像度を考慮して […]
BuffaloのLinkStationというネットワーク対応の外付けHDDを使っていますが、管理画面が何をするにも異常に遅くて、他の方も書かれていましたが設定するのが億劫になります。 ファームウェアの更新やメディアサーバーをオフにしてみたりしましたが解決しなかったのですが、原因がわかりました。 Buffalo LinkStation 管理画面の動作を速くする方法 Internet Explorerで管理画面にアクセスすると、実用レベルの遅さになりました。 それまではGoogle Chromeを使っていたのですが、メニュー項目をクリックするたびに5秒~10秒、ひどいときにはそのまま処理が返ってこないという状況でした。 ひょっとしてと思いIEからアクセスしてみたところ、画面遷移に1~3秒程と(じゅうぶんに遅いですが)設定するには実用的なレベルになりました。
インデックス登録されましたが、サイトマップに送信していません 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を比較するとマッチしていましたので、これで解決です。
PukiWikiのコメントスパム対策にGoogle reCAPTCHA v3を導入してみようと思ったのですが、検索してもWordPress前提の記事ばかりでしたので、具体的なソースコードを公開しておきます。 プラグインをわざわざ導入しないでもPHPで書かれたシステムであれば流用できます。 WordPress上のContact Form 7に表示される「reCAPTCHA v3バッジを非表示にする方法」は下記の別記事をご覧ください。 https://www.ii-sys.jp/notes/1511 Google reCAPTCHAにサイトを登録する まずGoogle reCAPTCHAでドメインを追加してreCAPTCHAのキーを2種類(サイトキーとシークレットキー)取得しておきます。 送信フォームを修整する 【1】フォームを表示する部分にJavaScriptを追加 インプットフォームが設置してあるページに以下を加えます。 挿入する場所は<head>と</head>の間が一般的ですが、ページ表示速度を考えると</body>直前が良い等いろいろありますが、そのあたりは今回触れません。 私の場合は、<form>と</form>の間に挿入しました。 手書きのHTMLならまだしも、最近はほとんどのコンテンツがPHPによる出力になっていますので、ヘッダ出力部分に追記するだけですと他の全てのページにまで挿入されてしまい、表示速度に悪影響を与えてしまいます。ですのでヘッダ出力部分に「インプットフォームがある場合にのみ挿入」という振り分け処理を入れる必要があるのですが、将来的にインプットフォームの表示ページ名等に変更があった際に、ヘッダ部分の書き換えを覚えている自信もないので、<form>~</form>にまとめたという次第です。 <script src=”https://www.google.com/recaptcha/api.js?render=ここにサイトキーを入れる”></script> <script> grecaptcha.ready(function() { grecaptcha.execute(‘ここにサイトキーを入れる’, {action […]
いまだに回線もサーバーも自社運用しているWeb制作会社がクラウド(VPS)への移行を考えて現在の構成を見直してみる。ランニングコストもさることながらスキル習得に無駄な時間を注ぎ込んできた気がする。
