multi-module conventions for phalcon

It looks pretty ok for a setup with many basic sites. I think that it would be a lot easier to use if it had a simple to use Bash or PHP script that could create a "site".

I dont anticipate the multi-site setup would get a lot of use, but want to make sure I'm not setting things up in such a way that hinder its being used for a multi-site setup. I dont know how much need there would be for a script.

This would do it:

mkdir sites

cp -r my sites/mynewsite

I don't see the actual Phalcon modules.

There are no modules in cernl as of yet. There is only a lib/modules directory where they'll live. I'm undecided on whether cernl should ship with any modules or not, but it will probably ship with a basic example module whose purpose is more for documentation than actual functionality.

Hey check out the Phalcon Developer Tools "modules" project. You can create it with phalcon project asdf modules when you have the tools installed. I put a lot of work into that for the Phalcon Cookbook that we recently released.

Thank you! This is the kind of thing I need to look at, to see where I'm duplicating effort, and to see what is a relatively conventional way to set up a multi-module project.

I just now installed a 'modules' project with the dev tools, as you suggested. What would the upgrade routine be like in the future? Let's say a year ago I installed a project called 'asdf'. Since then some work has been done on the project and I'm now running asdf 1.3. The asdf developers just released 1.4. What will the routine be like for a site owner to upgrade from 1.3 to 1.4? Is it another dev tools command to do the upgrade?

To be as community-friendly as possible, software should (generally) require little if any other software in order to do an install. I think about it this way... what will the install instructions look like? How many steps? Will any of those steps involve installing some other software? If so, is that other software something I can reasonably expect the site owner to already have installed? For example, I do think it's somewhat fair to expect that anyone running phalcon will have the dev tools installed. However, it would be ideal if there is a drop-in installation that doesn't even require dev tools. I think about the install from the perspective of a developer who has decided to spend a half a day taking a quick look at a few PHP frameworks. What will that developer's experience be like if my framework is one of the few they look at, etc. What will their experience be like if they've never even heard of phalcon? How quickly can they get to "first base" with my framework? Etc.

And I also think about the upgrade experience, and how the upgrade instructions will appear to a developer who has no familiarity with my framework at all, and who is just taking a peek at the upgrade docs to see what the future might hold.

For an install, ideally we want people to be able to do it using tools they already have. Git, that is. Not every dev in the world uses git, but git is installed on many, many more devs' computers than phalcon dev-tools, of crs. It's fair to assume that within a matter of hours of messing with Phalcon, a developer will probably install the dev tools. But I'm thinking about devs who arent even familiar with phalcon itself. We never know how someone comes to our software, but my case is probably typical. I searched google for a particular solution. The solution I sought was a Q&A forum themed like StackExchange. That led me to an app called Phanbook, which ultimately is not a good fit for me, but it got me interested in phalcon.

A year from now, somone who knows nothing about phalcon could find my project. Theyre going to see that it requires the phalcon php extension. I want my README to say there's one pre-requirement: phalcon. I dont want to say there are two pre-requirements.

Of course, phalcon means you need PHP itself, and a web server, etc. But those are even more ubiquitous than git.

To install my framework, a dev need only clone the git project and give the web server write privs for the cache directory. Done! Well, you also have to do the typical apache/whatever stuff like edit the hosts file but that's second nature for our target audience.

To upgrade my framework, all you have to do is replace the core directory with the newly released core. Presumably with git.

I very much have the dev tools in mind when I think about how to build a good PHP framework on phalcon. The fact that its so easy to hatch a new module makes it more imperative to set up the file system in a way that easily accepts contributions... and that makes that tendency very discoverable for new users.