CakePHPは、Ruby on Railsの概念の多くを取り入れた、高速開発とPHPの機動性を兼ね備えたフレームワーク
質問するときはCakePHPのバージョンを書きましょう

※他フレームワークとの比較等はスレ違いです

■本家
http://www.cakephp.org/
APIドキュメント
http://api.cakephp.org/
github - cakephp
http://github.com/cakephp
the Bakery
http://bakery.cakephp.org/
cookbook（マニュアル）
[3.x]http://book.cakephp.org/3.0/
[2.x]http://book.cakephp.org/2.0/ja/
[1.3]http://book.cakephp.org/1.3/ja/
Twitter
http://twitter.com/cakephp
Facebook
http://www.facebook.com/CakePHP

■日本語公式
http://cakephp.jp/
フォーラム
http://cakephp.jp/modules/newbb/


※前スレ
http://kanae.2ch.net/test/read.cgi/php/1393661004/

あーー、スレタイ間違えたわ

17ホール目じゃなくて18ホール目だった！

スマン

良いってことよ。乙。

Nginx+cakephpで、DocumentRoot以外に適用したいんだけど、うまくいかない
具体的には、cakephpのプログチュートリアルhttp://book.cakephp.org/2.0/ja/tutorials-and-examples/blog/part-two.htmlを、
tp://ドメイン/postではなく、
tp://ドメイン/cakephp/postで動くようにさせたい
スレチかもしれないけどどなたかわかりませんか

$vim /etc/nginx/sites-available/default
server {
root /usr/share/nginx/www;
index index.html index.htm index.php;
～略～
location /cakephp {
# alias /usr/share/nginx/www/cakephp/app/webroot;
index index.php;
try_files $uri $uri/ /index.html /index.php?$uri&$args;
if (!-e $request_filename) {
rewrite ^/cakephp/(.+)$ /cakephp/index.php?url=$1 last;
break;
}
}

location ~ ^/cakephp/.+\.php$ {
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_split_path_info ^/cakephp(.+\.php)(.*)$;
fastcgi_param SCRIPT_FILENAME /usr/share/nginx/www/cakephp/app/webroot$fastcgi_script_name;
fastcgi_intercept_errors on;
include fastcgi_params;
}
}

あれ使うならWordPressの方がよっぽどいい

>>7
WordPress以下って、そこまで酷いってこと？

>>8
世界中で何万人と使っているOSS以下なのが、
「そこまで酷い」に該当するの？？？

>>9
WordPressって、コードが酷いって散々言われているので。。。

>>10
じゃ、君の質問は
「BaserCMSはWordPressよりコードが綺麗なの？」
あるいは
「BaserCMSってコードが綺麗ですか？」
って事を聞きたいのか？

cakephpのテストでモックって使うべき？
勉強してもわからない。
モデルで、twitterにログインできるか？
をテストしたいんだけど。

テストの使い方がわからない

>>12 その場合は使わなくても問題なさそう。
やったことないけど twitter から成功したかどうかのレスポンスが返ってくるんだよね？
それが期待通りかテストすればいいと思う。

モックは、あるメソッドが期待通りの回数よばれたか、みたいなテストに便利。
たとえば、トランザクションの成功ケースのテストだとこんな感じ。

$mock->expects($this->one())->method('begin');
$mock->expects($this->one())->method('commit');
$mock->expects($this->never())->method('rollback');

begin() と commit() は一回だけ呼ばれるべきだし、 rollback() は呼ばれるべきじゃない。

>>15 画面操作が必要なんですね。
twitter 側からレスポンスを受け取った後のテストを書けばいいと思います。
どんなレスポンスが返ってくるのかはわかりませんが。

$user = $User->loginUsingTwitter('{"status":"success", "username":"hogehoge"}');
$this->assertEquals($user['User']['id'], 1);

$user = $User->loginUsingTwitter('{"status":"error", "message":"Invalid username or password"}');
$this->assertFalse($user);

みたいな感じでしょうか？

> あと、モックで回数を確認するのにと言うけどトランザクション以外で例ありますか？
ピンと来るかはわかりませんが――。

$dataSet = array(
array('id' => 1),
array('id' => 2),
array('id' => 3),
);
$mock->expects($this->at(0))->method('save')->will(array('id' => 1));
$mock->expects($this->at(1))->method('save')->will(array('id' => 2));
$mock->expects($this->at(2))->method('save')->will(array('id' => 3));
$mock->saveMany($dataSet)

内部的に saveMany() が save() を呼んでいるのであれば、 saveMany() に３レコードを渡したら save() は３回、それぞれのレコードを引数にして呼ばれるべきでしょう。

> 今まで、回数を確認したいと思ったことがないんです。
テストケースは、自分が確認したいと思うかどうかではなくて、追加開発を行う時に、後任の担当者を憂鬱にさせないために作るものかなと思います。
特に修正を行うと広範囲に影響が及ぶような中核機能については、入念なテストケースを書いておいた方がいいかもしれません。
さもないと、そこを修正する必要に迫られた時、後任の担当者は、関数をまるごとコピペして２、３行修正する、という愚挙に出ます。

>>16
ご丁寧にありがとうございます！

>>18 どういたしまして

どうしてもテストを書く時、
テストを先に、メインのプログラムを後に。というのがやりづらい。

先にメインのプログラムから書いてしまう。

何かコツみたいなないですか？

そもそもテストの意味がまるでわからない。
何かを登録する処理があるとして、
それをブラウザで実行して確認すれば良いだけじゃないのか？

あれデジャビュ

>>21
そう思うんだけど、テストした方が良いというのが定説なんだよね｡

>>21
テストケースを書けばテストも自動化できるので、コードの品質管理の上では必須。
ただ、Cake使いにはそういう所は少ない印象。
そういう取組をする現場はもっと新しいものを積極的に採用してるね。

>>24
テストケースって言うけどさ、ブラウザで実行して確認するのとどう違うんだ？

>>25
新規会員登録に成功、失敗。
ログインに成功、失敗。
パスワード変更に成功、失敗。

この合計6つのテストを一瞬でやれる。
また、これにツイッターでログイン機能をつける場合、ブラウザテストだとすべてをテストし直す必要があるが、
テストケースがある場合、どんな方法でツイッターログインをつけようがテストさえつけりゃOKということになる。

特に自分の場合はもう30過ぎたおっさんなので昨日のご飯すら覚えてない。
強いて言えば昔書いたプログラムなどほとんど覚えてない。

しかし、テストケースさえありゃどんな目的で作ったのか一目でわかるようになる。

>>26
それをブラウザで実行して確認するのと
何がどうメリットがあるのか全く理解できないんだよな。
どうせテスト書いてもブラウザで確認する作業もあると思うし。

単体テストでググれ

>>28
俺もテスト書くまではあなたと同意見だった。テスト書く手間もあるし、書き方もわからんし。
ただ、確認する項目が100,200となってくると同じ確認を何度もできなくなる。
手間だから。

安心感みたいなのもあるかもしれない。

http://jobinjapan.jp/job-listing/keyword-cakephp.html

公開画面の一部だけCake使うってこと出来ませんかね？
例えばDBに登録しているバナーを表示して、
表示回数をカウントするような機能。

こういうのは早い動作（処理）を求められるけど、
Cakeを通すとどうしても動作が遅くなってしまう。
けど、読み書きにControllerやModelを使いたい。

なにかいい方法ありませんかね？

Cakeと他のアプリの共存は.htaccessないし類似の設定で振り分ければできる
って書こうと思ったが後半見ると質問の意図は違うのか？

Cakeを丸ごと使うと遅くなるから機能の一部だけ使って速度と便利さ両立するような方法ない？って話？

>>33
はい。そういうことです。
1.3系にはあるみたいですが、2系ではググっても見当たりません。

そもそもそこまでしてCakeにこだわる意味あるのか？
フルスタックで高速開発が売りなのにわざわざバラして使うとか

素直に他の独立して使えるORMかSQLクエリビルダーのライブラリ使うってのは駄目なわけ？
軽いのならidiormとかあるじゃん
その例の程度だとControllerの必要性は感じないし

もしくは処理速くするだけならCakeフルに使ったままで
PHPをAPCやらで高速化するという手もあると思うけど

>>35
Cakeにこだわる意味あります。例えば>>32の要件の場合、
バナーの管理って管理画面を作ると思うのです。
その場合のログインシステム、バナー画像の管理、アクセス数の確認
など管理画面でやりたいことが結構あります。

これをフルスクラッチで作るのは結構骨が折れます。
「アクセスが集中する箇所を軽くしたい」という要件を満たすためだけに、
フレームワーク使わないというのは非効率に感じるのです。

なんで全部フルスクラッチにするの？
表示のカウントは管理画面と別でしょ？
管理画面だけCakeで作ってDBだけ共用すれば？

>>37
ということは、管理画面だけCakeにして
他は別のフレームワークを使うということですか？

それはそれで正しい開発の在り方なのでしょうか・・・

フロント側に他のページもあるならそこもCakeで作ればいいよ

要はアクセス集中する部分だけ素のPHPに近い状態で書けば速いわけだけど
Cakeはフレームワークの一部だけ取り出して使うことをあまり想定してないからこの用途にはあまり向かないんじゃないのってこと
かと言ってフルスクラッチはキツイだろうから軽めの他のライブラリ併用すれば？と

そこに他のフレームワーク使って何とかなるなら管理画面ごとそのフレームワーク使えばいいよね

外部ファイルにapp/webroot/index.phpの中身をコピって下部のDispatcherの部分のコード削って
その続きからApp::uses('Model', 'Model')などと書き始めれば動くことは動きそう
でも軽いかこれ？

バナーの表示回数ってWebサーバのログから集計したら
リアルタイムにデータ取りにくい代わりに負荷減らせね？

サーバのログから集計するって初めて聞いた考え方だなw
サーバのログ＝テキストファイルだけど、
それを分析・分類するのはどうするんだ？シェル書くのか？

アクセス解析のごく一般的な方法の一つでそ
共用のレンサバに機能としてついてるようなアクセス解析はほぼこの類
Apacheログのパーサーくらい探せばPHPのライブラリもあるだろうが
シェルスクリプトのが軽いか


最近はFluentdでログを構造化するのが流行ってんじゃね

でも、バリデーション便利だよ？

WordPressのテーマ編集のように、
ビューを管理画面から編集する機能をつけようと思っているのですが、
単にPHPのソースを編集する形にしても問題ないのでしょうか？
（不特定多数が使用しません。管理者のみです）

非プログラマにPHPファイルを編集させるのは違和感があるのですが、
WordPressでそうなってるので、特に問題ないのかな？と感じています。
もし、問題がある可能性があれば注意点を教えて下さい。