ハードディスクメンテナンス

ハードディスクの診断、物理フォーマット、静音化、Linux、サーバー、MySQLなどがメインだったのですが、その後広がり、カメラやハードウェアの投稿も増えてきました。 モバイルデバイスは、MacBookAir(13型)、iPad Air2、ポメラ DM100(キングジム)OLYMPUS STYLUS XZ-2など。 これらを使いながら、ブログを更新しています。

カテゴリ: サイト制作・管理



大幅に遅れていた、ライブドアブログのHTTPS化だが、

ライブドアブログ

関連:ライブドアブログのHTTPS配信が、マタモヤ延期!

関連:ライブドアブログのHTTPS対応が、「2020年春」から「2020年6月/7月」に延期!

2020年8月24日から利用できるようになった。

関連:サブドメインのブログで、HTTPSを利用できるようになりました (ライブドアブログ)

関連:ライブドアブログのHTTPSの利用について (ライブドアブログ)

HTTPSへの切り替えは、管理画面>ブログ設定 でHTTPS配信を有効にするだけであり、

HTTPS_ライブドアブログ

HTTPからHTTPSへのリダイレクト(https://shattered.blog.jp/https://shattered.blog.jp/)も自動で行われるのだが、

予想されたコトではあるが、Mixed Content(混在コンテンツ)連発でハナシにならない。

関連:Mixed Content(混在コンテンツ) (ライブドアブログ)

管理画面>デザイン設定 から、スタイルシート(CSS)や、雛形にある該当箇所を修正する。

他にも、以下の方法でMixed Contentを探し出す!

関連:Mixed Contentの発生箇所の調べ方 (ライブドアブログ)

しかし、各記事内の該当箇所(特にIMGタグ)が問題。

ライブドアブログの検索はタグは除外のようであり、一斉置換もできない!

アクセスの多い記事(上位30程度)に関しては、手作業で修正したが...

管理画面>ブログの書き出し(エクスポート) でテキストデータで書き出し、エディタで一斉置換、インポートという手順を踏むのがカシコイのかはシラン(SILANE)けど、URLが変わってしまったら、SEO的に意味ナゐデショ!

と思いきや、インポートの設定に「記事のURL形式を引き継ぐ」というのがある!

記事のURL形式を引き継ぐ

関連:他のブログから記事のURLを変えずにインポートする(URL引き継ぎ機能) (ライブドアブログ)

書き出したファイル(MT形式)を見てみると、「PATH: archives/52112456.html」という記述があるが、これがURLである。

@@@@@@@@@@@@@@@

−−−−−−−−
AUTHOR: shattered
TITLE: [中華] Ring of Elysiumの画質設定が追加された件 [無料]
STATUS: Publish
ALLOW COMMENTS: 1
ALLOW PINGS: 0
CONVERT BREAKS: 1
PRIMARY CATEGORY: ゲーム
CATEGORY: ゲーム
CATEGORY:
TAG: Ring,of,Elysium,リング,オブ,エリュシオン
DATE: 08/15/2020 21:00:00
BASENAME: 52112456
PATH: archives/52112456.html
−−−−−

@@@@@@@@@@@@@@@

移行元がライブドアブログの場合、URLを引き継げるので、是を使えば、Mixed Content(混在コンテンツ)を駆逐するコトが可能かはシラン(SILANE)。

ムァ、HTTPのムァムァ長期放置のライブドアブログ、イマサラ手を打ッたトコロで、「時スデに遅シ」や...

GAME OVER

追記:エクスポート→置換(修正)→インポートの手順で、Mixed Contentの駆逐可能を確認!

ブログの引越し(インポート)

インポートの際は、記事ID(PATH)が重複するが、既にある記事を全部消さずにインポートしても無問題(上書きとなり、ダブルにならない)。

インポート時の注意



但し、記事内にMT形式のヘッダ部(上記@@@@@@@@@@@@@@@間)があると、バグるので注意!

エクスポートの時点では出力されているが、インポートすると、誤反応してヘッダ部を含むソレ以降の内容がなくなってしまう。

また、文中に「-----(半角ハイフンの連続)」があると、MT形式の区切りと解してバグる模様。

よって、以後のコトを考えるなら、文中では「−−−−−(全角ハイフン)」にシテオクべきだろう。

インポート時の注意



また、「予約」が「下書き」としてインポートされてしまう問題がある。

当然「下書き」状態だと、未来永劫延々とゐツまで経ッても公開されナゐ!

ページ毎の一括操作は「公開」か「下書き」にしかできないので、1記事ヅツ開いて「予約」にしてユカナケレバならない、このヴァクァ詐加減wwwww

関連:ライブドアブログのHTTPS/SSL化が全く進んでいない件
[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック



ライブドアブログのHTTPS対応が、「2020年春」から「2020年6月/7月」に延期!

・ブログページ(サブドメイン):2020年6月予定
・ブログページ(独自ドメイン):2020年7月予定
・管理画面:2019年11月対応完了

関連:ライブドアブログのHTTPS対応について(続報) (ライブドア)

画像(livedoor.blogimg.jp)のHTTPS化は、2019年11月に完了しているが、問題はその呼び出し方法。

関連:Mixed Content(混在コンテンツ)について (ライブドア)

「記事本文に記載しているURLについては、ライブドアブログのシステムで自動的に、httpからhttpsへ置換処理を行っていますので、ブロガー様での対応は不要です。」とあるが、2019年11月付近より以前の記事だと、IMG SRCがhttp(Sナシ)となってるので、Mixed Contentと判断される?

Mixed Contentと判断されれば、Chrome等で「保護されていない通信」となり、検索エンジン(Google)の評価も下げられてしまう。

IFRAME等も含め、ページに含まれる全てをhttpsにしなければナラナイ!

一斉置換機能が対策は楽だが、ライブドアブログごときに、そのような機能はナゐンで...

ゆぅまでもナゐが、HTTPS非対応のまま長らく放置された結果、検索エンジン(Google)の評価がダダ下がりで取り返しのつかない状況、露出を望む人々はトックの昔に既に去ッてル。

関連:ライブドアブログのHTTPS/SSL化が全く進んでいない件

関連:ライブドアブログのFTPクライアント機能が終了予定

関連:ライブドアブログの有料3プラン無料化のウラにあるモノ

[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック



phpMyAdminを使ってMySQLにアクセスしているなら気付かンカムォだが、TeraTermなどのテキストでアクセスすると、結果が「???」となり文字化けしているコトがある。

MySQL文字化け

phpMyAdminの「サーバの文字セット」はUTF-8になっており、

サーバの文字セット_phpMyAdmin

TeraTermの設定やフォントもUTF-8であるにもカカワラヅだ。

設定_TeraTerm

フォント_TeraTerm

MySQLで

show variables like '%character%' ;

とすると、「character_set_results」が「latin1」になっている。

character_set_results_MySQL

# character_set_results:クライアントへ送信する文字コード

なンで、

set character_set_results = utf8 ;

としてUTF-8にシテヤルと、正常に表示される。

妖虫_冥ゐ

カクニンすると、以下の通り、「character_set_results」が「utf8」に変更されたコトが分かる。

character_set_results=UTF-8

ダレがlatin(ラテン)=ガイジン邪、ドァヴォ!!

他の「latin1」も全部「utf8」に設シタラ/設楽ゑ〜ンかはシラン(SILANE)し、utf8とutf8mb4の違いは何かもシラン(SILANE)。

set character_set_client = utf8 ;
set character_set_connection = utf8 ;
set character_set_database = utf8 ;
set character_set_server = utf8 ;

exitでMySQLを抜けて、MySQLの再起動。

mysql.server restart

再起動すると、ムァタ「latin1」に戻ッてる(文字化け復活)、このヴァクァ詐加減wwwww

だが、phpMyAdminの「その他>変数」でカクニンすると、「latin1」は存在シナイ罠!

サーバ変数と設定値_phpMyAdmin

モ〜(MOW)、ワクェが分からナゐョwwwwwwwwwwwwwww

MySQLの設定ファイル(my.cnf)を探し出し(方法は後述)、

# Default Homebrew MySQL server config
[mysqld]
character-set-server=utf8
[client]
default-character-set=utf8
# Only allow connections from localhost
bind-address = 127.0.0.1

を追記して保存、MySQLを再起動。

MySQLで

show variables like '%character%' ;

で再確認。

utf8_MySQL

再起動してもutf8が残り、成功。

[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック



WordPressで「TARGET="_blank"」付きのリンクを書いて投稿すると、勝手に「rel="noopener noreferrer"」が付加される。

WordPress

その理由は「Tabnabbing」対策なのかな?

関連:リンクのへの rel=noopener 付与による Tabnabbing 対策

サイトAにあるBへのリンク(TARGET="_blank"付き)を開くと別タブでBが開くが、Bを閉じると残るのはAのハヅがCになっているという危険杉流モノである。

BにAをCに変えるような仕掛けが施されている(window.opener.location = http://●●●.com")。

仕掛けがAとは関係ないBにあるので、悪用されると非常に危険。

Aにコメント欄や掲示板がある場合、URLを貼り付けられることがあるだろう。

その場合は「TARGET="_blank"」付きのリンクとして表示するのが普通だが、そのリンク先に上記が仕組まれていると、A閲覧者をCに誘導できてしまう。

この遷移はB表示の際の裏に隠れているので、Cを閉じるまで気付かない。

もし、CがAとソックリな外観であったら...

フォデ、Aがログイン必要なサイトであったら...

一定時間でログアウトされるサイトも多いので、再度ログインを求められても不審には思わないハヅだ。

Aでログインしている利用者がBを開き、Bを閉じた後の画面でログインを求められても、不審に思わヅ入力してしまうだろう。

それがAではなく、C(偽サイト)であったら...(フィッシング詐欺)

てコト。

ヂゃあ、「rel="noopener noreferrer"」て何?となるが、

noopenerは上記の危険性(window.opener.location = http://●●●.com")を防ぐためのモノ。 ← 脆弱性ではない。

noreferrerはその名の通りReferrer(リファラ)を抑止するモノなので、サイト管理者が意図的にリンク先にリファラを渡す際は付けてはならない。

WordPressに勝手に「rel="noopener noreferrer"」が付加されるのを防ぐには、function.phpを変更する。

外観>テーマエディター>functions.php

が、投稿画面のボタンを使わずに手動でタグを書く場合は不可であり、また、自動付加される前の「TARGET="_blank"」を含む記事には付かない。

投稿後に置換プラグインである「Search Regex」で、一斉置換するとよいだろう(既に付加されてしまった過去記事も置換できる)。

リファラは残す場合

Search Regex_noopener_noreferrer

Search pattern(前):rel="noopener noreferrer"
Replace pattern(後):rel="noopener"

「Replace and Save」で一斉置換する前に、「Search」で件数を確認しよう。

件数が多い場合、鯖(サーバー)がパワーがショヴォゐと、エラーで置換できンサカゐ/堺wwwww

その場合は、phpMyAdminでDBにアクセス、REPLACE(カラム名,前,後)でドン!

当然、新規投稿や、置換が済んだ過去記事でも、記事を編集すると、再度付加されてしまう。

キミの任務は、勝手付加機能を探し出し、排除するコトだ(大佐)。


(無料電話サポート付)できるWordPress WordPress Ver. 5.x対応 本格ホームページが簡単に作れる本 (できるシリーズ)
星野邦敏 相澤奏恵 漆原理乃 大胡由紀 清水久美子 清水由規 戸田秀成 山田里江 吉田裕介 できるシリーズ編集部
インプレス (2019-06-14)
売り上げランキング: 2,668



[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック



WordPressのアクセス解析プラグインであるSlimstat Analyticsで、Real-timeを見ても「表示するデータがありません」となり、アクセスが記録されない問題。

表示するデータがありません_Slimstat Analytics

自分のアクセスすら表示されないとはナニゴトか!ドァヴォ!!

てなハナシだが、

Slimstat Analyticsの 設定>General>解析モード と進み、「Client」から「Server」に変更すると出る!

解析モード_Slimstat Analytics

変更後、最下部にある「変更を保存」のクリックを忘れないように。

「解析モード」の説明には、

Select Client if you are using a caching plugin (W3 Total Cache, WP SuperCache, HyperCache, etc).
Slimstat will behave pretty much like Google Analytics, and visitors whose browser doesn't support Javascript will be ignored.
Select Server if you are not using a caching tool on your website, and would like to track every single visit to your site.


ツマリ、キャッシュプラグイン(W3 Total Cache,WP SuperCache,HyperCacheなど)を入れている場合は、「Client」にセヨとのコト。

テクァ、デフォルトで「Client」てコトは、WordPressにキャッシュプラグインが入っているコトが前提?

普通は逆ヤロ/野郎!ドァヴォ!!

試験用のローカル鯖などでキャッシュプラグインを入れていない場合、解析モードが「Client」でもアクセスログが出るコトを確認!

で、公開鯖でキャッシュプラグインが有効の場合でも、「Client」だと記録されヅ、「Server」に変更する記録されるとゐぅ、全く逆の振舞をする事案を確認済!!

ログが出ない場合、もう片方にすればゑ々(二者択一なので)、という、非常にカンタンなハナシであるが、ドウなッとるン邪!ドァヴォ!!

サーバーの問題(WAF,ウェブアプリケーションファイアウォール)がカラむンか?ともウタガッタが、関係ナゐ模様かはシラン(SILANE)。

あと、午前零時を過ぎ、日付が変わった時にも注意!

ページを再表示しても、表示期間が前日のムァムァであるからだ。

表示期間_Slimstat Analytics

意図的に今現在を含む期間にシナイと、直近のアクセスは表示されない。

この程度のコトに気付かナゐのであれば、ソクヅァに本件から手を引き、ドカタ、野球選手、プロレスラー、芸人にでもなるコトをオススメする。

関連:WordPress関連の投稿

関連:Macでサーバー(Apache,PHP,MySQL,WordPress)を作る

関連:[Mac] PHPのバージョンが異なる問題 [HighSierra]

[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック

このページのトップヘ