Por lo tanto, esto causará un gran revuelo e irá en contra de todos los desarrolladores de Magento, pero tenemos un proceso sólido para el tema que no utiliza local.xml (más sobre eso más adelante).
Siempre trabajamos fuera de la plantilla base/default
(y enterprise/default
para EE), pero ponemos a cero el CSS. A pesar de que todos los diseños no se prestan particularmente al diseño estructural de una tienda Magento de vainilla, consideramos una buena práctica utilizar el default
tema como punto de partida; podemos eliminar los métodos no utilizados / bucles / html, etc., según sea necesario durante la creación de plantillas.
Al comenzar un tema
Para EE
Primero instalamos esta extensión , de modo que obtengamos un nivel de reserva de temas, cuando luego eliminemos los archivos de temas que copiamos.
El paquete
Primero comenzamos creando el paquete y copiando todo el base/default
tema; así, por ejemplo (digamos que era nuestro propio sitio web, llamaríamos al paquete sonassi
)
cd ./app/design/frontend
mkdir sonassi
cp -par base/default sonassi/default
mkdir sonassi/default/layout/custom
La plantilla
El objetivo final es que no tengamos que guardar y pegar cada archivo que modificamos cuando sea necesario, solo editamos el archivo en el tema.
Pero cada vez que editamos el archivo, eliminamos los encabezados de Magento Commerce y agregamos un encabezado / identificador apropiado para marcar el archivo como una plantilla personalizada, generalmente algo así como ...
/*
* @category Template
* @package sonassi_default
* @copyright Copyright (c) 2013 Sonassi
*/
Este encabezado tiene un propósito más adelante cuando hacemos la limpieza final de la plantilla. Como haremos un recursivo diff
en el base/default/template
directorio y el sonassi/default/template
directorio, luego borremos todo lo que no haya cambiado.
De esta manera, solo quedan los archivos modificados y el paquete general se ha reducido al mínimo de archivos modificados.
Los archivos de diseño
Utilizamos un módulo central estándar propio sonassi.core
. Sí, siempre prefijamos el espacio de nombres del módulo con un identificador único: detiene los conflictos en los que otras compañías han elegido el mismo nombre (por ejemplo, fishpig / wordpress y sonassi / wordpress)
La metodología de diseño no local
<core>
<rewrite>
<layout>Sonassi_Core_Model_Core_Layout</layout>
<layout_update>Sonassi_Core_Model_Core_Layout_Update</layout_update>
</rewrite>
</core>
Luego, las dos clases de magia que agregan la funcionalidad para nuncalocal.xml
volver a necesitar ,
class Sonassi_Core_Model_Core_Layout
extends Mage_Core_Model_Layout
{
/**
* Loyout xml generation
*
* @return Mage_Core_Model_Layout
*/
public function generateXml()
{
$xml = $this->getUpdate()->asSimplexml();
$removeInstructions = $xml->xpath("//remove");
if (is_array($removeInstructions)) {
foreach ($removeInstructions as $infoNode) {
$attributes = $infoNode->attributes();
$blockName = (string)$attributes->name;
if ($blockName) {
$unremoveNodes = $xml->xpath("//unremove[@name='".$blockName."']");
if (is_array($unremoveNodes) && count($unremoveNodes) > 0) {
continue;
}
$ignoreNodes = $xml->xpath("//block[@name='".$blockName."']");
if (!is_array($ignoreNodes)) {
continue;
}
$ignoreReferences = $xml->xpath("//reference[@name='".$blockName."']");
if (is_array($ignoreReferences)) {
$ignoreNodes = array_merge($ignoreNodes, $ignoreReferences);
}
foreach ($ignoreNodes as $block) {
if ($block->getAttribute('ignore') !== null) {
continue;
}
$acl = (string)$attributes->acl;
if ($acl && Mage::getSingleton('admin/session')->isAllowed($acl)) {
continue;
}
if (!isset($block->attributes()->ignore)) {
$block->addAttribute('ignore', true);
}
}
}
}
}
$this->setXml($xml);
return $this;
}
}
y
class Sonassi_Core_Model_Core_Layout_Update
extends Mage_Core_Model_Layout_Update
{
public function getFileLayoutUpdatesXml($area, $package, $theme, $storeId = null)
{
if (null === $storeId) {
$storeId = Mage::app()->getStore()->getId();
}
/* @var $design Mage_Core_Model_Design_Package */
$design = Mage::getSingleton('core/design_package');
$layoutXml = null;
$elementClass = $this->getElementClass();
$updatesRoot = Mage::app()->getConfig()->getNode($area.'/layout/updates');
Mage::dispatchEvent('core_layout_update_updates_get_after', array('updates' => $updatesRoot));
$updateFiles = array();
foreach ($updatesRoot->children() as $updateNode) {
if ($updateNode->file) {
$module = $updateNode->getAttribute('module');
if ($module && Mage::getStoreConfigFlag('advanced/modules_disable_output/' . $module, $storeId)) {
continue;
}
$updateFiles[] = (string)$updateNode->file;
// custom theme XML contents
$updateFiles[] = 'custom/'.(string)$updateNode->file;
// custom theme XML override
$updateFiles[] = 'local/'.(string)$updateNode->file;
}
}
// custom local layout updates file - load always last
$updateFiles[] = 'local.xml';
$layoutStr = '';
foreach ($updateFiles as $file) {
$filename = $design->getLayoutFilename($file, array(
'_area' => $area,
'_package' => $package,
'_theme' => $theme
));
if (!is_readable($filename)) {
continue;
}
$fileStr = file_get_contents($filename);
$fileStr = str_replace($this->_subst['from'], $this->_subst['to'], $fileStr);
$fileXml = simplexml_load_string($fileStr, $elementClass);
if (!$fileXml instanceof SimpleXMLElement) {
continue;
}
$layoutStr .= $fileXml->innerXml();
}
$layoutXml = simplexml_load_string('<layouts>'.$layoutStr.'</layouts>', $elementClass);
return $layoutXml;
}
}
Las dos clases anteriores agregan la funcionalidad a Magento para que pueda ampliar, pero no sobrescribir un archivo XML de diseño. La extensibilidad del XML de diseño es importante para nosotros, ya que nos permite mantener la misma separación de archivos catalog.xml
, cms.xml
etc., pero solo necesitamos agregar pequeñas porciones de XML de diseño para manipular bloques (insertar / clonar / eliminar).
La local.xml
metodología es que simplemente ingrese sus cambios principales en un archivo engorroso e inmanejable.
La nolocal
metodología significa que, en lugar de colocar todos los cambios en un solo archivo, los coloca en un archivo con el nombre de archivo apropiado que está modificando (por ejemplo catalog.xml
), simplemente creando un nuevo archivo sonassi/default/layout/custom/catalog.xml
, con * solo las modificaciones .
Una vez más, una vez que hayamos terminado de hacer la plantilla, podemos eliminar el contenido de, sonassi/default/layout
con la excepción del custom
directorio. De esta manera, nuevamente, al igual que con la plantilla, tenemos una plantilla extendida liviana, basada en las plantillas base.
Las hojas de estilo
Los eliminamos, todos ellos. No nos molestamos en copiarlos en el directorio CSS de nuestro paquete. Copiaremos en el JS y eso es todo: el directorio images
y CSS
estará vacío desde el principio.
Como estamos usando SASS hoy en día, tendremos otro directorio ( scss
) para el CSS preprocesado , y lo enviaremos a los principales estilos / archivos CSS de impresión.
Limpiando la plantilla
Entonces, como mencionamos, una vez que se completa el tema de la plantilla, ahora puede limpiarlo, para eliminar los archivos no modificados y reducirlo al mínimo.
cd ./app/design/frontend
PREFIX="cleantheme_"
THEME="sonassi/default"
diff -BPqr "base/default/template" "$THEME/template" | \
awk '{print $4}' | \
while read FILE; do
DIR=$(dirname "$FILE")
[ -d "$PREFIX$DIR" ] || mkdir -p "$PREFIX$DIR"
[ -f "$PREFIX$FILE" ] || cp -pa "$FILE" "$PREFIX$FILE"
done
cp -par "$THEME/layout" "$PREFIX$THEME/"
Entonces, ¿por qué no local.xml
?
No es para ti , es para terceros, de la misma manera que community
es para ti y local
para terceros. Es una recuperación, último recurso, destino final para anulaciones.
Estructurar el XML de esta manera lo mantiene en línea con la forma en que Magento configuró originalmente el directorio y la estructura de archivos. Además, para la continuidad del desarrollo, tiene más sentido, es mucho más fácil de digerir y no agrega una sobrecarga notable.
Magento es un producto extraño, la comunidad ha inventado sus propias mejores prácticas basadas en el sentido común e imitando lo que hace el equipo central de Magento. Entonces, nunca hay una forma oficial (no hasta que un unicornio entre con la documentación de Magento-1) ; Pero este es nuestro camino.
Así que incluso me estiraría para decir que esta no es la respuesta, es solo una de las muchas formas de abordar un desafío que se enfrenta comúnmente. Aunque me gustaría pensar que nuestro método es el mejor.
Contenido felizmente obtenido de sonassi.com
default/default
instalaciones de CE. Quizás no sea tan difícil de hackear con las fuentes dadas, solo curiosidad (analizando esto: Magento Theme Fall-back / Hierarchy a la luz del tema personalizado y extensiones de terceros )"...the same way that community is for you and local is for 3rd parties..."
La manera de Magento es que esto sea al revés como se indica aquí: magentocommerce.com/wiki/2_-_magento_concepts_and_architecture/…Cree un tema de arranque en blanco para Enterprise. Eso significa tomar el
enterprise/default
tema, limpiar su CSS y "hacer clic en todas las cosas" para verificar que haya manejado el diseño de las características. No se olvide del vudú de vista de cuadrícula de productosUno de los beneficios es que esto brinda la oportunidad de configurar un flujo de trabajo MENOS (u otro). Piénselo: si bien el tema en blanco es un buen comienzo para los temas de colores claros, es un poco difícil cambiarlo para adaptarlo a un tema oscuro / negro. Sobre todo, DEBE incorporar el
enterprise/default
tema, de lo contrario, tiene una instalación EE interrumpida desde el principio.fuente