Reduam
Breadcrumbs Module
- Detalles
- Categoría: Navigation Modules
Breadcrumbs provide a pathway for users to navigate through the site. Help
Content
- Detalles
- Categoría: Plugins
Content plugins run when specific kinds of pages are loaded. They do things ranging from protecting email addresses from harvesters to creating page breaks.
Default on:
- Email Cloaking Help
- Load Module Help
- Page Break Help
- Page Navigation Help
- Rating Help
Default off:
- Code Highlighting (Geshi) Help
Cómo subir productos a tu tienda Prestashop
- Detalles
- Categoría: PrestaShop
Una de las razones más poderosas para utilizar un sistema de e-commerce como Prestashop es la facilidad para subir productos desde un entorno intuitivo.
Existen básicamente dos maneras de hacerlo:
- De forma manual. Subir manualmente los productos desde la opción “Catálogo” > “Productos” > “Añadir un nuevo producto”. Es sin duda la opción más largo y menos recomendable, ya que lo que nos interesa generalmente es tener cientos o miles de productos.
- Exportación de datos. Exportando una base de datos en CSV desde la opción “Catálogo” > “Productos” > “Exportar”. Es lo que suelen hacer las tiendas online que han trabajado con otro CMS, o tenían una base de datos ya realizada para su tienda física.
Cómo añadir un producto manualmente en Prestashop
Entramos en el apartado de “Productos” y veremos una pantalla en la que nos salen los productos que se han subido hasta ahora. Es muy probable que si la tienda está recién creada estén los productos por defecto. Cada producto te muestra los siguientes datos:
ID
Imagen
Nombre
Referencia
Categoría
Precio base
Precio final
Cantidad
Estado
Pinchando sobre el producto o haciendo click en el botón “modificar” podrás editar todos los aspectos de ese producto. Una vez ahí, nos saldrá la siguiente pantalla, donde deberemos rellenar una serie de datos.
- Información: debes indicar si es un producto estándar, si el producto forma parte de un paquete o si se trata de un producto digital. Muy importante: poner un código de referencia que resulte identificativo. También debemos indicar dónde se mostrará el producto, si sólo en el catálogo, sólo en los motores de búsqueda, o en toda la tienda. Conviene también escribir una descripción lo más detallada posible.
- Precio: Indicaremos el precio mayorista sin IVA, el precio de venta sin IVA, el tipo de impuesto y el precio de venta con IVA. Usaremos el apartado de “precios específicos” para señalar precios diferentes según la categoría de los clientes.
- Optimización de motores de búsqueda: importantísimo para el SEO. Hay que poner un meta-título, una meta-descripción con palabras clave y una URL que sea amigable para Google.
- Asociaciones: en este apartado integraremos el producto dentro de un eje de categorías y subcategorías.
- Transporte: aquí es donde debemos rellenar todo lo relacionado con el transporte y gastos de envío: altura, anchura, profundidad, peso y gastos de envío. También podremos seleccionar varios transportistas, según el que más nos interese para este producto.
- Combinaciones: el apartado de combinaciones es muy importante para establecer estándars. Así, por ejemplo, un producto que hemos categorizado como “grande”, puede tener un peso y tamaño estándar, así como unos gastos de envío más altos que otro que hemos categorizado como “pequeño”.
- Cantidades: señalamos la cantidad de la que disponemos del producto y sus variantes, en caso de que lo hagamos manualmente. Lo correcto, sin embargo, es habilitar el sistema de gestión avanzado de sistemas, o algún módulo o extensión Prestashop que sincronice el ERP de la empresa con nuestro catálogo Prestashop para que se actualice automáticamente y dispongamos de los datos sincronizados.
- Imágenes: puedes añadir las imágenes del producto. Lo recomendable no es que haya una sola, sino por lo menos unas 3 o 4 desde diferentes ángulos y posiciones.
- Funcionalidades: aquí señalaremos diferentes valores para las características de productos. Por ejemplo, si vendemos una mesa, señalaremos las medidas, el material, el estilo, etc.
- Personalización: aquí indicaremos el número de campos personalizados, tanto para archivos que subamos como para campos de texto.
- Adjuntos: podemos subir adjuntos para el producto, como por ejemplo un pdf con una guía del producto.
- Proveedores: en este apartado se indicarán los proveedores de los que disponemos para dicho producto y sus combinaciones. Los precios y las referencias que pongas aquí se utilizarán en la gestión avanzada de existencias cuando se produzcan órdenes de suministro.
Servidores DNS. Registro SOA
- Detalles
- Categoría: Registros DNS
Primero que nada el registro SOA, es el Registro de “Start of Authority” para un dominio. Contiene identificadores del servidor de nombres con autoridad sobre la denominación y su operador, y diversos contadores que regulan el funcionamiento general del sistema de nombres de dominio (DNS) para la denominación. Todo servidor de nombres de una denominación debe responder a una consulta por el registro SOA de esa denominación en forma autoritativa.
Además escribe los valores por defecto para el resto de parámetros de registro SOA en los archivos de zona que mantiene.
Dentro de los valores SOA se pueden configurar varios parámetros de opciones:
- TTL. Esto es el tiempo que los servidores DNS deben guardar el registro en el caché. Plesk establece el valor por defecto de un día.
- Actualizar. Esto es la frecuencia con la que los servidores de nombres secundarios verifican el servidor de nombres primarios para ver si se han realizado cambios en el archivo de zona de dominio. Plesk establece el valor por defecto de tres horas.
- Reintento. Esto es el tiempo que un servidor secundario espera para recuperar una transferencia de zona fallida. Este tiempo suele ser menor al intervalo de actualización. Plesk establece el valor por defecto de una hora.
- Expiraración. Esto es el tiempo antes que un servidor secundario deje de responder a las búsquedas una vez se haya producido un intervalo de actualización de la zona. Plesk establece el valor por defecto de una semana.
- Mínimo. Esto es el tiempo en que un servidor secundario debe cachear una respuesta negativa. Plesk establece el valor por defecto de tres horas.
- Número de Serie: Puede estar en varios formatos, tanto en IETF o en Unix-timestamp (menos utilizado).
- Persona responsable: Contiene la dirección de correo electrónico de la persona responsable donde la @ es un . (punto).
- Propietario: Es el nombre de dominio de la zona.
La sintaxis del registro SOA es la siguiente:
nombre-dominio ttl-RR IN SOA nombre-servidor-maestro correo-electrónico-administrador numero-serie t-refresco t-reintento t-expiración nx
El significado de los campos es el siguiente:
- nombre-servidor-maestro: Especifica un servidor DNS maestro del dominio, pero este significado de maestro es solo en el contexto del DNS dinámico (DDNS), indicando cuál es el servidor que podrá ser actualizado vía transacciones DDNS. Si no se ha configurado el DDNS, y por lo tanto no se usa, podemos poner cualquier servidor autoritario para el dominio, maestro o esclavo. Este servidor puede ser interno al dominio o externo, pero siempre debe llevar un RR NS. Es normal escribirlo en formato FQDN, pero esto solo es obligatorio en el caso de que sea un servidor externo.
- correo-electrónico-administrador: Se pone la dirección de correo electrónico (interna al dominio o externa) de la persona responsable de la zona. Se aconseja (RFC 2412) que sea una cuenta de correo exclusiva para este menester. En el ejemplo, el e-mail especificado es Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo., pero como el símbolo @ tiene un significado especial, se sustituye por un punto: hostmaster.asir.com. Es habitual escribirlo en formato FQDN, pero solo es obligatorio para direcciones de correo externas al dominio.
- numero-serie: Valor entero de 32 bits sin signo que va desde 1 hasta 4294967295. Este número lo utilizan los servidores DNS esclavos para ver si se han producido cambios en el fichero de zona y así actualizarse. Debemos incrementar este número cada vez que se hagan modificaciones sobre el fichero de zona. Se aconseja que se utilice un número con el siguiente formato basado en la fecha de la modificación: yyyymmddnn, donde nn es un número que comienza en 00 y es la parte que se incrementará cuando se hagan varias modificaciones en el mismo día, pues el resto del número no cambia. En el ejemplo, el número de serie está indicando que es la primera modificación realizada el 8 de abril de 2016. Se debe tener extremo cuidado de no cometer errores con este número.
- t-refresco: Indica el intervalo de tiempo tras el cual un servidor esclavo intentará actualizarse con la zona del servidor maestro. El RFC 1912 recomienda utilizar valores comprendidos entre 1200 segundos (20 minutos) y 43200 segundos (12 horas) según lo volátil que sean los RR. Si se usan los mensajes NOTIFY para la actualización, se pueden poner valores más elevados. Valor entero de 32 bits con signo.
- t-reintento: Indica el intervalo de tiempo entre reintentos del servidor esclavo, para cuando la conexión con el servidor maestro tras el tiempo de refresco ha fallado. El valor dependerá del conocimiento que tengamos del estado de la red, pero los valores van de 180 segundos (2 minutos) a 900 segundos (15 minutos). Valor entero de 32 bits con signo.
- t-expiración: Indica el intervalo de tiempo que el servidor esclavo estará haciendo reintentos de conexión con el servidor maestro porque este no contesta. Hasta que no pase este tiempo, aunque el servidor esclavo no se pueda actualizar, responde a las consultas de forma autoritaria, pero llegado el momento de expiración, deja de contestar a las consultas de la zona que no ha podido actualizarse. El RFC 1912 recomienda utilizar valores comprendidos entre 1209600 y 2419200 segundos, de 2 a 4 semanas. Valor entero de 32 bits con signo.
- nx: Indica el intervalo de tiempo que se mantendrá una consulta no resuelta en la caché de los servidores de nombres; transcurrido dicho tiempo, se volverá a intentar resolver la consulta (RFC 2308). Por ejemplo, si se hace una consulta del FQDN fpg.asir.com, y no es posible resolverla, el servidor devolverá un error de nombre (Name Error o NXDOMAIN). Durante los siguientes nx segundos, si se vuelve a hacer la misma consulta, se responderá de la misma forma; pero pasadas las dos horas, se intentaría de nuevo resolver la consulta fallida. Los valores posibles van de 0 hasta 10800 (3 horas). Anteriormente, este campo era el TTL por defecto de los RR, pero luego se introdujo la directiva $TTL como obligatoria y se le dio al campo el actual significado. Es por esto que nos podemos encontrar valores superiores a 10800 en antiguas configuraciones (versiones 4 y 8 de BIND); en estos casos BIND manda un mensaje log cuando se carga la zona y asume el valor 10800 para el parámetro nx. Valor entero de 32 bits con signo.
Latest Users Module
- Detalles
- Categoría: User Modules
This module displays the latest registered users. Help