作者別: higa

 

デジタルドリームワークスからHigaです。
少し前にWordPressでアップロードした「日本語名のファイル」がハッシュ化されて分かりづらいとご意見をいただきました。

例えば…

「テストファイル.jpg」をWordPress メディアにアップロードすると「6b0a0084b22e4c0839192f0a10e010ee.jpg」に変換されます。
制作側としては日本語ファイル名のデータをサーバー上にアップすることに違和感を感じます。
しかしハッシュ化されたファイル名はダウンロードした際に分かりづらく、
また複数ファイルある場合は、ファイル内容を確認しないとわからないということもあります。

調べたところ設定は簡単にできるようですのでメモ。

1. 「WP Multibyte Patch」プラグインの有効化
2. 「WP Multibyte Patch」プラグインのconfigファイルの設置
3. ファイルの設定を編集

という流れです。
1. 「WP Multibyte Patch」プラグインの有効化

まずはプラグインを有効化です。
日本語サイトならもちろん有効化していますよね！
「WP Multibyte Patch」プラグインは日本語環境での不具合や強化をしてくれます。

・文字数カウントの不具合
・検索時のスペース誤認識
・トラックバック/ピンバックの文字化け
・ピンバックの不具合
・メールの文字化け
・ファイル名の日本語部分の変換不具合

ということです。
プラグインんを入れていないことですべての不具合に遭遇したことはありませんが、
日本語ファイルがアップ出来なかったり、抜粋の際に文字数がおかしい等はあったと思います。

またこのプラグインが日本語ファイル名をハッシュ化しているようです。

 

 

2. 「WP Multibyte Patch」プラグインのconfigファイルの設置

「WP Multibyte Patch」プラグインのフォルダ内にある「wpmp-config-sample-ja.php」を「/wp-content/」直下にコピーして「wpmp-config.php」にリネイムします。

 

 

3. ファイルの設定を編集

上記でリネイムした「wpmp-config.php」ファイルを修正します。
ずらずらと設定内容が記述されているので、以下項目を修正。

$wpmp_conf[‘patch_sanitize_file_name’] の値をtrueからfalse
これでOKです。
つまり「WP Multibyte Patch」プラグインの設定を上書きすると日本語ファイル名でそのままアップロードが可能になります。

 

—–
ということでWordPress メディアアップロードをする際に日本語ファイル名でそのままアップロードする方法をメモしました。
ファイル名を日本語にすることはいろんな議論があるようです。

Googleは画像ファイルにも、その画像を説明するようなテキストを使ったほうがいい。と解説しているよ！
SEOの観点からも日本語ファイル名が良いという声は結構あるようです。

そのような話がある中で…

・日本語ファイル名を扱えない検索エンジンやブラウザ、デバイスがあるはず…
・URLコピペの際にはURLを誤認識する可能性や自動でURLがハッシュ化されて長いURLになることも…
・Googleの検索エンジンは日本語ファイル名を認識しているものの、SEOの評価にどれくらい影響を与えているのか疑問…

という意見もあるようです。
日本語ファイルはアップしちゃダメと教えられてきた自分からすると、
一応画像の説明は「alt」で記述できるからね…という思いもあります。
そこよりも、もっと最適化できる部分はあるはず!
さてみなさんはどうでしょうか。
日本語ファイル名でアップを積極的にやりますか？
ご意見頂けると幸いです！

EC-CUBE3 移設の注意点

Digital Dream Works からHigaです。
タイトル通りEC-CUBE3の移設について注意点メモです。

 

1. ファイル、データベースのバックアップ

どの移設でも同じですが、まずはファイルとデータベースのバックアップです。
自分の環境下ではEC-CUBEのキャッシュフォルダーがバックアップ出来ませんでした。
cacheやlogのフォルダ配下はapacheの所有権限の為、パーミッションで弾かれていました。
それで上位権限よりパーミッション変更を行いました。（これが後のさらなるエラーにつながります…）

 

2. 移設するサーバーへファイルとデータベースを設置します。

それではファイルとデータベースを新サーバーへ設置します。
SQLを確認したところSQLデータにはサーバー情報などは入っておらずそのままSQLをアップして問題無いようです。（例えばIP情報やディレクトリ情報など）

 

3. configファイル関係の修正

次にconfigファイル関係の修正です。
/app/config/eccube/ 内に4つのファイルがあります。

config.yml
database.yml
mail.yml
path.yml

各ファイル必要な修正を加えていきます。
データベースのアカウントなどを変更した場合はdatabase.yml
サーバーのディレクトリ環境が変わった場合は、path.ymlなどを修正します。

さてこれから、ちょっとした落とし穴。
このままの状態でサイトにアクセスした際に、自分の環境下ではエラーが起きてサイトが表示されませんでした。
先ほど「1. ファイル、データベースのバックアップ」でバックアップの為に変更したパーミッションが悪さをしているようです。
これまでもいくつかオープンソース系のシステムを触ってきましたが、パーミッションのエラーの場合、書き込み権限を与えてあげれば動いてくれます。
しかしEC-CUBEもしくは、Silexの仕様なのか書き込み権限を与えただけでは上手く動いてくれません。
ちゃんとcacheやlogのフォルダ配下のパーミッションを「apache」に戻してあげます。

 

ということでどうにか移設の確認がとれました。
上手く移設が出来なかった場合、ほとんどがconfigの設定ミスではないかと感じます。
まずはdatabase.ymlやpath.ymlを確認してみましょう。しかし何度見直しても問題ない場合は、パーミッションも合わせて確認すると動くかもしれませんよ。
EC-CUBE3系は公開からもうすぐ2年になります。
しかしまだまだ2系に比べて情報が少なかったり、敷居が高いという感じがします。
自分もEC-CUBEを扱えるようにもっと勉強が必要と感じました。

間違っている情報やもっと簡単に出来るなどありましたらぜひコメントいただけると嬉しいです。
それでは！！

 

デジタルドリームワークスからHigaです。
以前にも投稿したと思いますが、EC-CUBE3ではPHPフレームワーク SymfonyベースのSilexを利用しています。
EC-CUBE2系とは全くの別物で、Silexの知識もある程度理解していないとなかなか作業が難しくなっています。

自分はシステムの修正やカスタマイズを行う場合、変数に格納されている値を確認しながら作業を進めていくことが多いです。
PHPの場合は「print_r()」や「var_dump ()」の関数を利用して変数を確認します。
変数を確認することでページ間でどのような値が引き渡しされているのか、また引き渡しデータが正しいか、など順を追って作業することが出来ます。
しかしEC-CUBEでそれらの関数を利用するとずらずらと長いコード返ってきます。
多分 無限ループのような感じです。注意しましょう！

ではどのように変数を確認するのか…

EC-CUBE3.0.8以降では「dump」という関数が使える仕様になりました。
以下のように利用します。

—————

□ Controllerで利用する場合
dump($app)

□ Twigで利用する場合
{{ dump(app) }}

—————

PHP関数の「var_」を付けないなど若干の違いです。
しかしこれを分かっていないと先ほども記載した通り大変な事になります。
また正確に情報を確認出来ません。

というわけでEC-CUBE3系のdumpについてメモでした。
EC-CUBE3系は機能拡張やカスタマイズをプラグインという形で追加していきます。
かなりハードルが上がっていますが

デジタルドリームワークスからHigaです。
さて気になる記事がありましたのでピックアップ

数ヶ月以内にGoogleはインデックスを分割する。
つまりモバイルファーストインデックスを導入するという記事です。

これまでもモバイルフレンドリーなサイトは検索エンジンの結果に良いとされてきました。
しかしGoogleは検索に使用するためのインデックスを1種類しか持っておらず、
一部の評価に関してはモバイル向けページの情報が用いられているが、基本的にはPC向けのページを基準に検索結果を出しているようです。

しかしモバイルファースト インデックス導入後にはこれが逆転すると噂されています。
モバイルサイトを基準に検索結果を出していくと考えられています。
いよいよモバイルファーストの考えが検索エンジンにも反映されていきますね。

今後制作側に影響はあるのか…

弊社はスマートフォンへ対応したレスポンシブデザインをベースに提案しております。
この考えは変えなくても問題なさそうです。特に大きな影響は無い感じです。
しかし一部注意が必要かもしれません。
特にモバイル向けコンテンツはサイト内容を省略している場合は注意です。

まだ多くの事が憶測のような感じもします。
今後の情報に注目ですね！

参考

Google、モバイルファーストインデックスの導入予定を正式発表。スマホ向けページを検索の評価対象に。SEOへの影響は？

http://web-tan.forum.impressrd.jp/e/2016/11/08/24325

デジタルドリームワークスからHigaです。
WordPressを導入しているサイトはプラグインでAMPページに対応することが出来ます。

https://wordpress.org/plugins/amp/

まずはインストールしてみます。
インストールが済んだら、早速AMPページへアクセスしてみましょう！

導入は簡単ですね。
AMPは文法エラーなどがあると、キャッシュしてくれないのようです。
必ずエラーチェックを行ったようが良いと思います。

エラーのチェックは以下より。
https://search.google.com/search-console/amp

テストで確認したページは問題なさそうです。
特にこだわりがなければ、プラグインを有効化するだけで簡単に導入出来そうです。
書籍を確認するとメニューを入れたり、色々カスタマイズが出来るようなので引き続き勉強していきたいと思います。

デジタルドリームワークスからHigaです。
ホームページでも案内をしておりますが、先週より美浜へ事務所を移転しました。
今後ともどうぞよろしくお願い致します。

どの業界でも同じことと思いますが、Web業界も技術進歩が凄まじく早く、日々さまざまな事を吸収していかなければいけません。
その1つとしてAMPがあげられると思います。
以前のブログにも下調べとして投稿しましたが、弊社でもこれから本格的に導入してきます。

デジタルドリームワークスからHigaです。
PLESKなどのGUIコントロールパネルが用意されているサーバーは便利ですね。
PHPバージョンを簡単に上げられなかったりもしますが…

今回はそんなPLESKでハマった点をメモです。
PLESK10以降では仕様の変更によりサブミッションポートはTLS接続を行わないとメール送信が出来ない仕様になっています。
もちろん暗号化通信を行うことが一番ですが、どうしてもお客様の環境によりTLS接続が困難な場合などは、セキュリティーレベルを下げないといけない場面があります。
そんな場合には以下を参考に作業を行います。

設定ファイル
—————————————————–
/etc/postfix/master.cf
—————————————————–

▼変更箇所
—————————————————–
「submission」の設定で記述されている、「smtpd_tls_security_level」パラメータの値を「encrypt」から「may」に変更

○初期の記述
smtpd_tls_security_level=encrypt

○変更後の記述
smtpd_tls_security_level=may

—————————————————–
変更後例：
submission inet n – n – – smtpd -o smtpd_enforce_tls=yes -o smtpd_tls_security_level=may -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_sender_restrictions=
—————————————————–

という感じです。
これはPostfixとPleskの組み合わせで起こることでその他の組み合わせ、例えばQmailとPleskの環境では問題ありません。
弊社でもいくつかサーバーを管理しておりますが、環境により設定が異なるので時々 頭がパンクしそうになります。

またサーバーを疑う前にお客様のメール設定に問題がある場合も多いです。
まずはお客様のメール設定を確認することから始めるのが鉄則です。

それでは！

Digital Dream WorksからHigaです。
業務でWordPressの移設をすることがしばしばあるので、よく忘れてしまうDB文字セットについてメモしておきます。

WordPress移設の際、 SQLデータをインポートすると「Unknown collation: ‘utf8mb4_unicode_ci’」ということでDB移設ができない場合があります。
これはWordPress4.2よりデフォルトのデータベースの文字セットがutf8からutf8mb4に変更されたことがひとつの原因です。

utf8：1文字を3バイトで構成
utf8mb4：utf8の拡張版のようなもの（1文字を4バイトで構成、今までの文字に追加の文字セットが使える）

ということで、utf8mb4はutf8の拡張版で絵文字などの文字が追加されているようです。
WordPressの推奨とあってWordPressのアップデートの際に以下の条件がそろっていると自動で「utf8mb4_unicode_ci」に変更されるようです。

・現在utf8の文字セットが設定されている
・使用しているMySQLサーバーのバージョンが5.5.3もしくはそれ以上
・使用しているMySQLのクライアントライブラリーが5.5.3もしくはそれ以上の場合、又はmysqlndを使用している場合は5.0.9かそれ以上の場合

照会順序はいつも「utf8_general_ci」にしてるけどな…って思ったらそういうことでした。

さて移設先の環境がどうしても「utf8mb4_unicode_ci」を利用できないこともあります。
その際にはSQLを修正してあげる必要があります。

SQL文で直接置換する方法などもあるようですが、
自分はphpMyAdminなどを利用して SQL文エクスポート、修正、インポートする方法で変更を行ないます。
SQLデータのバックアップがテキストで出力されるのは、何となく安心出来ます。

1. SQL文をエクスポートしてバックアップ
2. テキストエディタで開いて、「utf8mb4_unicode_ci」を「utf8_general_ci」に置換
3. 「utf8mb4」を「utf8」に置換
4. wp-config.php内にあるcharsetの文字コードを確認して「utf8mb4」なら「utf8」に書き換え
5. それぞれをインポート、アップで完了

ざっくりと書きましたが、この手順はGoogleで検索すればたくさんの記事がありますので参考にして下さい。
というわけセキュリティー的にも出来るだけMySQLもアップデートしていくことがベストですが、
サーバー環境（PLESK等）や他システムの兼ね合いでどうしてもMySQLのバージョンがあげられないサーバーへの移設はこの方法で回避できます。

稼働中サーバーのMySQLのバージョンアップなどは怖くて気が引けます。
自分が会社に入りたての頃は依存関係などでサーバー全体がおかしくなったりと大変だったような覚えがあります。
今ではある程度安心して MySQLやPHPなどのアップデートは行えるのでしょうか…
ご意見などコメントいただけると幸いです m(_ _)m
それでは！

デジタルドリームワークスからHigaです。
今日はSVGを少し触れていきたいと思います。

SVGとは…

XMLベースの、2次元ベクターイメージ用の画像形式の1つである。アニメーションやユーザインタラクションもサポートしている。SVGの仕様はW3Cによって開発され、オープン標準として勧告されている。

とwikipediaで説明されています。
つまり画像をxmlで描写することが出来るというものです。
ベクター形式として描写されるので拡大しても画像が荒れないことやアニメよーションにも対応。Javascriptとの連携も出来ます。

さっくりとSVGのテストを行ってみました。
以下DDWの文字が書きなぞるように表示されていますか。
このように動きのある表現が出来ます。

これまでほとんどSVGは利用して来なかったのですが、表現の幅を広げる為にも習得していきたいと思います。
今回は触りくらいしか確認出来ていませんが、さらにSVGの知識を深めていきたいと思います。
それでは！