Respuestas de foro creadas

Viendo 15 respuestas - de la 31 a la 45 (de un total de 92)
  • Nilo Velez

    (@nilovelez)

    A ver, es innegable que los constructores visuales dan un motón de problemas:

    • No ves la morralla que te están metiendo
    • Son menos eficientes que el código a medida
    • El día que los desinstalas te dejan el contenido inutilizable (lock-in)
    • Animan a usuarios novatos a meterse en cosas que debería hacer un profesional

    También tienen ventajas innegables:

    • Reducen (en algunos casos) los tiempos de desarrollo
    • Reducen (en algunos casos) los costes de desarrollo, al depender menos de especialistas
    • Agilizan los cambios de páginas complejas que cambian mucho (landing, minisites, páginas de promociones

    Yo suelo abogar por una solución intermedia y los utilizo, pero con condiciones:

    • En las webs corporativas (poco contenido, pocos cambios), se pueden usar perfectamente, pero tienes que asumir que el día que cambies de tema vas a tener que rehacer tus páginas estáticas
    • Por lo mismo, en el contenido dinámico (entradas, productos, recetas…) jamás utilices maquetadores visuales. Así el día que cambias de tema no tienes que tocar nada
    • Desactiva todo lo que puedas, muchos constructores te cargan automáticamente el javascript de un carrusel, el API de facebook, google fonts y google maps… aunque no los uses
    • Todo lo el contenido maquetado debería ir cacheado, si no puede ser cacheado no deberías usar un maquetador

    Resumiendo: si sabes cuándo usarlos, puedes usarlos, si no, es mejor que no los utilices.

    Nilo Velez

    (@nilovelez)

    Sí, si ya lo tienes hecho claro que puedes, pero siempre te va a dar menos problemas utilizar las funciones nativas de WordPress.

    Yo lo que haría es aprovechar todo lo que tienes ya hecho, pero en vez de montar al final la consulta INSERT, preparar el array de atributos de wp_insert_attatchment(), no debería resultarte complicado.

    Nilo Velez

    (@nilovelez)

    Lo siento, pero hay que tener muy poca vergüenza para anunciarse como desarrollador web profesional sin saber editar una simple hoja de estilo.

    «CLWEB usa herramientas de diseño totalmente personalizadas desde cero pero también, debido al auge conseguido, trabaja apoyándose en una de las herramientas más potentes y actuales como es WordPress, que tiene muchas prestaciones y posibilidades y donde el interesado puede tomar muchas decisiones en el diseño e incluso él mismo mantener su presencia en Internet.»

    No te sale en la hoja de estilos del tema porque está escrito dinámicamente desde los ajustes de Blossom Femenine, así que o lo tocas en los ajustes del tema o creas una regla css que la pise en el personalizador.

    • Esta respuesta fue modificada hace 2 años por Nilo Velez.
    Nilo Velez

    (@nilovelez)

    Hola Alejandro,
    la base de datos de WordPress no está diseñada para ser atacada directamente como en otros CMS sino utilizando las funciones del framework, que hacen las veces de API.

    En el caso de los adjuntos, hay una función específica, wp_insert_attatchment(), que copia el fichero y crea las entradas y los metadatos automáticamente:
    https://codex.wordpress.org/Function_Reference/wp_insert_attachment

    La forma más fácil de hacer la migración que quieres es instalarte cualquier tema (por ejemplo un twenty*) y escribir tu código para hacer la importación en el fichero functions.php para que se ejecute cuando cargues la web en un navegador (evidentemente, bórralo en cuanto haya hecho la importación.

    add_action( 'init', function(){
        // tu código
    } );
    Nilo Velez

    (@nilovelez)

    Mira a ver si tu tema tiene algún ajuste que active una hoja de estilo RTL (right to left).

    Lo normal sería que sólo se activara cuando utilizas un idioma RTL como árabe o hebreo, pero sin saber lo que tienes instalado, vete tú a saber.

    Yo cada vez que he tenido que hacer algo parecido siempre he terminado usando algo como esto: https://es.wordpress.org/plugins/woocommerce-custom-options-lite/ para que se encargue de gestionar las opciones y el coste extran; la vista previa me la curro a mano.

    Si algún alma caritativa conoce alguna opción mejor, soy todo orejas.

    Para WordPress, las única imagen que cuentan es la que pones como imagen destacada. Si lo que se ve en la entrada es la imagen destacada porque la esté metiendo tu tema en la plantilla, todos los datos van a ser dinámicos y se van a cambiar cada vez que edites la imagen en la biblioteca de medios.

    El resto de las imágenes que tengas en las entradas, para WordPress son indistinguibles del resto de HTML y para actualizarlas tienes o que volver a incrustarlas o reemplazar el código a lo bruto desde la base de datos.

    Hay plugins que lo hacen por ti (como este, creo, https://wordpress.org/plugins/media-file-renamer/) pero no sé como de fiables serán, sobre todo si ya has modificado tú el código de la entrada a mano.

    Hay maquetadores visuales, como el de Site Origin, que tratan un poco mejor las imñagenes incrustadas, no sé si la cosa mejorará con Gutenberg.

    Sí claro, lo puedes ir haciendo tan específico como necesites:

    /* con esto pones todos los precios del cuadro en rojo */
    .product-type-variable .summary-inner .price,
    .product-type-variable .summary-inner .price span {
        color: #f00;
    }
    
    /* con esto le devuelves el verde al precio de abajo */
    .product-type-variable .summary-inner .woocommerce-variation-price .price span {
    	color: #cbd248;
    }

    Vale, ya he visto el problema, el precio de arriba (el desde-hasta) no tiene un selector específico. Lo más sencillos es que cambies los dos y luego arregles el de abajo:

    /* con esto pones todos los precios del cuadro en rojo */
    .summary-inner .price, .summary-inner .price span {
        color: #f00;
    }
    
    /* con esto le devuelves el verde al precio de abajo */
    .summary-inner .woocommerce-variation-price .price span {
    	color: #cbd248;
    }

    Pues al final no he encontrado lo que tenía pero se ha arreglado.

    Simplemente he creado un usuario nuevo y ha salido andando, imagino que sería algún usermeta viejo dando problemas. Mil gracias Carlos, no se me había ocurrido

    Simplemente tienes que hacer un selector css un poco más específico.

    El HTML de las páginas de producto cambia de unos temas a otros, pero el bloque de arriba con el título y el primer precio suele se un div con la clase product_title o entry-title, así que tu CSS sería algo así:

    .entry-title .woocommerce-variation-price .amount {
    	color: red;
    }

    Espero que te sirva, no puedo hacer nada más con la web cerrada.

    Releyendo tu pregunta, lo que pides va a ser complicado.

    En casos como ese lo que se hace es configurar un equipo de la red local (puede ser el mismo servidor web) como proxy DNS y configurarlo como servidor DNS de los demás equipos de la red. Así cuando alguien entra a mipagina.com el servidor DNS le conecta directamente usando la IP local sin que tenga que conectarse a internet.

    Cuando trabajas así es como cuando modificas el ficheros hosts, a Apache y a WordPress lo único que les importa es la dirección que se ha escrito en el navegador, no la IP desde la que se sirve.

    Si lo que quieres es poder trabajar con ese WordPress en local sin tener que estar cambiando URLs, la forma más sencilla es que edites el fichero hosts de tu ordenador.

    Te dejo enlace a un tutorial:
    https://support.rackspace.com/how-to/como-modificar-mi-archivo-de-hosts/

    En tu caso, tendrías que añadir dos línea:
    192.168.0.x http://www.mipagina.com
    192.168.0.x mipagina.com

    Con eso le estás diciendo a tu ordenador que el dominio mipagina.com lo busque en esa ip local en vez de la que te de tu proveedor de DNS

    Foro: bbPress
    En respuesta a: Migrar phpbb a bbpress

    Si te está dando ese error es porque no está encontrando las tablas de phpbb.

    ¿Has probado a entrar por phpMyAdmin y ver si existe la tabla phpbb_sftopics en la base de datos wpress_bmforo?

    Hay cosas en las que Poedit se ha quedado un poquito anticuado y esta es una de ellas. Aunque WordPress ya no necesita que inicialices el textdomain del plugin explícitamente, Poedit sí. Esto sale en el log del error de Poedit:

    no load_plugin_textdomain call and lacking metadata
    some work is probably required to make the PHP code localization-ready

    Tienes que añadir esto en /plugin.php justo después del bloque de comentario:

    add_action( 'init', function(
    	load_plugin_textdomain( 'sj', false, dirname( plugin_basename( __FILE__ ) ) );
    }

    He hecho la prueba y con eso el Poedit ya reconoce bien las cadenas.

    Si quieres hacerlo un poco más elegante, puedes añadir esta línea a la cabecera:
    Domain Path: /languages

    Y reemplazar el código de arriba por este:

    add_action( 'init', function(
    	load_plugin_textdomain( 'sj', false, dirname( plugin_basename( __FILE__ ) )  . '/languages' );
    }

    Con eso estás diciendo que los .POT, .PO y .MO quieres que se almacenen en la carpeta /languages de tu plugin y que se carguen de ahí si no se encuentran en /wp-config/languages/plugins/tuplugin-es_ES.po

Viendo 15 respuestas - de la 31 a la 45 (de un total de 92)