Recordad que para pedir soporte alguno, debéis facilitar los datos de soporte oportunos por favor, mirad aquí y leer las Normas generales del foro, esto nos servirá de ayuda para dar el mejor soporte..

Gracias.

La Administración de phpBB España.

Estilo  Consejos y trucos para autores de estilos phpBB 3.1Tema Solucionado

📝 Guías phpBB 3.1 3.2
Cerrado
Avatar de Usuario
ThE KuKa
Administrador
Mensajes: 9113
Registrado: 04 Ene 2004, 19:27
Nombre real: Raúl
Ubicación: Terrassa
Género:
Contactar:

Consejos y trucos para autores de estilos phpBB 3.1  Tema Solucionado

Mensaje por ThE KuKa » 30 Ago 2014, 17:45

Consejos y trucos prácticos para autores de estilos phpBB 3.1

Hasta que no actualicemos la Biblioteca, voy a utilizar este tema para compartir algunos consejos prácticos y trucos para los autores de estilos que quieren sacar el máximo provecho de phpBB 3.1.

Incluir eventos en plantilla

Con el nuevo sistema de extensiones (antiguos MODs), muchas extensiones comenzarán a utilizar los eventos de plantilla con el fin de "inyectar" su código en dichas plantillas. Si quieres que tu estilo sea más popular, deberías tratar de incluir la mayor cantidad de eventos "por defecto" en la plantilla como sea posible.

Puesto que prosilver sigue siendo el estilo predeterminado para phpBB 3.1, la mayoría de las extensiones se desarrollarán principalmente para prosilver (y por lo tanto utilizaran eventos de plantilla de prosilver). La inclusión de estos eventos (más o menos en la misma ubicación que prosilver) se asegurará de que las extensiones futuras funcionen con su estilo.

Puede encontrar la lista completa de eventos de la plantilla que actualmente se incluyen en prosilver en el paquete de descarga phpBB 3.1, en root/docs/events.md. Usted puede agregar sus propios eventos de plantilla también, por supuesto, pero a menos que las extensiones empiecen a usar sus eventos de plantillas personalizados, no serán de mucha utilidad.

Incluir {$SCRIPTS}, {$STYLESHEETS} y jQuery

El nuevo sistema de extensiones, permite a dichas extensiones añadir archivos personalizados (externos) de JavaScript y CSS. Lo hacen mediante el uso de las instrucciones de plantilla siguientes:
<!-- INCLUDEJS mi_script.js --> y <!-- INCLUDECSS ../theme/mi_estilo.css -->

Lo que estos fragmentos hacen, es añadir los archivos especificados en la lista de archivos que se cargarán en {$SCRIPTS} y {$STYLESHEETS} ubicaciones de plantillas, respectivamente. Si usted no incluye estas 2 variables en las plantillas, muchas extensiones no funcionaran (ya que su funcionalidad front-end se basa en estos archivos).

{$STYLESHEETS} debe ser incluido sobre del final del elemento <head>
(pero después de <!-- EVENT overall_header_head_append -->).

{$SCRIPTS} debe ser incluido en la parte inferior del pie de página (antes de </body> pero después que jQuery sea cargado).

Tampoco se olvide de incluir jQuery. Esta con phpBB 3.1 por defecto, y las extensiones asumirán que está cargada. Asegúrese de que el siguiente código está presente en su pie de página (y antes que {$SCRIPTS}).

Código: Seleccionar todo

<script src="{T_JQUERY_LINK}"></script>
<!-- IF S_ALLOW_CDN --><script>window.jQuery || document.write(unescape('%3Cscript src="{T_ASSETS_PATH}/javascript/jquery.min.js?assets_version={T_ASSETS_VERSION}" type="text/javascript"%3E%3C/script%3E'));</script><!-- ENDIF -->

Clases prosilver Mimic

Como se desarrollarán la mayoría de las extensiones para prosilver, los autores utilizarán assets del estilo de prosilver siempre que sea posible. Esto les ayuda a reducir significativamente la cantidad de reglas CSS necesarias para escribir. Si un autor de extensión quiere añadir un bloque de filas con contenido, podría escribir todas las reglas CSS el mismo, o puede depender simplemente de las normas ya existentes. Lo más probable es usar reglas del estilo de prosilver, con selectores como ul.topiclist.

Si quiere que las extensiones funcionen en su estilo asegurando la menor cantidad de esfuerzo, puede usar los mismos nombres de clases CSS en más o menos los mismos elementos, esto le ayudara mucho.

Usar la "herencia" de plantilla siempre que sea posible

Muchos estilos empiezan por modificar estilos existentes (tales como prosilver), porque la creación de un estilo completamente nuevo desde cero es una tarea extremadamente lenta. La "herencia" de plantillas ha sido parte de phpBB 3 desde hace un tiempo, pero a menudo no se utilizan de la manera más eficiente.

Con phpBB 3.1, utilizando la herencia de plantillas se ha vuelto mucho más poderosa. Esto es principalmente debido a los nuevos eventos de plantilla. En lugar de tratar de incluir todos estos eventos de plantilla en su propio estilo, por lo general es mucho más fácil simplemente "heredar" de otros estilos (como prosilver). Esto puede ser un ahorro de tiempo útil.

"Herencia" de activos (assets) (usando CSS/images de otros estilos)

El mayor obstáculo para la mayoría de los autores es el hecho de que el árbol de herencia sólo funciona para las plantillas, no CSS.

Así que digamos que quiere hacer un nuevo estilo, basado en prosilver. Pero sólo desea cambiar la cabecera, pie de página, la barra de navegación, y algunas imágenes/colores.

Se podría proceder de forma natural mediante la creación de un nuevo estilo...
(con un style.cfg adecuado, que incluya la línea: parent = prosilver)
A continuación, deberá copiar los archivos overall_header.html, overall_footer.html y navbar_header.html en el directorio su_nuevo_estilo/template.

Esa fue la parte fácil. Pero, ¿cómo "heredamos" assets CSS del estilo prosilver?

Hay varias maneras de hacer esto, y dependerá de si va a hacer o no cambios muy significativos en los archivos CSS. Voy a tratar de explicar las diferentes formas de "heredar" los assets de estilo, y sus pros y contras.

1) Copiar-pegar todos los assets (/theme/)
El más fácil (y probablemente el método más utilizado) ha sido simplemente copiar y pegar todos los assets (el directorio /theme/ entero) del estilo padre al directorio del estilo secundario, y editar los diferentes archivos CSS para adaptarse a sus necesidades.

Pros
  • Fácil edición
  • No requiere ningún tipo de trucos plantilla
Contras
  • Pobre mantenimiento. Cuando prosilver sea actualizado, y desee incluir esos cambios ... tendrá que realizar un seguimiento de todos los cambios, etc.
  • Duplicación de assets
2) Rute-relativa @import con la sustitución selectiva
Si sólo desea realizar cambios en algunos CSS padres, puede que no desee duplicar todos los assets, ya que eso será un desorden en su nuevo estilo. Es posible sólo copiar unos assets y realizar cambios en ellos, sin tener copias idénticas repartidas por todo el servidor. En el archivo de su nuevo estilo stylesheet.css, podría incluir el siguiente código:

Código: Seleccionar todo

@import url("../../prosilver/theme/common.css");
@import url("../../prosilver/theme/links.css");
@import url("../../prosilver/theme/content.css");
@import url("../../prosilver/theme/buttons.css");
@import url("../../prosilver/theme/cp.css");
@import url("../../prosilver/theme/forms.css");
@import url("colours.css");
@import url("imageset.css");
Esto básicamente, cargara todos los assets CSS padres (prosilver), a excepción de imageset.css y colours.css, que desea cargar de los assets de su nuevo estilo (que ha copiado desde prosilver, y posteriormente editados para adaptarse a sus necesidades).

Pros
  • Deduplicación de assets
  • No requiere ningún tipo de trucos plantilla
Contras
  • Normas de ruta relativa @import son malas prácticas
  • Aún requiere que copie todos los assets que no están incluidos en stylesheet.css (como responsive.css, /es/stylesheet.css, etc.)
3) Múltiple decisivo stylesheets.css en <head>
En lugar de copiar los assets y la edición de ellos, también se pueden escribir nuevas normas que anulan las reglas padres CSS del estilo.

Código: Seleccionar todo

<link href="{ROOT_PATH}styles/prosilver/theme/stylesheet.css?assets_version={T_ASSETS_VERSION}" rel="stylesheet" type="text/css" media="screen, projection" />

<link href="{T_STYLESHEET_LINK}" rel="stylesheet" type="text/css" media="screen, projection" />
Lo que esto hace es cargar primero el stylesheet.css (y cargar todos los componentes posteriores a través del método @import como se especifica en el archivo). Después de eso, se cargará el stylesheet.css de su estilo personalizado. Por supuesto, puede usar reglas @import en su propio archivo stylesheet.css (si quiere dividir el código en varios archivos), o podría simplemente poner todas las reglas CSS en el propio archivo.

Nota: Usando ambas normas @import y reglas CSS regulares en el mismo archivo, no se aconseja.
Nota 2: Usamos {T_ASSETS_VERSION} como forma rudimentaria de control de caché del navegador.

Este mismo método se puede aplicar para cargar otros assets CSS padre directamente (sin tener que duplicarlos), como responsive.css, print.css, bidi.css, etc. Si desea utilizar los assets lingüísticos padre del estilo, podría utilizar el siguiente fragmento de código:

Código: Seleccionar todo

<link href="{ROOT_PATH}styles/prosilver/theme/{T_THEME_LANG_NAME}/stylesheet.css?assets_version={T_ASSETS_VERSION}" rel="stylesheet" />
Pros
  • Sin normas de ruta relativa @import
  • Posible para deduplicar todo
Contras
  • Sin un control detallado sobre qué partes de stylesheet.css padre para incluir/excluir.
4) Enlaces de componentes decisivos en <head>
Este método funciona de la misma manera que el (3), pero en lugar de incluir stylesheet.css padre (prosilver), cargamos los distintos assets directamente (sin depender de @import). Esto permite un mayor control de los archivos que desea incluir/excluir.

Código: Seleccionar todo

<link href="{ROOT_PATH}styles/prosilver/theme/common.css?assets_version={T_ASSETS_VERSION}" rel="stylesheet" />
<link href="{ROOT_PATH}styles/prosilver/theme/links.css?assets_version={T_ASSETS_VERSION}" rel="stylesheet" />
<link href="{ROOT_PATH}styles/prosilver/theme/content.css?assets_version={T_ASSETS_VERSION}" rel="stylesheet" />
<link href="{ROOT_PATH}styles/prosilver/theme/buttons.css?assets_version={T_ASSETS_VERSION}" rel="stylesheet" />
<link href="{ROOT_PATH}styles/prosilver/theme/cp.css?assets_version={T_ASSETS_VERSION}" rel="stylesheet" />
<link href="{ROOT_PATH}styles/prosilver/theme/forms.css?assets_version={T_ASSETS_VERSION}" rel="stylesheet" />

<link href="{T_STYLESHEET_LINK}" rel="stylesheet" />

<link href="{ROOT_PATH}styles/prosilver/theme/{T_THEME_LANG_NAME}/stylesheet.css?assets_version={T_ASSETS_VERSION}" rel="stylesheet" />
Nótese que no hemos incluido imageset.css y colours.css, ya que queremos utilizar nuestras propias reglas personalizadas (que vamos a especificar dentro de nuestro propio stylesheet.css) en lugar de usar el de prosilver.

Pros
  • Control total sobre los assets que se cargan
  • No usa el @import CSS en absoluto (esto es preferible)
  • Posible para deduplicar todo
Contras
  • Modelo de la cabecera más complejo
¿Qué método debo usar?
En general, yo diría que si su estilo tiene cambios de assets relativamente menores, me gustaría utilizar el método (3). Si su estilo tiene más extensas modificaciones, me gustaría utilizar el método (4).

Estilo de extensiones

Esto es completamente opcional, pero si siente que los usuarios de su estilo probablemente deseen utilizar determinadas extensiones (populares), es posible que desee agregar soporte para dichas extensiones en su estilo. Esto es particularmente útil si su estilo tiene un diseño poco convencional, o ha modificado de manera significativa los assets CSS/imagen.

Muchas extensiones con funciones de front-end incluirá su propia hoja de estilos utilizando <!-- INCLUDECSS mi_extension.css --> que agregará el archivo mencionado a {$STYLESHEETS} en su <head> (como se mencionó anteriormente).

Desde {$STYLESHEETS} en general se incluye después de <link href="{T_STYLESHEET_LINK}" />, esto significa que las reglas CSS de la extensión se impondrán a las reglas de su estilo (como estaba previsto). Se dará cuenta de que esto nos da un problema. No podemos incluir las normas específicas para estas extensiones en nuestro nuevo estilo de stylesheet.css, ya que serán anuladas. Podríamos superar esto utilizando fuertes selectores CSS o añadir !important a las propiedades, pero esto no es una solución muy elegante.

En su lugar, podríamos simplemente invertir el orden de carga para las reglas de extensión específica de nuestro estilo. La forma más sencilla de hacerlo es mover todas las reglas de su estilo que son específicamente para las extensiones en un nuevo archivo CSS (/theme/extensions.css por ejemplo).

Ahora tenemos que incluirlo en el <head> de nuestra plantilla. Tenga en cuenta el orden.

Código: Seleccionar todo

{$STYLESHEETS}

<link href="{T_THEME_PATH}/extensions.css?assets_version={T_ASSETS_VERSION}" rel="stylesheet" />
Con este método se asegurará de que sus reglas personalizadas se cargan después de las propias reglas de la extensión, anulándolas de ese modo.

Usar recopilación automática de plantilla (durante al desarrollo)

Mientras que realice cambios en los archivos de plantilla, esto resulta útil para poder ver los cambios directamente, sin tener que purgar el caché del foro en cada momento. Un pequeño truco es volver a compilar las plantillas de forma automática después de cada cambio de archivo.

Vaya a: ACP > General > Configuración del servidor > Configuración de carga y establezca:
Recompilar plantillas antiguas: Si

Fuente: PayBas en phpBB



Raul [ThE KuKa] en phpBB
Jr. Extension Validator - Jr. Styles Validator - Style Customisations - Translator - International Support Team


Enlace:
BBCode:
HTML:

Ocultar enlaces al mensaje
Mostrar enlaces al mensaje

Cerrado
  • Temas similares
    Respuestas
    Vistas
    Último mensaje