CakePHPは、Ruby on Railsの概念の多くを取り入れた、Rails流の高速開発とPHPの機動性を兼ね備えたフレームワークです
CakePHPから派生したLithium(li3)も専スレできるまではここでどうぞ
質問するときはCakePHPのバージョンを書きましょう

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

■本家
http://www.cakephp.org/
APIドキュメント
http://api.cakephp.org/
github - cakephp
http://github.com/cakephp
the Bakery
http://bakery.cakephp.org/
Issue
http://cakephp.lighthouseapp.com/dashboard
CheatSheet[1.2] (PDF)
http://cakephp.org/files/Resources/CakePHP-1.2-Cheatsheet.pdf

■日本語公式
http://cakephp.jp/
フォーラム
http://cakephp.jp/modules/newbb/
cookbook（マニュアル）
[2.x]http://book.cakephp.org/2.0/ja/index.html
[1.3]http://book.cakephp.org/ja

http://kohada.2ch.net/test/read.cgi/php/1354593996/l50

無いので建てた
過去ログのタイトル記入漏れ

【PHP】フレームワーク CakePHP 15ホール目【v2.2】
http://kohada.2ch.net/test/read.cgi/php/1354593996/l50

テンプレが貼られるのを待たず質問。CakeDCって何ですか？
「CakeDCとは」でググったんですけど出てきませんでした。
CakeDCのユーザー認証は標準のユーザー認証機能より良いんですか？
CakeDCのデメリットはありませんか？
あと、「CakeDC」でググると一番最初に出てくるサイトは
「このサイトは危険にさらされている可能性があります。」
とか書いてありますけど大丈夫ですか？

>CakeDCって何ですか？

CakePHP のコアデベロッパーが多数在籍してるSIer
CEOがCakePHPの元開発リーダー
以前ほどは CakePHP の開発における依存度は高く無いとはいえ、影響力は絶大。
Github のリポジトリで公開しているプラグインはどれも有名で多くのユーザーが使ってる模様。


>CakeDCのユーザー認証は標準のユーザー認証機能より良いんですか？

Usersプラグインのことでしょうか？
だとすると、CakePHP の機能を置き換えるものじゃなくて、
補完および隠蔽して使いやすくしているのだとおもう。


>CakeDCのデメリットはありませんか？

ネットの評判を見る限り、特に致命的な欠陥はないでしょう。
実際には実装に応じて要求が異なるので何がデメリットになるのかは場合により異なる。
CakeDCに限らないが、どのプラグインを使うにしてもひと通りソースを読めないと安心して運用するのは厳しいと思うよ。

WordPress みたいな気軽な感覚（それも問題あるけど）で
初見のプラグインをホイホイ放り込んですんなり使えるとは思わない方がいい。

>あと、「CakeDC」でググると一番最初に出てくるサイトは

ググったトップがどれのことか分からんが、
http://www.cakedc.com/
ならそんなエラー俺の環境じゃ出てこなかったけどな。

>>4-5
ご丁寧なレス頂き本当にありがとうございます。
Usersプラグインのことです。
＞初見のプラグインをホイホイ放り込んですんなり使えるとは思わない方がいい。
と言うのは肝に銘じます。

>>5に関しては日本語でググってしまったので
「プラグイン/CakeDC/users - CakePHP2 Memo」
と言うページがトップに来ました。
URLは念のためあえて貼りません。

Usersプラグインは、プラグインとは名ばかりのサンプル実装と考えたほうがいいよ。
サンプルといっても、微妙なつくりになってるところもあるから、
使えるところだけ参考にしながら別途書くのがいい

cakephp2を触り始めて日記を作ったのですが
URLを直で .../delete/1 などとすると
An Internal Error Has Occurred.というエラーがでて削除はされないのですが

自分でhtmlファイルを作り　そこにポストでボタンを作成し日記のデリートＵＲＬに飛ばすと普通に削除できてしまいます

これは自分のコントローラーが悪いのかどこか書き方が間違っているのでしょうか？

山ほど可能性があるのでそれじゃ情報少なすぎる。

まずそのエラーが出てるってことはデバグの出力を抑制してるんじゃない？
質問する場合は必ず Configure で debug の値を 2 にしておく。
それだけで解決することも多い。
で分からなければ、出た文面をそのまま貼り付ける。

ただ文面から推測すると、bake したコントローラをそのまま使ってるっぽいが、違う？

ちょっと自分でもわからず書いていますのでわかりにくかったらすいません。

普通に作ったダイアリー上で削除ボタンはしっかり動作します

ＵＲＬを直に/delete/id とすると
Error: The view for diarysController::delete() was not found.
とでます。これは普通ですよね？ＵＲＬから削除をさせないため、ほかのとこにアクセスさせないため

少しいろいろ書いてあるので消しましたがたぶんこれで動いてるはずです
public function delete($id) {
if ($this->request->is('post') || $this->request->is('put')) {
$this->Diary->delete($id);
$this->redirect(array('action' => 'index'));
}

ここまで正常だと思うのですが
自分で作ったhtmlファイルに
<form action="自分のＵＲＬ/delete/ＩＤ" method="post">
<input type="hidden" name="_method" value="POST"/>
<input type="submit" value="DELETE">
</form>

で記述してこれで投げると消されてしまいます
どうすれば解決できるのでしょうか・・・？
ポストを判定するまえになにか条件いれればいいのでしょうか？

CakePHPは初心者も大事にするFWなんでお答えします。
結論から言うと、質問の中にそもそも答えが含まれてる。

> Error: The view for diarysController::delete() was not found.

がなぜ出力されるのかというと、アクションの結果を描画するためのビューがないっていうこと。
なので、このエラーそのものと、レコードが削除されないことは実は関係がない。

> ＵＲＬから削除をさせないため、

の措置はアクション内部でのリクエストタイプ判定で行ってる。
で、これがほんとうに意味が分かって言ってるんなら、質問の答がこれですよ。
URLを直接叩いて削除しちゃうと良くないことが多いので、そうしないようにコードに記述してる。
つまり、コントローラが悪いのじゃなくてリクエストの仕方が悪いだけ。

> ほかのとこにアクセスさせないため

「ほかのとこにアクセス」が意味不明だが、リダイレクトの事を言ってるのならば、
別にそういうふうに作りたければそうすればよいだけで、このエラーの内容とは直接関係がない。

> if ($this->request->is('post') || $this->request->is('put')) {

で判定してる $this->request というのは自動的にセットされる CakeRequest のオブジェクトで、
リクエストに纏わる諸々のデータ・構造が内包されてる。
こいつの CakeRequest::is() メソッドでリクエストタイプを判定して、POST か PUT なら
モデルに対して削除を命令して、「描画せずに」array('action' => 'index') へリダイレクトする。
ここでこのリクエストに対する処理は終わり。(厳密には多少の後処理はある)

ちなみに分かってるかも知れないけど、この array('action' => 'index') っていうのは URL そのもので、
足らないパラメータ('plugin' や 'controller') はRouter で自動補完されて完全なフルパスにパースされる。


で、先程のは POST か PUT の場合だけど、それ以外（まぁGETだが）は評価ブロックを抜けて
通常のレンダリングに移行する。
仮に Diaries/delete.ctp を配置しておけば上記のエラーは出ないというだけ。

こんな説明で分かりましたか？

とても詳しく説明してもらってすいません

書き間違えはすいません　日記のようなものを作っています。少し改変しました

ちょっと補足します
> ＵＲＬから削除をさせないため、

というのはその通りです。
> ほかのとこにアクセスさせないため
なんでもないです。すいません

>仮に Diaries/delete.ctp を配置しておけば上記のエラーは出ないというだけ。
エラーは別にあってもなくてもいいのですが

<form action="自分のＵＲＬ/delete/ＩＤ" method="post">
<input type="hidden" name="_method" value="POST"/>
<input type="submit" value="DELETE">
</form>

この部分の回答がほしくて理解不足でもう出ていたらすいません

日記はその書いた人した消せない仕様なのですが
メモちょうなので↑のコードを書いてそこにあるボタンを押すことでどのＩＤの日記でも削除できてしまう
のをどうしたらいいかの回答がほしいです


ちょっと自分のやっていることが特殊なのか言葉不足なのかもしれません。

あぁ、権限の話でしたか。
消したいのに消せないので困ってるのかと勘違いしてた。

それなら CakePHP 以前に、PHPでリクエストを送ったユーザーを
どう識別するのかってことが分かってないと。

実現する便利な機能（端的に言うと AuthComponent ですね）
は備わってるけど、"PHP ログイン 認証" とかでググって
まずは素のコードが書けるようになってから Cake に
再チャレンジした方がいい。

今のままだとサンプル見てもどの部分がCakeの機能で、
どの部分がPHPなのかさっぱりわからない状態じゃないかな？

もしそうならいったん基礎に戻ったほうが結局は早く理解できて効率がいい。

ポスト判定をする前にまずログインしてるか調べてそのあとユーザーとその日記の書いたユーザが一致か調べればいけますかねぇ・・・

きっちり基礎ができているとは言いがたいですけどがんばって見ます

ある程度基礎ができてるなら、上のレスで書かれてる CakeDC の
Users プラグインを使って認証を一通り実装してみるといいです。
とても勉強になりますよ。

StackOverflowてCakeの質問してみたけど全然レスが付かない
別の質問もしてみたけどやはりレスが付かない
そもそも8 viewsしかされてないし、Cakeってだけでスルーされちゃうのだろうか

>>20
だからどの質問だ?
url貼れ

チュートリアルを見ると1テーブルに1モデルでそのモデルに対して複数のコントロールとビューがあるパターンしかないんですけど、
自分がやりたいのは複数のビューとコントロールに対して、複数のテーブルからデータを集めてきて処理をしたいんです。
その場合、モデルで記述するクラスはテーブルを使わない独自クラス、呼び出すテーブルはアソシエーションで定義するという理解でいいですか？
モデルに使用するテーブルをクラスとして別々に記述できるといいんですけど、違うみたいだし。

>>22
1モデル＝1テーブル という図式があたかも
規則であるかのように受け取られてしまうのが
チュートリアルの欠点のように思う。

それは全く気にする必要なし。

やりたいようにやればいい。

あと、標準のプロパティで張れるアソシエーションは限界があるので
それを越えようと思えば 'joins' キーでパラメータを指定したり、
直書きする。

一例を上げると、主テーブルに対して2つのテーブルをLEFT JOINするときに、
サブテーブルのキー同士を結びつける条件はプロパティの設定では不可能。
こういうときはメソッド内で joins で指定するしか無い。

Cake3 はもう少しマシになってるらしいが。

さすがにその頃にはCake卒業したい

もう時間ないぞ

>>18
お前、チュートリアル（認証系の方）にちゃんと書いてあるぞ
翻訳も完了してるんだから最低限チュートリアルやってから質問しに来い

>>27
そういうなよ。
CakePHPのドキュメントは正直分かりにくいし、
初心者というのはいろんな情報を手探りで集めるんだし

ぶっちゃけ公式ドキュメント見るのが一番効率悪い
よくできてないだろ、あれ
絶妙に必要な情報が欠落していて、中級者でも戸惑う

かなり同意。
CakePHPのドキュメントは分かりにくいよね。
ぐだぐだと長い文章書いてある割りに、
開発中にあれ？どうなってるだっけ？と思った疑問には全然答えてくれない。

そう、ボリュームが足りないとはあまり感じないんだけど
開発してたら調べたくなるようなことが、悉く載っていない
結局ぐぐってどこかの馬の骨のブログにたどり着き、
古い情報やサンプルコードを、必死で直しながら使うことになる

ドキュメントで翻訳されていないページはみんなどうしてんの？

そのまま読むかググるq

apiの方かソースコードを読む

>>34 に同じく。
ドキュメント、面白くさせようとしてるんだろうけど無駄な文章や修飾が多い。
用語のゆらぎも多い気がする。

$this->Thread->Response->User->displayField = 'username';
$this->Thread->recursive = 2;
$thread = $this->Thread->read();

はどう？
試してないから間違ってたらすまん

あぁ、すまん、Thread が持つ Response に含まれる User の username ね。
それなら displayField 云々は要らないな。
これは単純に User.username のデータを拾えるようにしてそれを表示すれば良いので、
一番雑なやり方だけど簡単なのは上で書いたように recursive を 2 にすればデータを取得できる。

どんな形式で返されてるかは debug() とか使って確認してちょうだい。
データアクセスはなれるまで少し面倒くさいけど仕方ないね。

ただ、このやり方で発行されるクエリはかなり大雑把。
Containable というビヘイビアの使い方をもし知らなければまずそれを覚えて損はない。
しかしこれもパフォーマンスを追求するなら酷いSELECT文になることが多い。
パフォーマンス上げたいなら最終的には細かくチューニングしなくちゃならないです。

あと気になるのは

> $this->Thread->Response->User->displayField = 'username';
> を試してみましたが、
> Indirect modification of overloaded property AppModel::$User has no effect
> とエラーが出ました。

これは出ないはずなんだけどなぁ。
本当に Response::$hasMany に User をセットしてる？
それさえしていれば、Response::$User プロパティがコールされたタイミングで
（なければ）自動的にセットするんで上記のエラーは出ないはずなんだが。。。

> Threadの中身が表示されなくなりました。
というのは何でかよく分からんけど、どんなクエリ発行されてるのか確認すると良いと思う。

パターン1: 継承する

/app/View/Helper/MyPaginator.php

App::uses('Paginator', 'View/Helper');
class MyPaginator extends Paginator {

}

class PostsController extends AppController {

public $components = array('Paginator' => array('className' => 'MyPaginator'));

}

パターン2: Paginator を app にコピー

/app/View/Helper/Paginator.php

(元の Paginator をそのまま貼り付けて適宜改造)


パターン1 のほうがいい。

丁寧にありがとうございます
１の方法を試したのですがPHPの書式エラーが出てうまくいかなかったので、
とりあえず２の方法で実装できました

え、どんなエラー？
ひょっとして1.3使ってる？

はい。1.3です
Appなんて知らないよ、みたいなエラーでした
私自身cakePHPを使ったことないのですが、現行システムを引き継いで、
新システム＋機能追加を行えという依頼が来ているので、四苦八苦しているのです

うわぁ、大変だなぁ。

エラーは多分App知らないじゃなくて、そんなメソッドないよってエラーではないかと。
1.3 のときは App::uses() じゃなくて App::import() 使ってた。
このへんはだいぶ変わってるからなぁ。
とりあえずパターン1でもApp::uses の行を削除すれば多分動く。

あと、クラス名とか大幅に間違えてたすまん。
Paginator じゃなくて PaginatorComponent だよな。

ありがとうございます。
今他の人が動作確認等をしているところなので、エラー画面を出すわけにもなので、また後で試してみます
他社が作ったシステムなのですが、不具合だらけで、よくこんなので数年運用していたな…と思えるもので
お客さんもこの制作会社に愛想をつかしたのかなと

そう言えば何年も前に1.2で納品したサイトをこの前こっそり覗いたらまだそのまんま稼働してた。

ひょっとして裏でメンテナンスしてる？と思ったけどどうやらそのままっぽい。

あれを今こっちによこされても触る気しねぇなｗ