La respuesta es sí, las funciones de theme_mod serán más lentas, pero no significativamente, y los beneficios superan las diferencias.
Las modificaciones temáticas se almacenan como opciones. Entonces, en esencia, las funciones theme_mod son envoltorios alrededor de las funciones de opciones.
Primero, comprenda que la configuración de theme_mod se almacena como una matriz en una sola opción, asociada al nombre del tema específico. Entonces, si hago esto:
set_theme_mod('aaa',123);
set_theme_mod('bbb',456);
Entonces, lo que realmente obtengo en la base de datos es una sola fila de opciones con el nombre de theme_mods_themename que contiene una matriz serializada con ('aaa' => 123, 'bbb' => 456) en ella.
Ahora, get_theme_mod
será más lento porque en realidad está haciendo dos get_option
llamadas. Primero, obtiene el nombre del tema. Entonces, obtiene la theme_mods_themename
opción. Entonces, justo ahí, hay una pérdida de velocidad del 50%. El resto del trabajo realizado se basa principalmente en filtros, ya que hay una llamada de filtro adicional, pero a menos que tenga algo en ese filtro, esto es un poco insignificante.
Tenga en cuenta que el sistema de opciones almacena los datos recuperados en el caché de objetos, por lo que no está haciendo llamadas a múltiples bases de datos aquí. Solo el primer uso da como resultado un acierto en la base de datos.
El set_theme_mod
será algo más lento, ya que hace esos mismos dos consigue opciones llamadas, entonces tiene otra get_option
llamada para obtener el nombre del tema nuevo, y luego lo hace update_option
con el conjunto completo de opciones ahora cambiado. Esto provoca una actualización de la base de datos, y el hecho de que está enviando muchos más datos puede ser la causa de una desaceleración notable. Actualizar unos pocos bytes es más rápido que actualizar una fila más grande. Pero no tanto como notarías, por lo general. A menos que tenga una gran cantidad de configuraciones ...
Las funciones de mod de tema probablemente se deben optimizar en general, sin embargo, sin embargo, aún debe usarlas en lugar de get_option y, como así, temas secundarios.
El problema con el uso de filas de opciones directamente es que las está usando directamente y usando nombres de teclas específicos para su configuración.
Si tengo un tema llamado "AAA" y hago un tema secundario llamado "BBB" para usar en otro sitio, entonces mi tema "AAA" podría usar una opción llamada "ejemplo". Cuando actualizo un sitio y actualiza mi opción, la misma opción ahora se aplicará al tema de mi hijo. ¿Qué pasa si no quiero que lo haga? ¿Qué sucede si quisiera que el tema secundario usara un conjunto diferente de configuraciones de opciones?
Las modificaciones de tema, al incluir el nombre real del tema (y no un valor codificado) como parte de la clave, aseguran que cada "tema" en el sitio use su propio conjunto de configuraciones. Puedo cambiar de un lado a otro y la configuración no se transfiere entre ellos, se quedan como los configuro. Más simple, más obvio, más intuitivo.
Y si algún cambio en el núcleo o plugin en el futuro modifica el funcionamiento de theme_mods, automáticamente obtendrá los beneficios de eso sin ningún cambio. Los envoltorios siempre serán más lentos, eso es inevitable, es la naturaleza de los envoltorios. Sin embargo, todavía está escribiendo código PHP, no lenguaje de máquina. Usamos envoltorios como este para simplificar las cosas y separar la funcionalidad. Los temas no deberían necesitar saber, o importarles, cómo se almacenan sus opciones en la base de datos, o cómo funcionan los nombres. Las funciones theme_mod proporcionan una solución más simple que es más limpia.
/wp-includes
enoption.php
dondeget_option()
se define, y entheme.php
dondeget_theme_mod()
se define, se puede ver que este último hecho llameget_option()
sí, actuando como una extensión de la misma que se aplica también a cualquier filtros necesarios. Podría explicar por qué es más lento.