Estamos en el process de mover nuestros sitios de Drupal 6 a Git. Observé que Drupal 7 en realidad viene con un file .gitignore pnetworkingeterminado que ignora el file settings.php y el directory sites / default / files. Así que estoy asumiendo que esta es una práctica estándar y que no debería controlar las versiones del directory de files. Mi pregunta es, sin embargo, ¿cuál es el mejor método para mover estos files a través del process de migration de desarrollo a testing para vivir entonces? El sitio en vivo puede contener un montón de imágenes en ese directory que la gente ha cargado en el sitio en vivo, pero luego el directory en el server DEV tendría nuevas imágenes que algunos de los desarrolladores podrían haber agregado al contenido que han creado. Actualmente, cuando un editor de contenido agrega contenido en la forma de un nodo de página, por ejemplo, en el sitio de desarrollo, tenemos un editor WYSIWYG que les permite cargar una image que termina en / sites / default / files / images y se coloca en su contenido. ¿Cuál es la forma más fácil de sincronizar este directory de files entre los distintos serveres?
Gracias
En function de la respuesta a la respuesta de @ Brian anterior, el asker realmente tiene dos preguntas:
# 1, Razones por las que no debe include el directory de files en el control de código fuente:
/files/img.png
y /files/imagecache/small/img.png
. # 2, Implementar soporte de module para imágenes:
La respuesta corta es no; Implementar no admite imágenes cargadas por IMCE para D6. Ver: Agregar compatibilidad con imágenes IMCE .
Pero sarjeet.singh proporciona un parche para D7 en el problema vinculado anteriormente. Dado que las routes del directory de files son idénticas en dev / prod, debe poder adaptarlas para Drupal 6.
No sincronizas tu database desde el desarrollo a la producción, ¿verdad? Por lo tanto, tampoco debería necesitar sincronizar el directory de files. El directory de files drupal solo debe usarse para contenido agregado a través del website. Si sus desarrolladores están agregando resources que se necesitan en producción, entonces deben colocarse en otro lugar bajo control de versión.