Respuestas de foro creadas

Viendo 15 respuestas - de la 76 a la 90 (de un total de 474)
  • Efectivamente una buena solución sería el Lazy Load, que las imágenes se carguen solo cuando vaya a entrar en el área visual. Hay muchos plugins, yo ahora estoy utilizando Rocket Lazy Load y la verdad que me gusta mucho.

    • Esta respuesta fue modificada hace 8 años, 2 meses por cybmeta.

    ¿Puedes describir un poco que tipo de datos y el propósito? ¿Seguro que necesitas una tabla propia?

    Así a priori, asumiendo que de verdad necesitas la tabla propia, se me ocurre que podrías hacer un rewrite de tu URL personalizada hacia la página donde tienes el shortcode (no probado, solo escrito aquí como ejemplo):

    add_filter( 'query_vars', 'add_elemento_var', 0, 1 );
    function add_elemento_var($vars){
        $vars[] = 'elemento';
        return $vars;
    }
    
    add_action( 'init', 'rewrite_elemento_url' );
    funciton rewrite_elemento_url() {
        add_rewrite_rule( '^elemento/([^/]+)/?$', 'index.php?post_type=page&name=my_page&elemento=$matches[1]','top' );
    }

    Con ese rewrite, todas las urls de tipo elemento/algo te llevaría a la misma página y en ella podrías acceder al query var «elemento» y hacer lo que necesites con el valor en el shortocode o donde sea:

    $id = get_query_var( 'elemento' );

    Ya te habían dicho en el otro hilo, si has comprado la licencia y adquirido un producto premium, su desarrollador debería darte soporte para esas preguntas.

    Si tu intención es hacer una web app, ¿por qué no utilizar la REST API? Es un caso de uso de libro. Tendrás tu web app consumiendo datos de WordPress sin importar donde se ejecute la app o donde esté instalada.

    O si no, también puedes hacer tu web app en el subdominio o subcarpeta que quieras y cargar WordPress desde PHP (tengo un post donde hablo un poco sobre esto, por si quieres echarle un vistazo).

    Por ejemplo:

    require('../wp-load.php');

    Y así podrías acceder a la base de datos y utilizar cualquier función del API de WordPress sin necesidad de hacer otra instalación:

    require('../wp-load.php');
    
    $args = [
        'post_type' => 'products'
    ];
    
    $products = new WP_Query( $args );

    Hacer dos instalaciones con las misma base de datos y tablas no se yo si será posible, yo diría que no o que sería muy complicado.

    Yo tampoco entiendo bien la pregunta y el código que has puesto no se ve bien, a ver si pudieras editar el comentario o poner el código de nuevo en una forma «legible». Parece que era por lo del tag que comentaba Carlos en el comentario anterior.

    • Esta respuesta fue modificada hace 8 años, 3 meses por cybmeta.

    No te preocupes, doy por sentado que no es tu intención, lo comentaba más por como se puede tomar la pregunta más que por la intención que puedas tener.

    Si tienes alguna duda más, encantado de ayudar en lo que pueda.

    A él le pagaste, ¿por qué no le quieres preguntar? Lo que preguntas es casi como «haz un trabajo por el que ya pagué a otra persona, pero ahora lo haces gratis porque a la persona que cobró no le quiero preguntar».

    Más allá de lo que explica el enlace que puse, no se me ocurre otra cosa que decirte. Toma el selector del elemento al que quieres dar el color de fondo, y le aplicas la propiedad background-color con el color que quieras.

    Por ejemplo, para el body:

    body {
        background-color: black;
    }

    O como en tu web todos los elementos de clase «main-content» ya tienen el fondo negro, puedes crear un elemento con esa clase y tendrá el fondo negro sin que tengas que añadir CSS propio:

    <div class="main-content">
    Algún texto o contenido. 
    </div>

    ¿Y qué hacer con esa información? ¿cuál es el propósito? Imagino que querrás hacer algo con lo que el usuario escriba ahí, ¿no? ¿No te vale con los comentarios de pedidos y comentarios de productos que ya vienen con WooCommerce?

    «AMP for WordPress» es digamos el «oficial»y «básico» (es desarrollado por Automattic y Google, entre otros).

    «AMP for WP» funciona sobre el «básico», tienes que tener los dos instalados, y le añade más opciones y funcionalidades.

    Lo primero, pasarte a PHP 7 con Opcache (no recuerdo si Opcache viene activado por defecto en PHP 7, creo recordar que sí). Solo con eso vas a notar una gran mejora. Y no en velocidad, también en seguridad. La versión de PHP que utilizas está muerta y ya no recibe actualizaciones de ningún tipo, ni siquiera de seguridad, desde hace ya unos cuantos años.

    Pero no creo que se vaya a solucionar el problema por completo solo con PHP 7, ya que tienes una gran carga de plugins, y de plugins que consumen. Tras pasar a PHP 7, yo miraría los picos de consumo, ver si hay algun cuello de botella en la base de datos, pero sobre todo haría una auditoría a ver que plugins te puedes quitar antes de decidir si pasar o no a un plan de hosting mayor, o mejor dicho, lo haría incluso aunque pasaras a un plan de hosting superior.

    Ten en cuenta que plugins que parecen poca cosa pueden afectar en mayor medida al tiempo de carga que otros. Yo, por poner un ejemplo de experiencia personal, el plugin para shortcodes de Bootstrap lo tuve que quitar (no el que tienes tu, otro similar) y hacer un fork solo con los 3 o 4 shorcodes que se estaban utilizando. Un shortcode = un regex sobre el contenido, y ese plugin venía con 30 o así, y ejecutados de forma recursiva que en post largos necesitaban su tiempo (es solo un ejemplo de experiencia personal, no tiene porque ser tu caso).

    Acabo de mirar la empresa de hosting donde tienes alojada la web y veo que solo ofrecen VPS y que el más pequeño que tienen debería darte de sobra para esa web.

    ¿Qué versión de PHP utilizas? ¿Tienes activado OpCache? ¿Cuantos plugins tienes y cuales?

    Yo veo tal lentitud que probablemente se mezcle un hosting mediocre con problemas de programación/desarrollo. Algunas marcas son brutales: por ejemplo en el home del blog aparece en el código fuente «Dynamic page generated in 13.147 seconds.» !!! 13 segundos ¡¡¡¡. O en el home !!! 8.93 segundos ¡¡¡. Habría que mirar bien que pasa ahí.

    Veo que utilizas WP Super Cache, por lo que esos tiempos se reducen considerablemente para segundas visitas, pero una vez que seleccionas un producto, ya te saltas la cache de WP Super Cache y vuelta a tener que esperar esos largos tiempos para que se generen las páginas.

    Lo que tienes no se soluciona con CDN, minificaciones ni cosas de esas, vas a tener que revisar bien el código que hayas desarrollado y los plugins que estés utilizando, y probablemente vas a tener que cambiar de hosting; o puedes continuar en el mismo hosting si te gusta la empresa pero tendrás que contratar un plan más avanzado para tener más recursos para tu web.

    Te lo iba a proponer como solución temporal para que os aprueben el proyecto. Pero digo «solución temporal» porque lo importante es que entendáis que no se está exponiendo ninguna información sensible y el que problema que mencionas quedó perfectamente solucionado. La información expuesta es información pública no sensible.

    Si mi URL, descripción, username, avatar, etc, está aquí al lado junto a este comentario, ¿por qué es un problema que esté en el REST API? Espero explicarme bien.

    La información que expone el endpoint wp-json/wp/v2/users no es información sensible, pero en algunos casos podría ser considerada privada, y ese era el problema que tenía.

    El problema que había antes de 4.7.1 es que exponía información de CUALQUIER usuario que tuviese un post público, INCLUSO cuando el post era de un tipo de post registrado para no ser expuesto en el REST API.

    Desde 4.7.1 ese comportamiento se restringe. Si un usuario tiene UN SOLO POST publicado, pero es un post type que no debería ser expuesto en el REST API, entonces tampoco se mostrará la información de ese usuario.

    En los demás casos, la información que se muestra no es de tipo sensible ni privado; de hecho, es la misma información que muestran la mayoría de themes cuando muestran el autor de un post o de un comentario (avatar, username, url, descrición). Que se muestre esa información en wp-json/wp/v2/users es tan seguro como que se muestre en el HTML.

    Y también es la información que se muestra en wp-json/wp/v2/posts, en la información del autor de cada post. Así que, si os preocupa wp-json/wp/v2/users, también debería preocuparos wp-json/wp/v2/posts. Quiero decir, que no hay problema.

Viendo 15 respuestas - de la 76 a la 90 (de un total de 474)