Usted debe tener un directorio como root web, donde sólo los archivos que desea expuesto a toda la Internet debe residir.
project/
web/
index.php
css/
js/
images/
config/
lib/
- web/es la raíz se muestra a los visitantes
- lib/es aquí la carpeta de la biblioteca, y donde vistazo carga automática de archivos.
Puede agregar más subcarpetas al controlador de proyecto/como, módulos, vista, ayuda, etc. Esto depende de su marco de trabajo.
EDIT:
Si utiliza el compositor (que recomiendo) y tal vez NPM con ronco y menos la estructura de archivos sería el siguiente:
project/
web/
js/
css/
images/
index.php
cli/
config/
config.php
node_modules/
src/
test/
vendor/
composer.json
composer.lock
packages.json
- web/tiene toda su archivos públicos
- cli/scripts y programas que se ejecutarán desde la línea de comandos NO la web
- config/tiene toda su co Archivos nfig (en git usted ignora config.php y en su lugar tiene config.dist.php sin nombres de usuario, contraseñas, códigos de validación y prefijos/sufijos de tabla y otros "secretos")
- node_modules/tiene todos sus archivos de biblioteca de npm (en git le sugiero que ponga esto en un submódulo)
- src tiene todos sus archivos PHP locales en la estructura PSR4, creado para carga automática en composer.json
- prueba/tiene todas las pruebas unitarias para sus clases src, creado en autload-dev en composer.json (recuerde utilizar compositor instalar --no-dev en vivo, tal vez añadir -o si usted no tiene demasiadas clases)
- vendor tiene todos sus archivos de biblioteca del compositor y el ÚNICO y único autoload.php para ser incluido en la web/índice.php y cualquier script cli (en git sugiero que ignore esta carpeta de proveedor)
Agregue otras carpetas y archivos según sea necesario para su proyecto.
Para usar la distribución de esta estructura:
/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)
Hacer un script de implementación. Algo como esto:
Primero tome una copia de seguridad de db o para copiarlo en una nueva base de datos, descargue git repo a la nueva carpeta con la etiqueta de lanzamiento, obtenga todos los submódulos de git, ejecute la instalación del compositor --no-dev, configure cualquier alias para carpetas y archivos compartidos como imágenes cargadas y archivos de configuración, generar js/css con grunt y menos o equivalente, señalar el alias actual a la nueva carpeta con la etiqueta, ejecutar script de la base de datos de actualización, reiniciar servicios de nginx/apache/fpm-php, ejecutar pruebas para verificar que el sitio web esté activo.
Tenga una secuencia de comandos para volver a la versión anterior (o una guía para que sepa qué hacer).
Esto es solo un pensamiento. ¿Has considerado usar un framework PHP MVC que ya existe, como CakePHP? Entiendo que puede haber una curva de aprendizaje, pero podría valer la pena considerar los beneficios de un marco popular de código abierto. Creé y mantuve mi propio código durante años, pero descubrí que es más escalable utilizar un marco de terceros, especialmente para sitios grandes. Tal vez descubra que le ahorrará tiempo a largo plazo y tendrá habilidades valiosas para futuros proyectos de subcontratación. – Dooltaz
en realidad he pensado en eso ... y tal vez use uno al final ... pero tengo que ser capaz de hacerlo yo mismo antes de poder seguir adelante :) es algo neurótico ha – johnnietheblack