Scrapdiary

DesigningとEngineeringの架け橋

Wordpressの更新で「ダウンロードに失敗しました。:ファイルのチェックサムが期待値と一致しません。」のエラー

Wordpressを4.8にアップグレードを行おうとGUIから実行するも

https://downloads.wordpress.org/release/ja/wordpress-4.8.zip から更新をダウンロードしています…

ダウンロードに失敗しました。: ファイルのチェックサム (6c0797eea5561cdaa9b4edc75ba296dd) が期待値 (d95fd389479bf85939e0b36d9ae1d1a4) と一致しません。

インストール失敗

と表示されてしまい、何度実行しても更新がインストールされません。

Permissionかと考えwp-contents以下のディレクトリを調整しましたが、いっこうに改善されませんでした。

仕方ないので、coreのソースファイルを読んでみると以下の箇所で発生していました。 

github.com

チェックサムのエラーはこの「verify_file_md5()」という関数で出力されています。
それを呼び出している「download_url()」の$responseにて、実際にダウンロードしたファイルのチェックサムと比較するための「期待値」を受け取っています。

検証してみると、Wordpressダウンロードサイトhttps://downloads.wordpress.org)にて該当するZIPファイルをGETで取得する際のheader情報に「Content-MD5」というプロパティがあり、それを「期待値」とする仕様のようです。

wgetコマンドでheader情報を取得してると

$ wget -S --spider https://downloads.wordpress.org/release/ja/wordpress-4.8.zip
Spider mode enabled. Check if remote file exists.
--2017-07-26 11:00:39-- https://downloads.wordpress.org/release/ja/wordpress-4.8.zip
Resolving downloads.wordpress.org... 66.155.40.186, 66.155.40.187, 66.155.40.188, ...
Connecting to downloads.wordpress.org|66.155.40.186|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 26 Jul 2017 02:00:40 GMT
Content-Type: application/zip
Content-Length: 9436096
Connection: keep-alive
Cache-control: private
Content-Disposition: attachment; filename=wordpress-4.8-ja.zip
Last-Modified: Fri, 23 Jun 2017 02:03:03 GMT
X-Frame-Options: SAMEORIGIN
Content-MD5: d95fd389479bf85939e0b36d9ae1d1a4
X-nc: EXPIRED lax 186
Accept-Ranges: bytes
Length: 9436096 (9.0M) [application/zip]
Remote file exists.

「Content-MD5: d95fd389479bf85939e0b36d9ae1d1a4」が渡ってきます。
ですが、この値がWordpressが稼働するサーバ上で実際にダウンロードしたファイルに対してmd5_file()を実行して生成したチェックサム値と一致しません。

「Content-Length: 9436096」と「Length: 9436096 (9.0M) [application/zip]」とheaderは伝えているのだけど、実際にダウンロードされたファイルのサイズをfilesize()でチェックすると「2060288」(1.9M)なので、GETリクエストしているファイルと実際にダウするファイルが違っているように見受けられる。

これってWordpress側のheader情報が間違っているように感じるのだけれど、特に「4.8にアップロードできない」という声を聞かないので自分の環境特有の問題なんだろうか…。

 

調べてみたけど解決策がなくて困ったというお話でした。

 

パーフェクトPHP (PERFECT SERIES 3)

パーフェクトPHP (PERFECT SERIES 3)

 

CKEditorをCDNから利用する時のカスタマイズ方法

WebでWYSIWYGなエディタで使いやすいいCKEdiotorですが、サクッと導入したい時にファイル一式をホストするよりCDN経由で読み込む方が圧倒的に楽です。

CKEditorの特長の一つにカスタマイズのしやすさがあります。公式サイトでもツールを公開していますので、取捨選択・レイアウトも楽です。

Toolbar Configurator

利用サイトに自前でホストする場合はckeditor/config.jsを編集してカスタマイズするのですが、CDN経由の場合のエディタカスタマイズ方法が分からず、いろいろ解説サイトやドキュメントを(さっと)見たのですがすぐにわかりませんでした。

結果としてはCDN経由ではconfig.jsをCKEditorに明示的に指定してあげる必要があるようです。以下のサイトでCDN経由で利用する場合の注意点が書いてありました。

CKEditor CDN

CKEditor本体の読込み

CKEditor CDN setup

上記をhead内に記載し、エディタを適用したい要素にclass名で「ckeditor」と指定するか、別途scriptタグで置換します。注意点としては、このCKEditor.replace();はエディタを指定した要素より後に書く必要があります。

config.jsの指定

CKEditor customConfig setting

config.jsを指定するためのcustomConfigパラメータにファイルのパスを設定します。これもエディタを指定した要素より後に書かないと機能しません。

後は指定したconfig.jsを作成しカスタマイズを行うことでお好みのエディタの利用が可能になります。

カスタマイズ例

CKEditor customized example : 'config.js'

編集用の要素を絞ったのと、エディタ内でCSSやstyleを使えるようにする「config.allowedContent = true;」を追記しました。外部や不特定多数の利用が想定される場合にはこの設定をするとXSSなどのセキュリティリスクが高めてしまうので、利用には注意が必要です。タグの利用には個別の設定も可能なようなので、上記のようなケースでは「config.extraAllowedContent」で制御するべきとのことでした。

blog2.gods.holy.jp

Adobe Creative Cloudが正常に稼働しなくなった場合の対処方法

今まで5年ほどCreative Cloudを使っていますが、ログアウト出来なかったり、「App」の項目が表示されず各アプリのアップグレードができなかったりすることが多々ありました。どうやらアプリをアップグレード中に通信の切断が発生するとレジュームが出来ずに操作不能に陥るようです。

その際Creative Cloudを何度再起動してもダメだったので、Adobeのサポートの方に相談して解決方法を教示いただきましたので、再発の際の備忘録としてまとめます。

1. Creative Cloudアプリケーションの終了

Creative Cloudアプリケーションを開いて画面右上の歯車のマークをクリックし、環境設定>ログアウトのち再度歯車マークをクリックして「終了」を選択します。
終了がクリックできない場合は、アクティビティモニタを起動して「Creative Cloud」と「CoreSync」を選択し終了させます。

2. アンインストールの実行

以下ページのツールをダウンロードし、実行してCreative Cloudをアンインストールします。

helpx.adobe.com

3. 設定ファイル・キャッシュファイルの削除

3-1. ~/Library/の中

デスクトップのなにもないところをクリックし画面上部メニューバー、アップルマークの右側が「Finder」となっていることを確認してメニューバー中央あたりにある「移動」をクリックしOptionキーを押しっぱなしにすると「ライブラリ」という項目が出て来ますのでそちらをクリックします。

  • ~/Library/Application Support/Adobe/OOBE/opm.db ファイルを削除します。
  • ~/Library/Application Support/Adobe/AAMUpdater/1.0 フォルダを削除します。

3-2. /Library/の中

再度デスクトップのなにもないところをクリックし、「移動」をクリックして「コンピューター」を開きます。

  • /Library/Application Support/Adobe/OOBE というフォルダを OOBE.old と名前の変更をします。
  • /Library/Application Support/Adobe/SLCache フォルダを開き中にあるファイルを削除します。

4. Adobe Application Manager設定ファイルの削除

アプリケーションフォルダを開いて、ユーティリティも開き「Adobe Application Manager」というフォルダを削除します。

5. Adobe Application Managerの再インストール

以下ページのアプリケーションをダウンロードして実行し、インストールします。

Adobe - Adobe Application Manager:For Mac:Adobe Application Manager

6. Creative Cloudの再インストール

以下ページのアプリケーションをダウンロードして実行し、インストールします。

creative.adobe.com

一旦上記を実行しCreative Cloudが正常に機能するか確認します。

 

このような回答テンプレートを用意しているということは、サポートの方も問題を認識しているのかと思われます。高額なsubscriptionを組んでいますので、このようなことをせずに普通にアプリが使えて、最新版にアップグレードできるようAdobeさんには品質改善していただきいたいです。

Adobe製品はアップグレードするごとに「重く」なりクラッシュなどの「不具合」が多くなってくる印象があります。新機能やCloud連携など素晴らしい部分も多々あるのですが、バージョンすることで「基本的なところがしっかり動く(It just work.)」ことを大切にして欲しいです。

【EC-CUBE 2.13】購入後などにメールが送信されない場合の対策

EC-CUBEからメールが送られてこない場合の対応について備忘録。基本的な対策はこちらのエントリーを参考にしました。

バージョンが2.13に上がって設定等が微妙に変わってますので補足・補完。
インストール時に設定した「WEBサーバ設定」のオプション設定の「メールサーバー設定」>「メーラーバックエンド」の値は ~/data/config/config.php に移動しています。

もしsendmailを選んでいたら、稼働させているサーバのsendmailのパスを「which sendmail」などで調べ、パスがEC-CUBEデフォルトと違っていたらカスタマイズします。

自分が検証していたバージョン・環境では継承するfunctionで親のparent:: getBackendParamsに引数$backendを渡すとうまくいきました。

 

sendmailのパスは定数化して管理画面の「システム設定」>「パラメータ設定」で設定できるようにして欲しいですね。

 

涙の手紙【ハーレクイン文庫版】

涙の手紙【ハーレクイン文庫版】

 

 

【EC-CUBE 2.13】 支払い方法未選択で購入できてしまう時のテンプレートでの対処法

ダウンロード商品を購入する場合のプロセスの中で「支払い方法」を選ぶステップにて、支払い方法を選ばず(ラジオボタンをチェックせず)に次に進めてしまうみたいです。

コアclassを修正するのもいいんですが、マイナーバージョンアップでのマージが大変そうなのでそれは避けたい。class_extendsの機構を使うのも考えたのだけど、構造的に面倒そうだったのでテンプレートで対応する方法を考えました。 

~/data/Smarty/templates/default/shopping/payment.tplの184行目あたりにて、選択済みのセッション値がなく、ループでfirstだったら初期値としてchecked="checked"が入る形に。

テンプレート自体もバージョンアップで変わるから、あまり意味ないかもしれませんが独自テンプレートで実装すればそのままいけるかと思います。

 

EC-CUBE軽くを検証していてますが、結構「おや?」なところがあって、それが仕様なのか不具合なのか判断が難しいですね。

 

激落ち キューブ 36P

激落ち キューブ 36P

 

Amazonで注文した商品が配送されなかったらサポートに連絡しよう、きっと解決してくれるさ。

久しぶりにCDでも聞いてみようと2枚ほどAmazonで買ったのだけど、お届け予定日の今日午前中に「配送完了」とステータスが変わっていたので、勇んでポストに取りにったら商品届いないじゃないですか。JPどうなってるのよ?と思ったけど配送業者へ問い合わせる窓口がないので仕方なくAamzonのサポートに電話してみる。

日本でのお問い合わせ先
急ぎの場合は「0120-999-373」ですね。

電話は待たされることなくすぐに繋がり、注文番号ともろもろの個人認証情報を聞かれてから処理。うむ、これがちょっと前に話題になったソーシャルハックの件かな、などと思いながら回答。「配送完了とアカウントサービスで表示されているに、商品が届いてないです」と伝えると「Amazon側では配送したことになっているので、その状況であれば再配送します」と即対応。ちょっと心配になるくらい。値段が2,000円もしない額なのでいいのかもしれないけど、高額商品の場合はどうなんだろう?と思ってみたり。「配達の件、詳細を調査いたしますか?」とサポートの方に聞かれたので、どんな対応がされるのか気になったので「では参考までに」とお願いしておきました。

すったもんだで発覚から2時間くらいあれこれして、やれやれと思って昼食に出る際にもう一度ポストを見たら、商品が入ってるじゃない。なんなのこの時差は?再配送をキャンセルして、サポートにメールで商品が届いた旨を連絡して一件落着。

と思ったら夕方になってJPの配達員の方がやってこられ、「商品届いてないそうですが・・・」と調査にいらっしゃいました。こちらの事情を説明してご納得していただき、「なぜこのようなことになってるのでしょうか?もしかして配達前に「ステータス変更」処理してませんか?」と逆に質問してみました。どうやら図星、困ったものだ。「この地区の配達員が端末(投函・引渡したらピピッっと処理するハンディスキャナ的な機器ですね)を持ち歩いてないから」と言っていましたが、だったら配達終わってから一括で処理すれば変なタイムラグが発生しなくていいのに。

今日はこれを聞いて仕事してます。
ジュブナイル』と『ミサイル』がぐっとくる。いいなぁー。

Text WranglerのCommand-Line Toolsをインストール

MacでDiffとMergeが同時に綺麗に出来るアプリがなかなかないので重宝してたText Wrangler。OSの再インストールに際し、環境を再構築する時にハマったのでメモ。

単体版

ダウンロードはここから
http://www.barebones.com/products/textwrangler/download.html

本体をインストールを後、メニューから「Install Command Line Tools...」を選択しインストールを実行します。

何が問題だったのか

本体をインストール後にCommand-Line Toolsのインストールパッケージを実行します。
以前と同じように /usr/bin/ 以下に入ると思いきや /usr/loca/bin/ にそれぞれのバイナリが入ります。

これに気づかずに「インストールしたはずなのにない・・・」と勘違いはなはだしい状態が続きました。
単体版でインストールしててわからなくて、パッケージで出る注意書きで気がつけた。

Dreamweaverで指定するときは /usr/local/bin/twdiff を環境設定から指定しましょう。