テンキー[7]の上にある[NumLock]キーを押してしまうとテンキーから
数字の入力ができなくなります。
もう一度[NumLock]キーを押すことにより、テンキーが有効になります。
一般的なキーボードにはNumLockLEDがあり、点灯している状態が
テンキーから数字入力可能な状態となります。
&ref(numlock.jpg);
テンキー[7]の上にある[NumLock]キーを押してしまうとテンキーから
数字の入力ができなくなります。
もう一度[NumLock]キーを押すことにより、テンキーが有効になります。
一般的なキーボードにはNumLockLEDがあり、点灯している状態が
テンキーから数字入力可能な状態となります。
&ref(numlock.jpg);
OCNのPOP・SMTPメール設定をBecky!にする方法
WordPressのTheme(テーマ)選びは大切
Google Ad Grantsで支払情報を求められてしまう
WordPressでメディアをアップロードできない
ConoHa VPSリニューアル後のプランに移行する方法
XMLサイトマップをGoogle Search Consoleに準拠
学校で使うiPadのバッテリー持ちが悪い
偽サイトに嵌って防衛手段を検証する
Let’s EncryptでSSL証明書の発行・更新・トラブル
フレッツ光を使っている人はウイルス対策ソフトを買う前に確認
無観客で行われる小学校の運動会を複数カメラでライブ配信したい
WordPressリダイレクトプラグインで日本語を扱えるように修正
「画像の後処理に失敗しました。このファイルが写真もしくは大きい画像であれば、2500ピクセルに縮小してから再度アップロードしてください。」というWordPress 5.3のエラーについて。
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担当者スキルに合わせて管理 […]
NTTのフレッツ光プレミアムが2019年1月末で終わるという事で、トラブルの出尽くしたであろうギリギリで切り替え工事をしてもらいました。 「ハイスピード」と「ハイスピード隼」が選べましたが、工事に何倍も時間のかかる「ハイスピード隼」でお願いしました。(工事に来ていただいた業者様、忙しい時期にありがとうございました) タイトルの「下り速度320Mbps」ですが、実は古いルータ(NEC WR8700N)の有線接続で出た数字です。 あ、すみません。画像加工してMbpsをbps表記にしてあります。 オリジナルは↓これです。 WR8700Nのレビューはこちらが参考になります。 2010年の製品ですのでIEEE802.11n/11aしか対応していないのと2ストリーム(アンテナが2本)のためか、別の階でのWiFiは遅く、3台・4台と接続すると良く通信が切れたりしていました。 業務用はYAMAHA、家庭用はNECという信念を10年以上貫いてきましたが、家庭用ならバッファローもありかな…と。(NTTが切り替え工事の際に施策ルータとして提供しているのがBuffalo又はYAMAHAだったのがトドメ) お買い得品をネットで見つけて買ったのが「WSR-2533DHPL」です。 バッファローのルータは、WSR-2533DHP(L無し)とかWXR-2533DHPとか間違い探しみたいな型番号が多いので、気を付けてください。 IPoE(IPv6)には対応していませんが、4ストリームで1733Mbps(5GHz)+800Mbps(2.4GHz)が魅力で実売価格7,000~8,000円。 9年前の機器とはさすが違いますね。 別の階で2台のパソコンを使っているのですが、どちらもUSBタイプの無線LAN子機を使っています。それも1,000円もしない11acには非対応で2.4GHz専用のもの。 それでも平均して下り速度100Mbps~200Mbps 出ています。 さらに非常に安定しています。 有線もすいている時には400Mbpsを超えます。 スマホやタブレットもWiFi回線が安定し、ブロスタやスリザリオがぬるぬる動くようになったと評判です。 屋根裏に潜ってLANケーブル引っ張ろうかと、釣り竿まで用意していたのが不要になりました。 無理なら屋外から引っ張ろうと、防水LANケーブルを「欲しいものリスト」に […]
送信者を偽装できる脆弱性 Mailsploit Mailsploitの脆弱性が発表されてから半年余り過ぎますが、なぜか日本ではあまり話題にすらなっていません。 バックドアを仕掛けられる等、直接ファイルを改竄されるわけではないからなのでしょうか。 しかし悪用しようとする人からすれば、本人だという証明付きで権威ある人になりすましてメールを送れるというのは、最高のソーシャルハッキングツールです。 私宛にトランプ大統領からメールが来たところで(仮に本人だったとしても)日本語以外のメールは普段やりとりをしていないので、迷惑メールと決めつけて開封すらしないでしょう。 差出人がソフトバンクの孫正義さんであったとしても、 「ついに自分も認められたか」などと思い上がるほど若くはありません。 怖いのはもっと身近な人を詐称したメール。 取引のある会社の担当者から本人証明されたメールが届けば、疑うよりも先に開いてしまいます。 URLが記載されていれば、ソースをじっくり見ることもせずにクリックしてしまうかもしれません。 緊急なのでこちらに電話を!と電話番号が記載されていれば、電話してしまうでしょう。 振り込め詐欺なんかと組み合わされると、比較的ITリテラシーが高い人でも騙されてしまう危険性があります。 Mailsploitの影響を受けるメールソフトが非常に多く、ThunderbirdやApple Mail.app・Outlook 2016などを使っている人も多いのではないでしょうか。 一部メーカーからは既に対策パッチも出ていますが、対策しないと宣言をしているメーカーもあります。 該当するアプリを使っている方は情報収集が必要そうです。 影響を受けるメールクライアント Apple Mail.app MACOS IOS Mozilla Thunderbird / SeaMonkey MACOS WINDOWS Mail for Windows 10 WINDOWS Microsoft Outlook 2016 MACOS WINDOWS Yahoo! Mail IOS Yahoo! Mail ANDROID [A bug bounty program that does not allow disclosure yet] ANDROID [A bug bounty program that do […]
上記のような画像がでてビックリされる方も多いと思います。当サイトでも数日の間、表示されてしまっていました。 パスワード、メッセージ、クレジットカード情報などを不正に取得しようとしている可能性があります。 してません…。 中にはそういったサイトもあると思いますが、SSL証明書を失効してしまっているサイトが大多数です。 常時SSLへの対応 Googleらが推し進めている常時SSL化がかなり浸透してきました。 常時SSL化とは、Webサイト全体をHTTPS化する(暗号化する)ことを言います。 以前は個人情報を送信するフォームを設置したページだけに使われるのが一般的でしたがここ数年で急速に常時SSL化が推し進められ、ブラウザによっては、SSL化されていないページは警告表示されるようにまでなってきました。 SSL化が進んだ背景についての詳細はこちらのサイトに詳しく書いてあります。 IISYSでは2017年よりLet’s Encryptを使った常時SSL試験運用をして参りましたが、証明書更新時にいくつかの問題に遭遇しましたので、レポートしておきます。 【現象】一部のドメインで自動更新が効かず、証明書の期限切れを起こしてしまう。 Webサーバーによるリダイレクト設定 well-knownディレクトリのパーミッション設定 WordPress等CMSを動かしている場合のHTTPステータスコードの問題 上記のような環境下でSSL証明書の更新がうまくいかずに期限切れを起こしてしまい、該当ドメインのサイトを開こうとするとブラウザ警告がでて表示されないという事象がネット上でも多く見受けられました。 該当ドメインの本来のルートディレクトリでは無く、認証専用のディレクトリを用意しておく方法で、多くの運用方法に対応することができます。 /usr/local/www/letsencrypt バーチャルドメイン運用の場合、上記のようなディレクトリを作成しておき、それをwebrootに指定します。 # certbot certonly –webroot -w /usr/local/www/letsencrypt -d DOMAINNAME 証明書が無事に発行されたら、Webサーバーの設定をしておきます。 Nginxの設定例 webroot.conf location ^~ /.well-know […]
BuffaloのLinkStationというネットワーク対応の外付けHDDを使っていますが、管理画面が何をするにも異常に遅くて、他の方も書かれていましたが設定するのが億劫になります。 ファームウェアの更新やメディアサーバーをオフにしてみたりしましたが解決しなかったのですが、原因がわかりました。 Buffalo LinkStation 管理画面の動作を速くする方法 Internet Explorerで管理画面にアクセスすると、実用レベルの遅さになりました。 それまではGoogle Chromeを使っていたのですが、メニュー項目をクリックするたびに5秒~10秒、ひどいときにはそのまま処理が返ってこないという状況でした。 ひょっとしてと思いIEからアクセスしてみたところ、画面遷移に1~3秒程と(じゅうぶんに遅いですが)設定するには実用的なレベルになりました。
WordPressを使い慣れていて、ドメイン変更等も手動でsql置換して~とやった事がある方が「今回は楽にやってみたい」と、ナメてかかると意外とハマります。 ドキュメント読めば書いてあるんでしょうが、甘く見ているだけに慣れ親しんだ日本語ページをGoogleで探して斜め読みして取り掛かるものですからなおさら。 移転先サーバーにはWordPressをインストールしない。 これ重要です。 多くのサイトで「WordPressをインストールしておく」と書いてありますが、zipが解凍できなかったり、パーミッションの問題が発生したりと問題を引き起こします。 私もエラーが発生したので、サーバーコンソールでunzipのパス確認したり、installer.phpの該当部分を眺めてみたりしましたが、ディレクトリを削除するだけでOKでした。 新しいサーバーに設置するのは旧サーバーからダウンロードした2つだけ。 installer.php 20180000_XXXXXXX_archive.zip これだけの記事なんですけど、少し寂しいので他のポイントも挙げておきます。 installer.phpにアクセスする前にドキュメントルート(public_html等)を一旦707等にしておき、終わったら戻す。 nginxでキャッシュを使っている場合には止めておかないとハマる。 正常に動作することが確認できたらアップロードした2つ以外にも消しておいたほうが良さそうなファイル。 20180000_XXXXXXX_archive.zip installer.php database.sql installer-backup.php web.config installer-data.sql .htaccess (旧サイトで使用していた場合を除く) installer-log.txt Contact Form 7等でGoogleのreCAPTCHAを使っている場合などは「サイト所有者のエラー:サイトキーのドメインが無効です」と表示されていると思うので申請を忘れずに。 旧サイトへの301リダイレクト設定。
最近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を正確に書きます。
WordPress用のテーマXeory Extensionでトップページ表示用のfront-page.phpが、同じid属性の値(id=”front-contents-1″とid=”front-service-1″をそれぞれ複数)を持つ要素を出力してしまっているのを修正する方法。
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に変換するサービス […]
ConoHa VPSがリニューアルされました。自社サーバーの移設先として使えそうなVPSサービスを実際に契約して試した結果を独自の視点から検証しました。
WordPressに目次を自動挿入するプラグイン「Easy Table of Contents」をカスタマイズして表示を最適化したCSSを配布。
WordPressでCSSが反映されないという疑問について、テンプレートLightningを例にWEB制作現場で実際に行っているデベロッパーツールの活用方法をご紹介します。
WordPress管理画面のユーザー一覧から不要な項目を削除・オリジナル項目を追加し、並び替えができるように設定する方法をコピペ可能なソースで紹介。
Webコンテンツをシルバーファーストで Web制作において「パソコンで表示する文字サイズはvwを使ってmax-widthは1920pxまで対応するべき」という話。 最近は年配の方でも自宅でネットを楽しんでいますが、小さい文字が読みにくいためブラウザを最大化にしている姿をよく見かけます。 残念なことに、有名どころを含めてほぼすべてのサイトで文字は大きくならずに、左右の空白が増えるのみ。 「Ctrlを押しながらマウスホイールで拡大」すれば大抵のブラウザでは拡大されますが、そんな技を使っている一般高齢者を見たことがありません。 パソコンのディスプレイサイズは昔と比べて大きくなりましたが、それと共にディスプレイの高精細化も進んできたため、「目が悪くなってきたから大きなディスプレイを買うかのう」は期待を裏切られる結果となってしまいます。 一般的にWeb制作の現場では、幅1920px以上で見る人向けに作ってしまうと、小さいディスプレイ(解像度の低い)を使っている人や、ブラウザを最大化しないで使用している人には表示がはみでてしまうため、幅1000~1200pxで見た時に最適になるように制作されています。 少し前まではタブレットやスマホはこれよりも画素数が少ないものが多かったため、レスポンシブデザインという表示サイズによって可変のデザインが主流になりました。 しかし可変とは言っても通常はモバイル対応がメインです。画素数の大きい端末での全画面表示は基本的にあまり考慮されず、大きすぎる端末から見た場合にデザインが崩れるのを嫌がり、上述のように幅1000~1200pxを超えた場合は、それ以上には広がらずに左右の余白だけが広がるというのが現状です。 高齢化時代のWebスタンダートに max-width は最低でも1920px、4Kが主流になることを考えると4000px程度までは欲しいです。 メニューやヘッダ・フッタ等以外のコンテンツ部分のフォントサイズは、vwで指定。 これでサイトを作ってみたところ閲覧が非常に楽でした。 椅子にふんぞり返ったままでも、ブラウザを最大化すれば楽に文字が読めます。 あいにく当サイトはまだ着手できていませんので下記サイトをご覧ください。 ブラウザを最大化もしくは幅を広げると、デザインが崩れない範囲で文字も大きくなります。 現在主流のディスプレイ解像度を考慮して […]
