Following an audit, I've been tasked to remove extraneous files from the Twig 1.x vendor directory in one of our sites. Planning on removing /twig/twig/doc, /twig/twig/test and see if anything breaks.
What about /twig/twig/ext/twig/run-tests.php, or the entire "ext" directory?
Does anyone have prior experience weeding a default Twig 1.x installation for production environments? Any assistance or advice gratefully welcomed.
The correct action would be to update your site's layout so that these files are outside your web server's document root -- then you don't have to worry about what to delete and what to leave. You probably have something like this, where your web server's document root is pointing directly at /path/to/project:
/path/to/project
/lib
foo.php
bar.php
/twig
/twig
/doc
/test
index.php
This means anybody can directly request http://yourdomain.com/twig/twig/test/some_file.php
What you want is more like this:
/path/to/project
/public
index.php
/lib
foo.php
bar.php
/twig
/twig
/doc
/test
Then configure your web server so that its document root is /path/to/project/public. Then your application code can still include() things in /twig and /lib, but your web server won't directly serve them.
If your removing files from the vendor directory they'll come back the next time you do a composer install so this seems kind of pointless.
The files you mention (docs and test) are causing no harm other than taking up space as they are not directly called, but that's just a downside to any package management system. Like #Alex said as long as they are not publicly accessible there is no need to worry.
If you really want Twig without the extra files you could fork the project, move it into your own Git repo then reference that in your composer.json instead of the official one - but you will miss out on any updates from Twig.
We're running on Apache, so the easiest solution was to simply add a .htaccess file to the top vendor directory:
# Prevent non-local access to the vendor directory.
Order deny,allow
Deny from all
Directory structure:
/root
/vendor
.htaccess
/twig
...
/includes
...
Now the PHP scripts continue to have access, but external attempts to view anything inside the vendor directory return a 403 error.
I have two different Symfony2.8 applications. During development they are accessible via two separated domains (virtual hosts): www.app1.local and www.app2.local. And everything works fine. But finally both applications should be deployed to the one server with one domain. Therefore I created two folders for each application.
Document root is /httpdocs, so file /httpdocs/test.php is accessible via www.domain.com/test.php. Two folders are /httpdocs/app1 and /httpdocs/app2. Each contains different installation of Symfony2.8 with own bundles etc.
And what is the problem? The web in URL. The URL to application looks like www.domain.com/app1/web/index.php instead of www.domain.com/app2/web/index.php. I'm trying to hide this web from URL but I don't have idea how to do this.
In general, it should be configurated via web-server itself. But if you don't have any access to configuration of web-server (Apache, nginx), you can do the following.
Put in your /httpdocs/app1 copy of app1/web, and in /httpdocs/app2 copy of app1/web
Applications themselves put in some other place.
So it will look, for example, like this:
app1/
app/
bin/
... # <--no web among these folders
composer.json
...
app2/
app/
bin/
... # <--no web among these folders
composer.json
...
httpdocs/
app1/
bundles/
....
index.php
app2/
bundles/
....
index.php
And then in your index.php fix paths to application
$loader = require __DIR__.'/../../app1/app/autoload.php';
include_once __DIR__.'/../../app1/var/bootstrap.php.cache';
(and same for app2, but with app2).
Also, fix both composer.json
"symfony-web-dir": "../httpdocs/app1",
I am going thorough the quick start for Symfony 2 and I'm getting quite confused. I have the following directory structure after unpacking Symfony2 (As in the documentation):
/var/www/ <- web root directory
Symfony/ <- unpacked archive
app/
cache/
config/
logs/
Resources/
bin/
src/
Acme/
DemoBundle/
Controller/
Resources/
...
vendor/
symfony/
doctrine/
...
web/
app.php
...
I've got the demo working at <host>/Symfony2/web/app_dev.php/demo/welcome/James. So far so good.
I know I can't use apache's mod_rewrite with app_dev.php so I was wondering if someone could give me a step by step to:
Moving the DemoBundle over to using app.php (because <host>/Symfony2/web/app.php/demo/hello/James is not working. It's throwing up a Symfony error. I swear I haven't touched a thing. I'm at the bottom of the first page of the tutorial)
Keeping the development toolbar when using app.php (do I just cut web_profiler: from config/config_dev.yml?)
Setting up Symfony2 outside of the web route (best thing for security I presume?!?) (Should I have to have a soft link /var/www/index.php pointing to /home/<name>/Symfony2/web/app.php?)
Now I'm on the production version will I be able to go to <host>/demo/welcome/James, if not, why not? (I have apache's mod_rewrite installed) (I'd really like to get this bit working)
(I had the same problem learning django, just to much information to absorb at first.)
The demo is not meant to be run in production. However, if you wish to do so for learning purposes, simply move the routes _demo and _demo_secured from app/config/routing_dev.yml to app/config/routing.yml.
Using the web profiler in production is again not sensible. Site visitors must not get access to such information. This is the reason why there are two separate front controllers (app.php and app_dev.php). They've both set up for different purposes.
The best practice in setting up the web server would be to have the web root point to ./web.
I'm trying to deploy an PHP application which is written with Zend Framework to a shared cPanel server.
There are not many tutorials available on this area online, however, I followed several of them. It is successful to run the test page which proves the zend framework is installed correctly.
However, since cPanel server has a default root directory called public_html/, it is impossible to simply rename it to the Zend Server's default public/.
As a result, I had two options in mind: (Say the project name is AAA)
1) upload my projects under the /public_html/ directory, then the project will be like /public_html/AAA/public, and etc.
However, this one simply fails to work.
My thought would be something wrong here with the baseUrl setting, however, no matter I comment ( which is to remove the baseUrl) or set to the root page, ( in this case /public_html/AAA) both failed.
2) I tried to follow the way listed in this article: http://blog.motane.lu/2009/11/24/zend-framework-and-web-hosting-services/. Still failed.
Can anyone suggest how to do it?
Really appreciate your help!
Just symlink it:
ln -s public public_html
then this structure will work:
htdocs/
myvhost.com/
public/
application/
library/
public_html # this is actually a symlink pointing to public
Whatever you do, dont just throw everything in the publicly accessible area... its just bad form :-)
I don't think ZF cares what you name your "public" directory. It's just the convention that's typically used.
I can't think of any ZF component or common use case where anything explicitly points at "public/...".
A project structure like this should work:
myproject/
application/
library/
public_html/ # this used to be public until you renamed it.
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/