So here is a bit of an update.

• 548 CakePHP-related projects
• 284 Developers in the index
• Much better search (ajax even!)

That sounds like a really small amount of changes since March 4th, but you’ll have to remember that this is just a side project.

HOWEVER, there are a few things that have been worked on during the course of this project. If anyone bothers to check, there is a PermitComponent in controllers/components that controls access based on the concept of routes. Neil Crookes Searchable Plugin has had a few changes done to improve searches (so you should all see much better results). I’ve even open-sourced the data-set, so you can all start working on this project if interested.

In essence, the last iteration was about stability. I wanted to be sure the application didn’t have too many places where it would break or needed work before I add features that others might feel are necessary.

Where am I headed with *CakePackages*? Well for the moment, there are several interesting problems that I would like to explore for the next iteration:

1. Rating/Commenting System. Don’t like the package, or is it broken? Flag it, send a message to the developer, give feedback directly. I feel this is an area where we can improve Developer-to-Developer relationships
2. Refactor Flagging. Is this a full-blown application, a plugin, or just a snippet of code that should be refactored? We’d like to make it easier for developers to migrate their code to standard CakePHP practices. Would a screencast on creating Plugins help?
3. Tagging. It’s a great idea, and I’d like to standardize tags that can be applied to applications. Searching is cool, but without tags, it is sometimes difficult to see what is included in a package. Automating this via calls to the Github repository would be the best solution.
4. Categorization. We all know of the categorization system used on the Bakery, and how much it sucks. This is in the same vein as Tagging, but done correctly, we can ensure that users find ONLY code that contains the specifications they desire and nothing more.
5. Pulling in documentation. 9 times out of 10, there is more documentation for a package somewhere other than the Github repository or the developer’s homepage. Allowing users to submit meaningful links related to a package would be a great way to easily spread knowledge quickly

That said, I think I’ll take a look at Refactor Flagging for this particular iteration. It’s relatively easy to refactor your CakePHP snippets for release on the net, and it will allow CakePHP developers to standardize on an installation schema.

So how can you help?

• Submit your github repository to CakePackages on Twitter
• Fork CakePackages on Github and make your changes. If it is a great addition to CakePackages, in it goes!
• Report any bugs or feature requests via Twitter to CakePackages on Twitter
• Fork someone else’s non-plugin snippet and turn it into a plugin. Then issue a pull request :) Oh, and make sure we’re indexing it!
• Anyone want to design a Twitter Avatar?
• Release Open-Source CakePHP code on Github
• Tell your CakePHP friends that they no longer have to be jealous of Gemcutter :D

Follow this space for more updates