EC-CUBE without freetype2

なんか色々納得いかないなぁと思いつつ、とりあえず自分でソース書いてみた。

/data/page_extends/admin/total/LC_Page_Admin_Total_Ex.php

function init() {
parent::init();
  // ここから追記
  // GDライブラリのインストール判定をより強固に
  if($this->install_GD)
  {
    // FreeTypeが入っていない場合、$this->install_GDをFALSEにする
    $gd_info = gd_info();
    $this->install_GD = $gd_info["FreeType Support"] ? true : false;
  }
  // ここまで追記
}

何が言いたいかというと、
なんでGDライブラリが入っているかどうかのチェックはしているのに
freetypeが入っているかどうかのチェックは行っていないのか、ということ。

おかげで、「GDが入っていてもfreetypeが入っていない」環境で統計を開こうとしても
freetype系の処理がエラーになる。

そのくせ、GDが入ってない環境ならエラーにならない(はず)。

というかそもそも「必須PHPライブラリ」って書かれているのに
インストール時にチェックされないよね。。。。。
wordpressだっけ、インストール時にきっちりチェックしてくれるの。
ああいう感じにしたらいいのに。

おかげで何が悪いのか調べるのに結構な時間を要した。

これってどうなの!
…と言いつつ、今は忙しいから開発コミュニティに情報を投げたりしないんだが。
忙しくなくなったら投げるでしょう。きっと。

EC-CUBEを実際に最新版にしてみた

前回の記事を踏まえて、実作業。
コピーした環境で上げるので、バックアップについては省略します。

【2.12.1→2.12.2】
ファイル数はそんなに多くなかったので、そこまで手間ではなかった。
5〜10分くらいですかね。

動作試験してみると、2.12.3に少し近い感じがするというか、
2.12.2では直っていない不具合が改善されていたりする。

リリース版よりも少しだけ2.12.3に近い、といった所ですかね。

【2.12.2→2.12.3】
ファイル数が多すぎて、30分以上かかったでしょうか…。
テンプレートなどの書き換えをしないように留意して作業しないとなので
かなり気を遣って作業しました。

それにしても、全部手動でマージは手間ですね。
何かスクリプト書いて一括で…ってできたら楽なんでしょうけど。
スクリプトを書く気力もないので、とりあえずやめておきました。

こちらはリリース版の2.12.3と全く同じ感じですが、
いかんせん、とにかく膨大なファイル量だったので
「こんなに頑張ってやる価値あるんだろうか」と少し思いました。

そして、何故か管理画面の売上集計機能でエラーが出た。
2.12.2と2.12.3では出ないのに、2.12.2→2.12.3ではエラーが出るという事は
何かが悪いんだろうけど、ソースの比較をしまくってもわからなかった。

とりあえず、/data/class/pages/admin/total/LC_Page_Admin_Total.phpだけ
2.12.2に戻したら動いたので、それで良いや、ということにした。

あ、どちらのアップデートにも言える事ですが、
独自改修している場合は、当該部分には相当気を遣う必要がありますね。
/data/class_extends内に独自改修していたとしても
class内の元ファイルが更新されているから動作しなくなった、という事は
十分に考えられるので、独自改修していた部分は入念に動作試験したほうが
良い、という事ですかね。
…ついでに、2.12.3の更新ではclass_extends内のファイルも更新対象になっているので
独自改修自体を上書きしてしまわないように、とかですか。

とりあえず、疲れたので今回はここで終了で…。

EC-CUBE 2.12系のマイナーバージョンアップ

※実際にこの手順で作業して失敗しても当方は責任を負えませんのでご了承下さい。

EC-CUBE2.12系について私的メモ。

私はあまり今までEC-CUBEに携わってこなかったので、基礎知識が全くないんです。
で、マイナーバージョンアップについての記載がほとんどないので、
「実際何が修正されてるの?」「で、上書きするだけでいいの?」とかが
情報が少ないこともあり、わからなさすぎて困ったわけで。

が、現状で実際に2.12.1 & 2.12.2の管理画面等で不具合に遭遇したりして、不便を感じる。
さっさと2.12.3に上げてしまいたい…。

でも開発コミュニティ内では何やら難しい事が書かれている。
そもそも「難しそう」というか、「じゃあどうすればいいのさ」の答えがどこにもなかった。
ので、面倒だと思いつつ、いろいろ調べてみた。

EC-CUBEのダウンロードページ下部より抜粋
http://www.ec-cube.net/download/

EC-CUBE のバージョン番号は aa.bb や aa.bb.cc の形式になります。
「aa」 は、設計思想を含めた大幅なバージョンアップで更新されます。

「bb」 は、機能追加を伴うバージョンアップで更新されます。
(データベース構成やテンプレートファイルの変更を伴います。)

「cc」 は、バグフィックス等の機能追加を伴わないバージョンアップで更新されます。
(データベース構成やテンプレートファイルの変更は基本的に実施されません。)

ということは、マイナーバージョンアップは基本的にファイル上書きするだけじゃん。
なんだったんだよあの思わせぶりな書き込みは…と思いつつ、それでも不安だったので
もう少し掘り下げて調べてみた。

【2.12.1→2.12.2】

更新ファイル
http://www.ec-cube.net/download/からダウンロードできる
修正概要(開発trac内)
http://svn.ec-cube.net/open_trac/query?status=closed&group=resolution&milestone=EC-CUBE2.12.2
修正詳細(開発trac内)
http://svn.ec-cube.net/open_trac/changeset?old_path=%2Fbranches%2Fversion-2_12-dev&old=21959&new_path=%2Fbranches%2Fversion-2_12-dev&new=22009

…詳細を流し読みした限りでは、typo修正などの小さめの修正が多めのようですね。
念のために2.12.1と2.12.2で/html/install/sql/create_table_mysql.sqlを比べてみましたが
全く同じ内容だったので、DBに変更がないのも確認できました。
/data/Smarty/templates内の各種ファイルは運用中のものを上書きしないように気をつけないといけないですが、
それ以外は普通に上書きして問題なさそうですね。

何かあってからでは困るから、ちゃんと手順を踏む!という事で作業手順を考えてみますと、
1.EC-CUBEで使用しているデータベースと全ファイルをバックアップする
2.更新ファイル内のdataフォルダ内の各ファイルをマージする
3.動作試験を行う
…という感じでしょうか。
正直データベースはバックアップ取る必要あるんだろうかとも思いましたが、
何かあった際に2.12.1に戻せる、という状態を作っておく事が肝要なので
実際に作業するとしたら、こんな感じになるでしょう。

留意点としては、2.12.1内で独自で改修した部分があれば、それを上書きしてしまわないように
別途注意が必要、というところでしょうか。

※後日、実作業するので何かあれば追記します

【2.12.2→2.12.3】

更新ファイル
http://www.ec-cube.net/download/からダウンロードできる
修正概要(開発tracのチケット)
http://svn.ec-cube.net/open_trac/query?status=closed&group=resolution&milestone=EC-CUBE2.12.3
修正詳細(開発trac内)
http://svn.ec-cube.net/open_trac/changeset?old_path=%2Ftags%2Feccube-2.12.2&old=22013&new_path=%2Ftags%2Feccube-2.12.3&new=22513

こちらは詳細が読みにくいですね…。
色々見てみた限りでは、開発中に年を越した都合でCopyright更新があり、
多めのファイル更新になっているようです。
が、他もそこまで重度の更新はないように見えます。

こちらも念のために2.12.2と2.12.3で/html/install/sql/create_table_mysql.sqlを比べてみましたが
全く同じ内容だったので、DBに変更がないのも確認できました。

ということで、こちらも2.12.1→2.12.2同様、運用中のテンプレート上書きや独自改修部分の上書きに
気をつけて手動マージで問題なさそうです。

1.EC-CUBEで使用しているデータベースと全ファイルをバックアップする
2.更新ファイル内のdataフォルダ内とhtmlフォルダ内の各ファイルをマージする
3.動作試験を行う

ですかね。
まぁ、細かい事を言うならば/html/installフォルダとかは入れる必要ないと思いますが。

※後日、実作業するので何かあれば追記します
2.12.1→2.12.2→2.12.3と、2.12.2→2.12.3と、2.12.3の3本で動作比較する予定です

macでPHP開発環境構築 おまけ(apache編)

Homebrewでapacheを入れたは良いが、virtualhost系で困ったので追記。

eclipseのworkspaceはDocument内。
ということで、例えばexample.comの公開ディレクトリを
/Users/XXXXXX/Documents/workspace/YYYYYYYYYYYY/trunk
にしたかったんだけど。

パーミッションの関連でうまく動いてくれない。
かといって、パーミッション側をいじるのも面倒。

ということで、httpd.confをいじって回避することにした。
apacheを動かすUserとGroupを
User XXXXXX
Group Staff
としてやった。

これで見れるので、とりあえず良しとしようかと。
また何か問題が出たら、そのときに考えようと思う。
その時はeclipseのワークスペース設置箇所から変更だな。

macでPHP開発環境構築 完結編

やっとこさ、実用レベルのPHPが入れられそうなので。

ここまでの経緯は、macでPHP開発環境の構築macでPHP環境構築の続き。を参照。

2013/4/3段階の最新版のPHPは5.4.13と5.3.23。
php-buildには記述がないバージョンなので、それぞれ記述する。

/usr/local/share/php-build/definitions/5.4.13

install_package “http://php.net/distributions/php-5.4.13.tar.bz2”
install_pyrus
install_xdebug_master

/usr/local/share/php-build/definitions/5.3.23

install_package “http://php.net/distributions/php-5.3.23.tar.bz2”
install_pyrus
install_xdebug_master

こんな感じ。
いずれはここからPHP5.1.6と5.2.17も入れたいが、とりあえず今は5.3系と5.4系だけで。

さて、ここで少し脱線。
EC-CUBEを入れる前提でやっているのだが、このまま入れるとPHPからfreetype2が使えない。
freetype2自体はXCodeにも入ってるみたいだけど、何か変更があると嫌なのでHomebrewで入れて、
そこにパスを通してPHPのconfigureを構築しようと思う。

XCodeで入れるって人はここを省略して下へ…。

freetype2をHomebrewで入れる方法はこちらを参照。

/usr/local/Library/Formula/freetype2.rb

require 'formula'

class Freetype2 <Formula
  url 'http://sourceforge.net/projects/freetype/files/freetype2/2.4.4/freetype-2.4.4.tar.gz/download'
  homepage 'http://freetype.sourceforge.net/index2.html'
  md5 '9273efacffb683483e58a9e113efae9f'
  version '2.4.4'

  # depends_on 'cmake'

  def install
    system "./configure", "--disable-debug", "--disable-dependency-tracking",
                          "--prefix=#{prefix}"
    # system "cmake . #{std_cmake_parameters}"
    system "make install"
  end
end

上記を設置してから、

brew install freetype2

で完了。
次はPHPのconfigureを書きます。

/usr/local/share/php-build/default_configure_options

–without-pear
–with-gd
–enable-sockets
–with-jpeg-dir=/usr
–with-png-dir=/usr
–enable-exif
–enable-zip
–with-zlib
–with-zlib-dir=/usr
–with-kerberos
–with-openssl
–with-mcrypt=/usr
–enable-soap
–enable-xmlreader
–with-xsl
–enable-ftp
–enable-cgi
–with-curl=/usr
–with-tidy
–with-xmlrpc
–enable-sysvsem
–enable-sysvshm
–enable-shmop
–with-mysql=mysqlnd
–with-mysqli=mysqlnd
–with-pdo-mysql=mysqlnd
–with-pdo-sqlite
–enable-pcntl
–with-readline
–enable-mbstring
–disable-debug
–with-apxs2=/usr/local/sbin/apxs
–with-freetype-dir=/usr/local/include/freetype2

うちの場合はこんな感じ。
freetype2をXCodeのものを使う場合は、最終行が

–with-freetype-dir=/opt/X11/include/freetype2

って感じになるのではないかと。

実際に追記したのは下の2行だけなので、他は必要があれば書き換える感じですかね。

ではインストール。
PHP5.4.13から。

php-build 5.4.13 ~/.phpenv/versions/5.4.13
mv /usr/local/Cellar/httpd/2.2.23/libexec/libphp5.so ~/.phpenv/versions/5.4.13

これでOK。
続いてPHP5.3.23。

php-build 5.3.23 ~/.phpenv/versions/5.3.23
mv /usr/local/Cellar/httpd/2.2.23/libexec/libphp5.so ~/.phpenv/versions/5.3.23

これでOK。
phpenv versionsでちゃんと入ってるか確認して、
phpenv global 5.4.13とかやってCLI側を切り替えて、
php -vでCLI側のバージョン切り替わるか確認して、
phpenv apache-version 5.4.13とかやってapache側を切り替えて、
phpinfo.phpとか作ってapache側のバージョン切り替わるか確認して。

…確認作業についてはサラっと流しました。
細かい確認としては、phpinfoを見る時にGD内のFreeType Support欄があるかどうか、ですかね。

やっとここまで来ました…。
apacheの設定とかも必要ですが、とりあえずPHPに関しては相当カスタマイズできる環境ができたので
うれしい限りです。

なにせ、同じPHPのバージョンでもconfigure optionを変えた版、とかも作って置いておけますしね。
phpenv + php-build、最高です。

macでPHP環境構築の続き。

以前の記述の追加で。

こことかこことかここを参考にさせて頂いて、macで複数バージョンのPHPを入れるということでがんばってみた。

◆事前準備

brew tap Homebrew/dupes
brew tap josegonzalez/php

◆ついでなのでapacheもbrewから入れておく

brew install httpd

うちの環境ではhttpd.confは/usr/local/etc/apache2/httpd.confにありました。

◆phpenv

brew install –HEAD phpenv

その後、.bashrcに

# phpenv
export PATH=”$HOME/.phpenv/bin:$PATH”
eval “$(phpenv init -)”

と追記して、

source ~/.bashrc

と叩いて読み込み直しして完了、だと思う。

◆php-build

brew install php-build

# php-buildのPATHを追加

$ vi ~/.bashrc
export PATH=/usr/local/bin:$PATH
# 設定したPATHの設定を有効にする
$ source ~/.bashrc

上記を入れて、その後php-buildから各バージョンのPHPを入れる。

php-build X.X.X ~/.phpenv/versions/X.X.X
mv (生成したlibphp5.soのパス) ~/.phpenv/versions/X.X.X

っていう感じで。

php-build –definitions
で出てくるリストは、
/usr/local/share/php-build/definitions
内に追記すれば自分で追加できる。
最新のものとか、ベータ版とか入れる時には自分でここに入れると良いかも。

で、最終的にいろいろやってインストールできたら、

phpenv versions

でインストールされているものが確認できて、

phpenv global X.X.X

でCLI側のPHPが切り替えできる。
CLI側で使用しているPHPのバージョンを調べるのは簡単で、

php -v

って叩けば出てきてくれる。

けど、apache側は上記では切り替えできないので、それ用のスクリプトを用意する。

~/.phpenv/libexec/rbenv-apache-version

#!/usr/bin/env bash

set -e
[ -n "$RBENV_DEBUG" ] && set -x
# Provide rbenv completions
if [ "$1" = "--complete" ]; then
  echo system
  exec rbenv-versions --bare
fi
RBENV_VERSION="$1"
RBENV_ON_FILE="${RBENV_ROOT}/versions"
APACHE_ROOT="/usr/local/Cellar/httpd/2.2.22"
APACHE_MODULE_PATH="${APACHE_ROOT}/libexec"
# Make sure the specified version is installed.
RBENV_PREFIX_PATH="${RBENV_ROOT}/versions/${RBENV_VERSION}"
if [ ! -d "$RBENV_PREFIX_PATH" ]; then
  echo "rbenv: version \`${RBENV_VERSION}' not installed" >&2
  exit 1
fi
PHP_MODULE_PATH="$RBENV_PREFIX_PATH/libphp5.so"
if [ ! -f "$PHP_MODULE_PATH" ]; then
  echo "apache module not found \'${PHP_MODULE_PATH}'" >&2
  exit 1
fi
if [ ! -d "$APACHE_MODULE_PATH" ]; then
  echo "Directory not found \'${APACHE_MODULE_PATH}'" >&2
  exit 1
fi
echo "copy ${PHP_MODULE_PATH} to ${APACHE_MODULE_PATH}"
cp "$PHP_MODULE_PATH" "$APACHE_MODULE_PATH"
echo "Restarting apache..."
sudo apachectl restart

上記ファイル生成後、

chmod 755 /Users/***/.phpenv/libexec/rbenv-apache-version

で実行権限をつけてやる。
上記が終われば、
phpenv apache-version X.X.X
でapache側のPHPが切り替えできる。
apacheの再起動がかかるのと、sudoするからパスワードを聞かれることがあるのはお忘れなく。

とりあえず、入れられること、切り替えができることまでは確認できたので
本当に入れたいバージョンやら、入れたいオプションやらを追求して
改めて開発環境が整うのは…いつだろw

PHP5.4とec-cube

ec-cubeはPHP5.4系を意識した修正は行われていないなぁ、という事で。

エラーレベルの話。
PHP5.4.0からはE_ALLにE_STRICTが含まれるようになっている。
ということで、管理画面の統計など、ちょっとしたタイミングでエラーが出てくる。

/data/class/SC_Initial.php内には

function setErrorReporting() {
error_reporting(E_ALL & ~E_NOTICE);
// PHP 5.3.0対応
if (error_reporting() > 6143) {
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);
}
}

と記載があるが、とりあえずコイツにE_STRICTを加えて

function setErrorReporting() {
error_reporting(E_ALL & ~E_NOTICE);
// PHP 5.3.0対応
if (error_reporting() > 6143) {
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT);
}
}

ってすればエラーは出なくなる。

PHP5.5 beta1も出てきているみたいだし、更新して使えなくなる(or 使い勝手が悪くなる)
という事は多く出てきそうですね…。

macでPHP開発環境の構築

久しぶりの更新になってしまいましたが、備忘録なので仕方ないということで。

MacBook Proを購入しまして。
各種アプリ開発環境はサクッとインストールしたのですが、
PHP開発環境はeclipseを入れたくらいのものでした。

Mac自体がapache、mysql、postgresql、その他もろもろ入れられるので
自鯖で開発できるようにしたかったんです。

HomebrewでPHPのバージョン切り替えも簡単にできる感じで
(できればmysqlとかapacheもバージョン変えられるといいなと思ってる所ですが)
開発できれば色々と楽になるかな、と。

ということで、いろいろ調べつつ実行。

【とりあえずHomebrewの基本的なことを調べる】
Homebrewってのは、linuxで言うyumみたいなパッケージ管理システムのひとつ。
yumとの違いは、yumが既にビルドされているパッケージをインストールするのに対して
HomebrewはinstallコマンドでDL後にビルドしてインストールするらしい。
macではHomebrewとかMacPortsというパッケージ管理システムが多用されるみたい。

MacPortsはデフォルトでMac内に入っているアプリを依存関係として使用してくれない
らしく、既にインストールされているapacheも別の場所に再度入れて…みたいな事を
してしまうらしい。
ので、今回はHomebrewで。

前提として(?)Xcodeだけではなくてcommand line tools for Xcodeが必要なので、
app storeやらmacのサイトやらで入手する必要がある。
command line tools for Xcodeは、以前はXcode内に同梱されていたようなのだが
今は別梱らしいので、それも探して入れないといけなくなったらしい。
こういう細かい事は、Homebrewのインストール後に英語で注意書きが出るから
それを読めば大丈夫。

Homebrewのインストール自体は非常に簡単で、ターミナルから

ruby -e “$(curl -fsSkL raw.github.com/mxcl/homebrew/go)”

と入力するだけ。
その後

brew doctor

は走らせておく必要があるみたい。

ちなみに、Homebrewを使っていろいろインストールした際のキャッシュとかDLしたものは、
/Library/Caches/Homebrew/内に入るみたい。
で、その後はbrewコマンドでHomebrewを使ってパッケージを入れることになる。
例えば、

brew install wget

とか

brew uninstall wget

みたいな。

【apacheやらmysqlやらpostgresqlやら】
apacheはとりあえずmacに最初から入っているものを使用。
(面倒なので。)
必要に迫られることがあれば何か考えることにする。

sudo apachectl start

とかで起動して、http://localhostとかで動いたかどうか確認。
configは、/private/etc/apache2/httpd.confにある。

mysqlはHomebrewでインストール。
ターミナルを起動して、

brew install mysql

と打つだけ。
その後はどうするか(英語で)表示されるので、その通りに

unset TMPDIR
mysql_install_db --verbose --user=`whoami` --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp

とかでデータベースの構築。
(/usr/local/varディレクトリがないとmysql_install_dbでエラーが起きるかも?)

mysql.server start

でmysql起動。

postgresqlもHomebrewでインストール。
mysqlとほぼ同様なので、詳細は割愛。

brew install postgresql
initdb /usr/local/var/postgres -E utf8
pg_ctl -D /usr/local/var/postgres -l logfile start

という感じ。

PHPは後日で。5.1系のインストールができないかどうか悩んでいるところなので。
5.2系〜5,4系までは問題なくインストールできたんだけどね。

CSVファイルの扱い

CSVって、基本的に

・改行コードCRLF
・文字エンコードShift-JIS

であることが多いんだけども、
macintoshで作られたCSVを拝見したらCRだった。

さすがマック。…というべきか?

とりあえず、fopenしてfgetcsvで…とか思ったが、CRだとfgetcsvが上手く動いてくれない
(全てのデータが1行目にあると思われてしまう)
ので、改行コードを先に始末しないといけない。

ついでにUTF-8で書かれているPHPでも文字が読み込めるように
追加でひと手間加えてやる。

// SJISで記載されたCSVはUTF-8環境下では正常に読み込めないので、ここで対応
$buf = mb_convert_encoding(file_get_contents(CSVファイルのパス), “utf-8”, “sjis”);
// 改行コードCRLF、CRをLFに変換
$buf = preg_replace(“(\r\n|\r)”, “\n”, $buf);
// テンポラリファイルとして保存
$fp = tmpfile();
fwrite($fp, $buf);
rewind($fp);

// 1行ずつ処理していく
while($data = fgetcsv($fp))
{
// 各種処理
}

こんな感じで。
まさかCRの改行コードで苦しめられるとは…これっぽっちも考えていなかった。

一旦、clamdを停止する

VPSにqmail & vpopmail & clamd & spamassassinでメール環境を作っていたのだが
重い!メモリを大量に食う!
ので、他に何もできなくなる!

…ということで、一旦止めた。

 /home/vpopmail/etc/tcp.smtp
:allow,QMAILQUEUE=”/var/qmail/bin/qmail-scanner-queue.pl”

:allow,QMAILQUEUE=”/var/qmail/bin/qmail-scanner-queue.pl”

多分これでcdbを作成し直して、qmail再起動。
動いてるっぽいし、大丈夫っぽい?