Esto depende de qué quieres decir con ‘todo’. Supongo que te refieres a código de procedimiento + configuración. El contenido normalmente no se incluye en la práctica ‘todo en código’, pero la línea entre el contenido y la configuración a veces es confusa.
También depende de lo que entiendas por “personas”. En general, “todo en código” es una práctica recomendada aceptada por la comunidad de Drupal. En Drupal 8, este tipo de idea está integrada en el núcleo, consulte Gestión de la configuración en Drupal 8 y Gestión de la configuración en Drupal 8.
Por supuesto, Drupal permite una mayor flexibilidad que la configuración codificada. Tiene una capa de base de datos que permite a los usuarios cambiar la configuración a través de la interfaz de usuario. Esta es una de las grandes fortalezas de Drupal. Ahora con Drupal 8 es mucho más fácil obtener estos cambios de configuración en el código y ver qué ha cambiado. También es más fácil implementar estos cambios entre sitios. Esta suele ser una característica imprescindible si tiene diferentes versiones del sitio utilizadas en su flujo de trabajo de implementación (desarrollo, puesta en escena, en vivo). Sin algún tipo de administración de configuración, como Características y Strongarm en Drupal 7, necesitaría realizar cambios de configuración a mano en cada versión del sitio. Nunca recomendaría esto como práctica general.
- ¿Alguien puede publicar un código que capte la esencia de la relación entre html y javascript?
- ¿Qué herramientas de diseño usan los desarrolladores de juegos sociales para modelar y equilibrar juegos como Farmville y Social City?
- ¿Cuáles son las empresas web más influyentes en Pennsylvania?
- ¿Puedo usar Squarespace para crear un sitio web donde las personas puedan publicar y tener sus propios perfiles?
- ¿Cuál es la mejor manera de almacenar en caché una aplicación web de una sola página para SEO sin ningún desarrollo del lado del servidor?
Drupal 8 también permite bloquear algunas configuraciones de los usuarios. Esto hace posible tener dos tipos de configuración, una que se supone que cambia con el tiempo por las interacciones del usuario y la que solo cambian los desarrolladores. En este caso, probablemente no sea razonable poner la configuración administrada por el usuario en el código. Es mejor asegurarse de que su sitio funcione con cualquier combinación de configuración administrada por el usuario.
Si tiene un sitio simple no crítico con pocos usuarios, tal vez no lo necesite. Simplemente podría ejecutar una versión del sitio, instalar módulos y cambiar la configuración sobre la marcha. ¡Solo recuerde hacer copias de seguridad de la base de datos en caso de que algo salga mal y use GIT para la versión que controla el código! Una desventaja es que puede ser muy difícil saber qué cambios de configuración causaron los problemas en retrospectiva.
