皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

先週『WordPress5.3.1リリース情報』の記事を投稿しましたが、それに続き『WordPress 5.3.2』が2週連続でリリースされました。

今日はそれをお伝えします。

WordPress 5.3.2 メンテナスリリース

前回の『WordPress 5.3.1』のリリース直後、いくつかの重要度の高いチケットが上がったため『WordPress 5.3.2』がクイックメンテナンスとしてリリースされました。

今回のリリースで対処された問題は以下の通りとなります。

・日付/時刻：get_feed_build_date（）が無効な日付の変更された投稿オブジェクトを正しく処理する変更。

・アップロード：大文字と小文字を区別しないファイルシステムで大文字の拡張子を持つファイルをアップロードするときのwp_unique_filename（）でのファイル名の衝突を修正。

・メディア：宛先ディレクトリが読み取れない場合のwp_unique_filename（）のPHP警告を修正。

・管理：.activeクラスを持つボタンのすべての配色の色を修正します。

・テスト/ビルドツール：wp_insert_post（）で、投稿日をチェックして将来のステータスまたは公開ステータスを設定するときに、適切なデルタ比較を使用する変更。

以上のようにWordPressの公式サイトには投稿されています。

前回に続きマイナーアップデートですから、そのままアップデート更新で良いでしょう。

今回のリリースは4件のセキュリティ修正を含む『Security and Maintenance』リリースです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

日本時間の今日、『WordPress』の更新版『WordPress 5.3.1』が公開されました。

今日はそのニュースをお伝えします。

WordPress 5.3.1セキュリティ&メンテ

さて、今回のリリースは『WordPress 5.3以前のバージョン』で影響を受けるとされるセキュリティ修正、バグ修正、機能強化となります。

『更新を強く推奨する』といったコメントではなく、『アップグレードする必要がある』というコメントが掲載されているため、アップデートすべきでしょう。

以下、アップデートの内容です。

＜セキュリティアップデート＞

・非特権ユーザーがREST APIを介して投稿をスティッキーにする可能性のある問題を修正

・クロスサイトスクリプティング（XSS）が巧妙に作成されたリンクに保存される可能性のある問題を修正

・wp_kses_bad_protocol（）を強化して、名前付きコロン属性を認識できるようにするための修正

・ブロックエディターのコンテンツを使用して、保存されたクロスサイトスクリプティング（XSS）の脆弱性を修正

＜メンテナンスアップデート＞

・管理：管理フォームコントロールの高さおよびアライメントの標準化の改善、ダッシュボードウィジェットリンクのアクセシビリティ、および代替カラースキームの読みやすさの問題を改善

・ブロックエディター：Edgeのスクロールの問題と断続的なJavaScriptの問題を修正

・バンドルテーマ：作成者の略歴を表示/非表示にするカスタマイザーオプションを追加し、JSベースのスムーズスクロールをCSSに置き換え、Instagram埋め込みCSSを修正

・日付/時刻：非GMT日付の計算を改善し、特定の言語での日付形式の出力を修正し、get_permalink（）をPHPタイムゾーンの変更に対してより回復力のあるものにする

・埋め込み：サービスが存在しないため、CollegeHumor oEmbedプロバイダーを削除する

・外部ライブラリ：sodium_compatを更新する

・サイトの正常性：管理者の電子メール検証のリマインド間隔をフィルタリングできる

・アップロード：ファイル名が一致する場合、サムネイルが他のアップロードを上書きしないようにし、アップロード後にPNG画像をスケーリングから除外する

・ユーザー：管理メールの確認で、サイトロケールではなくユーザーのロケールが使用されていることを確認する

・その他

以上のようになっています。

例によって早めの段階で『WordPress 5.3.1』へアップデートされることがお勧めです。

今回のリリースには、『WordPress 5.2.2』以前のバージョンに影響する『セキュリティ修正』や『バグ修正』などが含まれているとされています。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、冒頭に書いた通り『WordPress 5.2.3』がリリースされたわけですが、今回は『セキュリティ＆メンテナンスリリース』となります。

今日はその話題をお伝えします。

WordPress 5.2.3へアップグレードする必要がある

『WordPress（英語版）』のブログニュースを見ると、今回は『WordPress 5.2.2』以前に影響する『修正』となっています。

以下、修正された内容です。

・投稿者による投稿プレビューのクロスサイトスクリプティング（XSS）の脆弱性

・保存されたコメントのクロスサイトスクリプティング（XSS）の脆弱性

・URLの検証とサニタイズがオープンリダイレクトにつながる可能性

・メディアのアップロード中におけるクロスサイトスクリプティング（XSS）の脆弱性

・ショートコードプレビューでのクロスサイトスクリプティング（XSS）の脆弱性

・クロスサイトスクリプティング（XSS）攻撃につながる可能性のあるURLサニタイズの問題

・ダッシュボードでのクロスサイトスクリプティング（XSS）の脆弱性

・etc…

今回のリリースには29の修正と機能強化が含まれており、多数のセキュリティ修正が追加されていることもあり、早い段階で『WordPress 5.2.3』へのアップデートが望まれます。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

よくある話しですが、『お金をかけたのに効果がない。。。』とWebサイト（ホームページ）のオーナーが嘆きます。

そこで質問です。

『そのWebサイト（ホームページ）はちゃんと育てていますか？』

Webサイトからもっと情報配信を

Webサイト（ホームページ）のオーナーからの嘆きの声はよくあることですが、多くの場合においてはやるべきことをやっていません。

それは、構築した当初のまま放置し、新しい情報を何も提供していないことです。

そのような状況にあるオーナーに『何故更新しないのですか？』と聞くと、必ず同じ答えが返ってきます。

『それをやる人材もいなければ、やる時間もない。』です。

そのような答えに対して『業者に保守をお願いすれば良いのでは？』と突っ込むと、これも同じ答えが返ってきます。

『毎月のようにお金がかかるのは嫌だ。』です。

これには2通りの意味があります。

1つは『保守料まで支払う余裕はない。』というケースと、もう1つは『保守料を払うことに納得がいかない。』です。

前者のケースでWebサイト（ホームページ）構築をした場合は自社や自店にて情報配信をしていくしかありません。

その場合、前述のような答えが返ってきてしまうと『何のために構築したのですか？』となってしまい、それに対しては『単なる言い訳』としか聞こえません。

定期的に新しい情報を配信されている企業やお店であっても人材に余裕があったり時間に余裕があったりするわけではないのです。

何とか時間を作って『新しい情報』を提供されています。

後者のケースもよくある話しです。

単純に『IT系の人件費』をタダ同然のように思っている方の答えです。

しかし、そうは言っても保守する側もメンテナンスを行うのに人が時間を使って行うわけですから、そのように思われている方の会社やお店と同じように『人件費』がかかっているわけです。

話しがそれてしまいましたが、Webサイト（ホームページ）は構築したら終わりではありません。

その後も継続的に育てていくものです。

構築したWebサイト（ホームページ）にブログ機能があるのであれば定期的にブログ記事を書いてください。

もちろん自社や自店に関連した内容をです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

先週、大阪市議会の『IT技術者議員』さんが意見書を提出し、大阪市議会はそれを全会一致で可決したそうです。

それは、Microsoft（マイクロソフト）のブラウザ『IE（Internet Explorer）』を前提としたオンラインサービスをやめるよう国に求める意見書だったそうです。

IE への依存から早急に脱却すべき

昨今、ブラウザに『IE（Internet Explorer）』を使用するユーザーは非常に少なくなっています。

また、最新のIE11以外（IE10やIE9以前のバージョン）はサポートが終了していることからセキュリティ上危険とされてもいます。

しかし、銀行系や行政のオンラインサービスを中心に、未だIE（Internet Explorer）での使用に限定した動作保証を行うサービスは多く存在します。

そんな状況を認識しているのかいないのか、オンラインサービスサイトをリニューアルした後もIE（Internet Explorer）に限定した動作保証のサービスも多々あります。

『見直しは行わないのか？』と、思ったりしませんか？

正直なところ、どのブラウザも動作保証を行うとしてしまった場合にはメンテナンスの観点からすると大変だと思う気持ちは理解できなくはありません。

であれば現状の利用状況も把握し直し、もう少し間口を広げても良いのではないでしょうか。

もしMicrosoft（マイクロソフト）ありきで進めようとするならば、『Edge』ともう1つ他社のブラウザくらいは使用可能にした方が利便性が上がるように思います。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

ウェブサイト（ホームページ）を公開している会社や店舗であれば、自社や自店のウェブサイト（ホームページ）にどれくらいのアクセスがあるのかが気になるところです。

しかし、その中に自社や自店からアクセスしたものも含めていては正確なアクセス数に大きな誤差が生じる場合があります。

WAN側のIPを定期的に見直す必要性

ウェブサイト（ホームページ）のアクセス解析を行う場合、多くはGoogleのAnalytics（アナリティクス）が使われていますが、それに何も設定をしなければ全てのアクセスが含まれてしまうため正確なアクセス数とは言えないことが多いのも事実です。

つまり、自社や自店の従業員・スタッフがアクセスした数まで含まれてしまうため、大幅にアクセス数が増えてしまっていることも考えられます。

これはAnalytics（アナリティクス）の管理上でフィルタリング設定を行うことで除外できますが、問題なのは自社や自店で契約しているインターネット回線のWAN側IPアドレスです。

どういうことかと言うと、中小・零細企業、小規模事業者の多くは固定IPアドレスの契約をすることは少なく、OCNやauなどのプロバイダから割り当てられる動的なIPアドレスを使用することになります。

これが今日の本題です。

プロバイダから割り当てられる動的なIPアドレスはある日突然変わることがあります。

例えば、プロバイダ側で設備メンテナンスがあったとか、影響する部分において障害が発生したとか、自社や自店付近などにおいて停電があったとかによる影響を受けます。

このような場合、自社や自店に設置されているルータはIPアドレスを取得し直すため、WAN側のIPアドレスが変わってしまうことがあるのです。

それ以外にも、セキュリティ的な観点から一定期間を経過すると割り当てているIPアドレスの割り当て直しを行うこともあり、WAN側のIPアドレスが変わってしまうのです。

これを把握しないまま放置していると当然ながらアクセス解析に影響しますので、定期的にWAN側のIPアドレスを確認し、変わっていたのであればAnalytics（アナリティクス）のフィルタ設定にて除外しているIPアドレスを変更してあげる必要性があります。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

多くの会社やお店には『ウェブサイト（ホームページ）』があると思いますが、それに対して『保守契約』はされていますか？

もしされていないのであれば損をしているかもしれません。

WEBの保守契約を嫌うと損をする

毎月、もしくは年単位で一括など、保守料を支払わなければいけないということを嫌うユーザーは結構います。

当然、お金を支出するわけですから喜ばしい話しではありませんが、その考え方は損をする可能性もあります。

何故？と思われた方、そのウェブサイト（ホームページ）は何のために制作してもらったのですか？

永遠に何も更新をしないつもりで制作してもらったのですか？

本来、ウェブサイト（ホームページ）は情報を更新していかないといけません。

これはSEO（検索エンジン最適化）対策を行っていなくてもです。

従って、制作してもらう時点でそれを育てていくことが前提だという認識を持った方が良いです。

知人が制作を受託したユーザーにこんな方がいました。

『毎月コンスタントに保守をしてもらうことがないので必要な時にスポットでお願いする。』

そして、必要になった時にはこうです。

『少しメンテナンスしてもらうだけなのに金額が高い。』

これ、その時のスポットメンテナンス料金は5,000円だったそうですが、全くもって高い料金ではありません。

年間保守契約をせず、必要な時だけスポットで依頼をするわけですから割高になるのは当り前の話しです。

（この会社の財政状態は相応に余裕がありました。）

そして、結果的にはベースに使われていたWordPressのアップデート更新（メジャーアップデート）すら行ってこなかったため、ある時アップデートが行えなくなってしまいました。

WordPressで使用しているデータベースがミスマッチとなってしまい、データベースを最新の状態にあわせない限りアップデートが行えなかったのです。

（WordPressはアップデート更新時にデータベースの更新を行うことがありますので、データベースもアップデート可能な状態にしておかないとWordPress本体のアップデートが行えなくなります。）

この後どうなったかはご想像にお任せしますが、ウェブサイト（ホームページ）であっても保守契約を嫌うとこのような顛末になってしまうこともあります。

いかがでしょうか？

保守契約を嫌うと損をするという意味がご理解いただけましたでしょうか？

人は工業製品の保守料は平気で支払う割には人の作業に対しては対価を支払うことを嫌がる傾向にあります。

物が存在しないからです。

しかし、自社内で解決できず外部に依頼せざるを得ないのであれば仕方のないことではないでしょうか。

ご自身が逆の立場であればきっと同じことを思われるはずです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、私も愛用している『Mozilla』の『Thunderbird』ですが、52系の最終は52.9.1（32bit）までとなり、今後は60系がメンテナンスされていくことになります。

そして、これには未だ公開されていないものが存在します。

Thunderbird 60系で64bitが存在

今までもMozilla Thunderbirdは『earlybird』としてであれば64bit版が存在はしていました。

ただし、これはβ版より前のα版の扱いでのことです。

そして、今回のThunderbird 60においても公式サイトにてダウンロード可能なWindows版は32bit版のみとなっています。

しかし、このThunderbird 60にはリリース版としての64bit版が存在するようです。

Thunderbird 60.0 64bit 日本語

上記のリンクはMozillaのFTPサイトで、ここからThunderbird 60.0 Windows向け64bit版がダウンロードできます。

これをインストールしてみると『Program Files (x86)』ではなく『Program Files』にインストールされ、起動後に『Mozilla Thunderbirdについて』を確認すると『60.0（64ビット』なり、その後に更新を行うと現在の最新である『60.2.1』に更新されます。

（32bit版でも最新は60.2.1です。）

ただし、Thunderbird 60系にバージョンアップした段階で32bit版、64bit版を問わず使えなくなるアドオン（拡張機能）が出てくる可能性がありますので、使用しているアドオンの対応状況を確認した上でバージョンアップを行った方が良いでしょう。

ちなみに、『Thunderbird 60.2.1』は『Thunderbird 52』系統のユーザーに対しても自動アップデートとして提供されるとアナウンスされていたものの、実際には自動アップデートは行われませんでした。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

日本時間の今日、WordPressの更新版であるWordPress4.9.7が公開されました。

今日はそのニュースをお伝えします。

WordPress3.7以降のすべてに向けたリリース

WordPressのブログニュースを見ると、今回のリリースもWordPress3.7以降のすべてのバージョンのセキュリティ及びメンテナンスリリースで、直ぐにWordPressをアップデートをすることが強く推奨されています。

また、WordPress4.9.6以前では、特定の権限を持つユーザーがuploadsディレクトリ外のファイルを削除しようとするメディアの問題の影響を受ける可能性があるともされています。

これ以外にも、

・用語クエリのキャッシュ処理の改善

・ログアウト時の投稿パスワードのCookieのクリア・

・ウィジェット管理画面のサイドバー説明に基本的なHTMLタグを許可する

など、17のバグ（不具合）修正も行われています。

いつもながら、マイナーアップデートが自動更新になっている場合はそのまま自動的に更新がなされます。

ただし、以前にもご紹介した通り、『WordPress4.9.3』において自動バックグラウンド更新をサポートするサイトが自動的に更新されないというバグ（不具合）があったため、手動で4.9.4以降にアップデートされていない場合は自動更新されることはないと思われますので、念のため管理画面で確認をしておくことをお勧めします。

マイナーアップデートも自動更新を『オフ』にしている場合は早めにアップデートされることがお勧めです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

2019年5月1日、元号は現在の平成から新元号へと変わります。

それに伴い問題となるのがシステムの元号対応。

さて、この先もこの元号対応を続けていくのでしょうか？

システム日付は西暦で管理すべき

お客様専用で構築したシステムにおいては特別指定がない限り元号対応を盛り込むことはあまり見かけない話しですが、これが業務系のパッケージシステムとなると少々違います。

業務系のパッケージシステムにおいては元号か西暦を選択できるようになっているものが多く、改元の際には新元号対応されたプログラムへのバージョンアップが必要になる場合があります。

普段から西暦を選択して使っている事業者にとっては無視して良い話しにはなりますが、元号での表記を使われているところにおいてはパッケージメーカーの対応待ちという状態が発生します。

今回の場合は改元の日付が決まっているものの、今後も同じようになるとは限らず、かつ、元号が発表されるのは改元直前です。

こういった状況にならないようにするには、システム日付はすべて西暦で管理していくことが無難と言えるでしょう。

有償で元号対応をしているパッケージメーカーなどにおいてはもったいない話しかもしれませんが、全体的なことを考えるとその方が得策と思えます。

そうでないのであればユーザー側でメンテナンス可能なものとして提供することが一番良い方法かもしれません。

現在、元号で帳票類を出力している事業者の方、この先は西暦で出力していくことを検討された方が良いかもしれません。

過去に出力したものと見た目が少々変わることで統一感のなさを感じる部分もありますが、どこかで切り替えてしまった方が気にすることが一つ減ることにもなります。