Zoomに代わるオンライン会議ツールを無料で公開しています。
登録不要でブラウザからもすぐに利用できますので検証としてご活用ください。
Jitsi Meet
記事検索
ICT実践記事
- WordPressテーマXeory Extensionで同名のid属性が出力されるのを修整する
WordPress用のテーマXeory Extensionでトップページ表示用のfront-page.phpが、同じid属性の値(id=”front-contents-1″とid=”front-service-1″をそれぞれ複数)を持つ要素を出力してしまっているのを修正する方法。
- WordPressのTheme(テーマ)選びは大切
紺屋の白袴とでもいいましょうか、いろいろと問題の多いOneToneというWordPressテーマを当コンテンツでは使用しています。 一般的なサイトでの使用はおすすめしません。 私がOneToneを選んだ主な理由 このテーマを使う以前は、ホームページ全面にFlashを多用したコンテンツとなっていて、早急な改善の必要性に迫られていた。 海外のWordPressテーマサイトで上位にランキングされていた。 OneToneのインパクトが強く一目惚れしてしまった。 SEOで検索結果上位を狙う気はあまりなかった。 コンテンツ移行に(サーバー移行も含めて)1時間程度しか掛けたくなかった。 また自社サイトでしかできない、お客様には提案できないような(爆弾を抱えた)テーマを試してみたかったという部分も大きいです。 悪い点 独自に作りこまれているためカスタマイズがしにくい。 プラグインも必要となり、ページ読み込み速度が遅い。 ランディングページ向きに設計されていて、WordPressのページという概念がほとんどない。 タグが微妙(h2タグがフッタータイトル等)でSEOに弱い。 英文フォント仕様なので、スタイルシートの変更が結構必要。 トップ動画等に一部不具合あり。 良い点 見た目のカッコよさ。 基本的に1カラムのレスポンシブなので、PCとスマホで同じイメージを提供できる。 jQuery盛りだくさんで、昔ホームページビルダーで「アニメーションgifで画像が動く」「音楽が流れる」というコンテンツを好んで作られていた方には受けが良いかもしれません。 時代に逆行している感は否めませんが、もうしばらくOneToneを少しずつカスタマイズして使ってみようと思います。 まずはフッター周りですね。 「関連サービス」 「リリース」 「障害情報」 で検索エンジンに働きかけても意味ないですし。
- 最近主流のPC用ディスプレイ解像度は?【過去10年間の推移】
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 […]
- 時代錯誤な自社サーバーをクラウド(VPS)にするメリット
いまだに回線もサーバーも自社運用しているWeb制作会社がクラウド(VPS)への移行を考えて現在の構成を見直してみる。ランニングコストもさることながらスキル習得に無駄な時間を注ぎ込んできた気がする。
- 小中学校「1人1台タブレット」いよいよ導入【豊後高田市】
大分県豊後高田市の小中学生に、1人1台導入されるタブレットについて概要を独自にまとめました。
- サーバーのバックアップで過去18年間に遭遇した問題点
サーバーを運用してきた18年間に遭遇したバックアップ・リストアの具体的な問題と改善策をまとめてあります。
- WordPressをお名前.comのレンタルサーバーRSプランに引っ越しをする際の注意点
お名前.comのコントロールパネルからMySQLファイルをインポートしようとするとエラーが発生した際の解決方法。WordPressのファイル転送はFileZilla(SFTP)を使って問題なく完了。
- 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 = […]
- 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
- 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を比較するとマッチしていましたので、これで解決です。
- 常時SSL証明書の更新エラー対処法
上記のような画像がでてビックリされる方も多いと思います。当サイトでも数日の間、表示されてしまっていました。 パスワード、メッセージ、クレジットカード情報などを不正に取得しようとしている可能性があります。 してません…。 中にはそういったサイトもあると思いますが、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 […]
- OCNのPOP・SMTPメール設定をBecky!にする方法
プロバイダから支給されているメールアドレスはほとんど使っていないのですが、OCNから【再度のご案内】【重要】と、えげつないメールが来ていたので目を通してみると、本当に重要な内容でした。 OCNではセキュリティ強化のため、 2019年10月1日以降順次、OCNメールをメールソフトでご利用いただく際、推奨設定以外では送受信(POP/SMTP)できないように変更いたします。 最近では受信メールにPOPを使う人は少ないのかもしれませんが、私はPOP派で、50以上のメールアカウント全てをPOPで設定しています。 自サーバにおいては何年か前にサブミッションポートの運用に切り替えましたが、OCNのメール設定は放置したままでした。 メールクライアントは以下のような理由からBecky!をいまだに使っています。 動作が軽快 複数アカウントの管理がしやすい データのインポート・エクスポート・バックアップが簡単で確実 過去にパソコンを入れ替えるたびにデータを引き継いできたため、受信箱には1999年のメールもいまだに残っています。 POPでの受信に加えてBecky!を使っている人となると限られてくるため、OCNの公式サイトはもとよりネット上を調べてもなかなか情報を得られませんでした。 2019年10月以降もBecky! Internet MailでOCNのメールをPOP・SMTPで送受信するポイントをまとめておきます。 この記事の対象となる方 OCNのメールをPOP・SMTPで使用されている方 メールクライアントにBecky!を使用されている方 OCNのPOP・SMTPメール設定をBecky!にする方法 OCN公式サイトによりますと、POP・SMTPの設定は以下のようにする必要があるそうです。 受信メールサーバー(POP3) pop.ocn.ne.jp と入力 ポート番号 995 と入力 SSL 使用する ユーザー名 メールアドレスをすべて入力 送信メールサーバー(SMTP) smtp.ocn.ne.jp と入力 ポート番号 465 と入力 SSL 使用する 認証 使用する ユーザー名 メールアドレスをすべて入力 Becky!「メールボックスの設定」を表示します 複数のメールアカウントを設定している場合には、該当のプロファイルを選択します。 Becky!基本設定の変更箇所 POP3サーバー […]
- 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に変換するサービス […]
- シルバーハッカー世代がやってくる。時代はVGA。
Webコンテンツの制作をするにあたって、Internet Explorer/Google Chrome/Firefox/Safariといった主要ブラウザに加えて携帯電話での表示も乱れないようにと、クロスブラウザ対応に多くの時間を費やしてきました。 その後HTMLの文書構造が重要視されるようになり、テーブルタグを使ってページレイアウトをすることも減り、またフラットデザインというシンプルなデザインが好まれる風潮になり、クロスブラウザ対応もだいぶ楽になりました。 さらにスマホやタブレットが急速に普及したおかげでレスポンシブデザインが主流となり、構造化されたHTMLとメディアクエリを書いたCSSで多くのブラウザに対応できるようにもなりました。 さて前置きが長くなりましたが「今後何を基準にレイアウトを決めようか」と悩む出来事がありました。 下記をご覧ください。このサイトの記事です。 見る人の設定次第で表示は大きく異なる どちらも同じ記事です。 1枚目が私の見ている環境、2枚目が一般的な表示環境です。 このコンテンツは「WordPress」+「海外のテーマ」を1時間程度の簡単なカスタマイズだけ施したものですが、パソコンから閲覧する際に、Windowsやブラウザのフォントサイズを巨大化させているのを忘れていました。 数年前から近眼なのか年のせいか、小さい文字が非常に疲れるんです。 高解像度ディスプレイは人間の目の限界超え 時々訪問先で「文字が小さくて」という話を耳にするのですが、拡大表示設定などをすると、文字がぼやけてしまいとてもお勧めできるものではありませんでした。 XGA(1024 x 768)がまだ出たてのころ、とある会社の社長デスクの設定を行った際に、VGA(640 x 480)にしたらとても喜んでもらったことがありました。内心(「もったいない…」)と思っていましたが。もう文字滲みまくり。 若い人は解像度が高い=多くの情報が表示できるというのを好みましたので、設定で文字を大きくするような人はあまり見かけませんでした。 しかし最近はディスプレイの解像度が高くなりすぎて、そのままでは非常に小さい文字となってしまうため、OSやアプリによる拡大表示機能が充実してきています。 [DropWin src=”https://www.ii-sys.jp/tips/506″]4Kモニ […]
- 光ネクストへ切り替わったのでルータ新調で下り320Mbps
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ケーブルを「欲しいものリスト」に […]