Visual Composer vs. Page Builder by SiteOrigin

[metacortex]

Algunos diseñadores/programadores creen que Visual Composer les solucionará la vida mágicamente, luego lo compran y se tropiezan con la triste realidad de que igualmente tienen que escribir un buen puñado de CSS (y por supuesto saber integrarlo con el plugin) para darle forma a su sitio.

Hay que comprender esto: Visual Composer NO es una herramienta dirigida al diseñador sino al cliente. Este plugin nos permite ofrecer al cliente la posibilidad de cambiar él mismo su diseño de forma fácil, lo cual agrega puntos a nuestra propuesta y más dinero al presupuesto que le enviamos. Viéndolo así, VC es tremenda herramienta.

Pero si creemos que podemos diseñar una web con puro Visual Composer estamos jodidos. En serio. Y estamos jodidos porque le daremos un uso incorrecto a una herramienta que no es para ese fin.

Alternativa gratuita a Visual Composer

De hecho este plugin tiene muchos competidores (la mayoría de pago), pero existe uno gratuito que probé varias veces (aún no en sitios productivos) y me dio la impresión de que es bastante robusto, estable y versátil.

Se trata de Page Builder by SiteOrigin. A diferencia de VC y otros, éste no se desenvuelve enteramente con shortcodes (una ventaja y desventaja a la vez, según la óptica). El asunto es que he observado una notable reducción del tiempo de respuesta del sitio, así como en el peso de los archivos necesarios para echarlo a andar.

Nota: No he probado Page Builder by SiteOrigin en su totalidad, así que alguna información estará incompleta.

Algo sobre el peso de los archivos

Visual Composer genera una monstruosa hoja de estilos de unos 530kb (400kb si se desactiva la opción de personalización de estilos vía panel). Esta hoja lamentablemente es "sí o sí", pues el plugin hace su propia adaptación de Bootstrap para gestionar su estructura de rejillas. No hay manera de ahorrarse ese peso extra. Con Page Builder by SiteOrigin al menos tenemos la oportunidad de elegir cuál framework usar y sólo atenernos al peso de ese framework. Al menos eso creo, de todas formas me falta probarlo más tiempo.

API de funciones personalizadas

VC no sólo dispone de un método fiable y relativamente sencillo para nosotros desarrollar nuevas funciones y reflejarlas gráficamente en el panel, sino también ofrece una interfaz amigable llamada Shortcode Mapper (aunque si sabes programar te recomiendo irte por la vía del código).

Con Page Builder by SiteOrigin, en cambio, te encuentras con una clase php igualmente sencilla y bien estructurada. Respecto al alcance de la personalización tampoco lo he probado, pero al observar los ejemplos que sí están realizados no dudo que ofrece total libertad en ese sentido.

Templating

VC ofrece un sistema de templates donde sólo es necesario crear en el theme activo (o plugin creado) una estructura de directorios/archivos igual a la de éste. Sólo con eso el sistema otorga prioridad a los archivos creados por nosotros, por encima de los nativos. Con Page Builder by SiteOrigin aún no sé si esto sea posible.

(Este post se irá desarrollando poco a poco)

[siddartha23]

Sería genial leer que los post que usan shortcodes de visual composer ya puedan cargarse correctamente mediante una función AJAX, o en tu experiencia, que solución le darías a este problema :)

[metacortex]

¿Cómo así siddartha23? no entendí bien a qué te refieres.

[siddartha23]

Digamos que muestro algunas imágenes de productos en el home page para que cuando el usuario haga clic sobre una de ellas se ejecute un ajax request para obtener el contenido de la página del producto (hecha con los shortcodes de VC) y mostrarlo en un contenedor... la última vez que traté de hacer eso me dí contra la pared ya que los shortcodes del plugin no se renderizaban correctamente...

[metacortex]

Ya te entiendo. Eso depende de cuál shortcode existente utilizaste y si ese shortcode era para tal fin. Si no existe siempre hay la opción de crearte el tuyo propio. Recordemos que el único objetivo de Visual Composer es ofrecerte una interfaz amigable desde donde puedes modificar la estructura html del sitio en base a un diseño existente, y por lo tanto éste no suele ser el causante de errores como el que comentas.

Algo como lo que quieres se logra construyendo un query para obtener la imagen y una función orientada a ajax para que te devuelva los resultados. El resto es cuestión de mapear el shortcode con la función vc_map() (si es que deseas agregar un diálogo con opciones en el editor). Te dejo el mismo mini-tutorial que finalmente me hizo comprender cómo funciona esto:

http://www.sourcexpress.com/add-cust...mposer-plugin/

Como puedes notar, la construcción se basa en dos funciones: una que construye el shortcode (vcas_title_function) y otra que lo mapea para darle opciones (vcas_component_title). en tu caso necesitarías otra función más para gestionar la consulta a través de ajax y que te devuelva los resultados que esperas.

[siddartha23]

Mmm ok, gracias por la explicación :) pero creo que no se entendió bien lo que quise explicar, mira, acabo de encontrar un caso similar en los siguientes enlaces:

http://wordpress.stackexchange.com/q...esponse/227028

https://wp-types.com/forums/topic/th...vc-shortcodes/

Básicamente, tienes una función, a la cual se accede mediante una petición ajax, que te devuelve el contenido de una página maquetada con visual composer. El resultado te devuelve el contenido más los códigos (yo les llamaba shortcodes) que el plugin le agrega al post, y no los ordena visualmente como uno esperaría que suceda, es decir te devuelve el contenido así, tal cual se encuentra en la base de datos:

[vc_row][vc_column width=”1/4″][vc_single_image image=”389″ img_size=”full” alignment=”center” ....

Al parecer ahora que VC esta implementando lazy loading, ya están encontrándole soluciones, como la de usar esta función WPBMap::addAllMappedShortcodes(); antes de imprimir el contenido, aún no la he testeado...