I have 2 websites projects on the main directory inside /var/www/ directory
what I want to do is creating controller with it's views to be shared between the 2 project, not repeat the same controller on both projects,
now I create it ex. myController.php inside host A
How can I access the controller from the second host B ?
and render myaction function?
the url rules in the main.php config file
'newpage/list'=>'myController/myaction',
Edit :: I'm using this advanced template
**DIRECTORY STRUCTURE**
common
config/ contains shared configurations
mail/ contains view files for e-mails
models/ contains model classes used in both backend and frontend
tests/ contains tests for common classes
console
config/ contains console configurations
controllers/ contains console controllers (commands)
migrations/ contains database migrations
models/ contains console-specific model classes
runtime/ contains files generated during runtime
backend
assets/ contains application assets such as JavaScript and CSS
config/ contains backend configurations
controllers/ contains Web controller classes
models/ contains backend-specific model classes
runtime/ contains files generated during runtime
tests/ contains tests for backend application
views/ contains view files for the Web application
web/ contains the entry script and Web resources
frontend
assets/ contains application assets such as JavaScript and CSS
config/ contains frontend configurations
controllers/ contains Web controller classes
models/ contains frontend-specific model classes
runtime/ contains files generated during runtime
tests/ contains tests for frontend application
views/ contains view files for the Web application
web/ contains the entry script and Web resources
widgets/ contains frontend widgets
vendor/ contains dependent 3rd-party packages
environments/ contains environment-based overrides
Question is : How I can access the front end controllers in front end directory from backend rules ?
Frontend and Backed are two different modules. When they are bootstrapping from index.php they behave like two individual projects. So, you cannot route from frontend to backed or vise versa using urlManager of Yii.
May be you can maintain some params in common/params where you can configure absolute Url.
Actually you can reuse frontend controller classes in backend - you can use controllerMap property of application or module to define custom controller classes. For example if you add something like this to your backend config:
'controllerMap' => [
'mycontroller' => 'frontend\controllers\SomeController',
],
Then frontend\controllers\SomeController will act like it would be backend\controllers\MycontrollerController - backend.local/mycontroller will use the same controller as frontend.local/some, but with different contexts (and probably layouts).
You can even use controllerNamespace to load all controllers from given namespace. For example create separate module in backend:
namespace backend\modules;
class FrontendModule extends \yii\base\Module {
public $controllerNamespace = 'frontend\controllers';
}
Then this module will use all frontend controllers at backend context. backend.local/frontend/some will use frontend\controllers\SomeController.
For example: I have a session class, a message class, a CRUD class, in which folder I put them?
my folder structure is:
app/ <-- MVC logic
config/ <-- config files
core/ <-- core files of application, such as init
public/ <-- index and assets
vendor/ <-- for composer packages
I would recommend the Standard PHP package skeleton as a good root-level directory structure.
config/ # Configuration files
docs/ # Documentation and examples
public/ # Web server files (and front controller)
resources/ # Other resource files (assets, locales, migrations)
src/ # PHP source code (The App namespace)
tests/ # Test code
Extended version:
vendor/ # Reserved for composer (don't touch this folder)
tmp/ # Temporary files
tmp/cache/ # Cache files
tmp/logs/ # Log files
MVC directory structure (example):
templates/ # Templates (HTML, Twig files)
src/Controller/ # Controllers and actions, also src/Action
src/Domain/ # Business logic
I think your Session class is a HTTP Session library and the Message class is a validation class (or library). For this reason it should be installed via composer into the vendor/ folder.
It think your "CRUD" class is some kind of a "Data Table Pattern" or DAO or Repository and could be a combination of an external library vendor/ and application specific code src/.
What is "core" and "init"? Have you learned about MVC some abomination like CodeIgniter or something?
The "crud classes" (which actually should be data mappers) are part of model layer, same would apply to domain objects, repositories, services and other cod, that is strictly for implementing domain business logic.
The .. emm ... "session class" should probably do in the vendor, since there are dozens of implementations for session abstraction already available. And I have no idea what "message class" is supposed to be, but if you means "request" and "response", then those too should go in the vendor. I would recommend installing Symfony's HttpFoundation standalone component for those features.
I have all my zend applications like this
/app/
/app/registration
/app/games
I need to create a URL for games like this
mydomain.com/games/game-1
How do I set up the controllers and views in this directory structure when its like a module or sub application?
/app/games
/app/games/configs
/app/games/controllers
/app/games/controllers/Game1Controller.php
/app/games/views
...
One way would be to use the existing module conventions:
application/
controllers/
views/
configs/
modules/
registration/
controllers/
views/
configs/
The good thing about this is that ZF is already set up to handle this to some extent by convention... If you do it another way you are going to have to modify things more.
In this layout the top level controllers, views, etc.. are the Default module, while all other modules are under the modules directory.
I would also make each game its own module. If you have common code used in all games make classes you can extend and put those in your library.
You can also use zf tool zf.sh create module yourModuleName to create the default directory structure for modules.
Hey all, kind of new at Kohana and I have a quick question.
I have a site where there will be three subsections, organized by subdomain (i.e. admin.site.com, community.site.com, www.site.com) but each of the subsections will be pulling from the same database so should be sharing the same models. Is there a way to organize it so that I can use the same Kohana model/system/module files for each of the subdomains, but keep the application folder separate? Something like:
/home/user/admin/
application/
bootstrap.php
cache/
...
index.php
/home/user/community/
application/
bootstrap.php
cache/
...
index.php
/home/user/public_html/
application/
bootstrap.php
cache/
...
index.php
/home/user/kohana/
modules/
...
models/
...
system/
That way I can keep Kohana up-to-date across three sites with only one update, plus I can use the same modules and model classes. Is there any way I can make this happen? Or is there some other method I should be using?
Thanks!
I figured out how to do this, so I thought I would answer it in case someone else needs to know.
I moved my system and modules folders out of the webroot (to /home/user/kohana/) and created a folder there called sites. Then I created three separate folders in /home/user/kohana/sites/ for each of my three subdomains (admin, community, and www). I copied the contents of the application folder to each of these folders, then copied the index.php and .htaccess files to the webroots for each subdomain.
In each of the index.php files, at the top, I added:
$install_dir = '../kohana/';
and edited the following directory variables to include the new path:
...
$application = $install_dir.'sites/admin';
...
$modules = $install_dir.'modules';
...
$system = $install_dir.'system';
And it worked! I feel kind of stupid for not realizing how easy it was to move the directories around. Hopefully my explanation is coherent and assists someone else in the future.
I am creating a very large PHP MVC-based site that will have a large library of php classes, javascripts, and many css files (not to mention a large amount of files for the MVC).
For the first time ever, I am actually taking the time to plan out a clean and organized directory structure.
What directory structures do you typically use, and which will be easiest to manuever when there are thousands of files?
This is my setup. It's worked great for me for small - very large projects (including a social network).
These folders would all live within my main application folder:
config - contains custom PHP config files
css - contains the project's CSS files
helpers - contains 'helper' files (each file is a collection of functions)
images - contains the project's images
js - contains the project's Javascript files
lib - contains PHP classes specific to the project
modules - My MVC framework allows packaging site sections as modules
blog - An example module
controllers - contains the controllers for the module
models - contains the models for the module
views - contains the views for the module
views - contains views that should be globally accessible (page header, footer, etc)
All the directories could obviously contain sub-folders that would further organize your files. For example, the 'css' folder could have sub-folders named 'web' and 'mobile'. The 'images' folder could contain a 'user_uploaded' folder which could then contain`'profile'. And of course you can add folders as you see fit, in one project I have a folder called 'uploaders' which just contains stand-alone upload scripts.
I also use convenience methods which help construct the filenames of what I want to load. For example, my loadView() will look for the view file in the current module directory, or if you pass an optional $module argument, it will look specifically within that module's folder.
I hope this helps.
You should have one directory as web root, where only files you want exposed to the whole internet should reside.
project/
web/
index.php
css/
js/
images/
config/
lib/
web/ is the root shown to visitors
lib/ is here the library folder, and where autoload look for files.
You can add more subfolders to project/ like controller, modules, view, helper, etc. This depends on your framework.
EDIT:
If you use composer (which I recommend) and maybe npm with grunt and less your file structure would be the following:
project/
web/
js/
css/
images/
index.php
cli/
config/
config.php
node_modules/
src/
test/
vendor/
composer.json
composer.lock
packages.json
web/ has all your public files
cli/ scripts and programs to be run from command line NOT the web
config/ has all your config files (in git you ignore config.php and instead have config.dist.php without usernames, passwords, validation codes and table prefixes/suffixes and other "secrets")
node_modules/ has all your library files from npm (in git I suggest you put this in a submodule)
src has all your local PHP files in psr4 structure, set up to autoload in composer.json
test/ has all your unit tests for your src classes, set up in autload-dev in composer.json (remember to use composer install --no-dev on live, maybe add -o if you don't have too many classes)
vendor has all your library files from composer and the ONE AND ONLY autoload.php to be included in web/index.php and any cli scripts (in git I suggest you ignore this vendor folder)
Add other folders and files as required for your project.
For deployment use this structure:
/sites/project/ (project is your projectname)
current (alias to current release folder releases/v1.1.0)
previous (optional alias to previous release folder releases/v1.0.1)
releases/
v1.0.0/ (git checkout of tag v1.0.0)
v1.0.1/ (git checkout of tag v1.0.1)
v1.1.0/ (git checkout of tag v1.1.0)
shared/ (has all your shared files and folders to be aliased in all releases - maybe something like GlusterFS)
Make a deployment script. Something like this:
First take backup of db or to copy it to a new database, checkout git repo to new folder with release tag, get all git submodules, run composer install --no-dev, setup any aliases for shared folders and files like uploaded images and configuration files, generate js/css with grunt and less or equivalent, point current alias to the new folder with the tag, run update database script, restart nginx/apache/fpm-php services, run tests to check the website is up.
Have a script to go back to previous version (or a guide so you know what to do).
For core files which are included:
approot/inc/
For data access functions and classes are in:
approot/dao/
For javascripts:
approot/scripts/
For CSS:
approot/styles/
For images:
approot/img/
For static content (normally for user profile pictures or uploaded images):
approot/static/
For caches:
approot/caches/
For templates or View files:
approot/templates/
All pages file:
approot/
Structure from Samstyle PHP Framework
The answer I posted here was from 2009. Over the years more standards were published, including PSR-0 which covers the topic on folder structure. I also have a new (and I feel that it's better) folder structure with Packfire Framework.
In my experience, you can never plan for this. You can try to follow what frameworks do, but I find I never quite fit exactly into their mold.
I recommend to just keep a good rule of thumb for 20 files in a directory maximum. If you find you need more, just create a few sub directories and move common components in there.
This is mostly a matter of preference, a quick Google search would reveal many different project structures. But it would be really nice if there were an agreed upon standard. I think this initiative by the PHP Package Development Standards is a good candidate.
This is the directory structure they propose:
bin/: command-line executables
config/: configuration files
docs/: documentation files
public/: web server files
resources/: other resource files
src/: PHP source code
tests/: test code
EDIT:
This is also mentioned in the PHP The Right Way under the section Common Directory structure.
I use codeigniter for small and big projects.
It's MVC feature is moderately good.
codeIgniter\system\application\config : contain all kind of configuration files like DB,Payment gateway, ftp config, routes and ...
codeIgniter\system\application\models: contain all kinds of database classes, you should create sub folders according to your need, I used customers, mailData, paymentModel, report, web-service and ....
codeIgniter\system\application\views: contain all kinds of files that will work as output for clients, you should think of reuse these files if possible. Like the models you had to create sub folder like administration, reports, email, email_template .....
codeIgniter\system\application\controllers : this is the most important part. This will help to create SEO url, so you should be more careful about sub folders this time. You can create like administration, products, reports, orders..... and consider a good name for the functions of the controller class.
These were for the PHP/HTML file.
Now about the other files:
codeIgniter\images: for the images
codeIgniter\scripts: for the Java scripts and their framework
codeIgniter\styles: for the CSS
codeIgniter\uploads: for the uploaded files, if you don't want to put files in the DB
For the detail see codeIgniter framework in detail.
Here "codeIgniter\" is the approot
This is the structure i'm using currently,
public/
assets/ /* js, css, imgs, ... */
index.php
src/
config/ /* for config files */
helpers/ /* for functions */
libraries/ /* for free classes that are not MVC classes */
models/ /* for M in MVC */
views/ /* for V in MVC */
controllers/ /* for C in MVC */
vendor/ /* for vendors files */
uploads/ /* for uploaded images, docs, ... */
Have a look at symfony 1.4 or symfony 2 dir structure. Choose what's most intuitive to you.
I believe this depends on how large the project will become. This is what I used mostly:
project/
index.php
img/
css/
js/
views/
functions/
As long as all the project files are organised...
Even though the question is abit old, I still think it is wise to suggest the latest scaleable application structure which I have been working in my SOA based application and working absolutely fine.
myApplication/
app/
config/
+ this can include custom MVC structure
cli/
docker/
lib/ - most commonly reusable components
logs/
public/ - should contain all publicly exposable web contains
sql/ - db migration stuffs
tests/ - compulsory test
tools/ - application addon tools like any kinds of rulset etc
vendor/