Configuración - Posting de contenido

Para que el formulario de posting funcione correctamente y en toda su capacidad, se necesita definir una serie de
parámetros de configuración.

A continuación se muestra paso a paso, lo que se debe modificar o revisar al momento de implementar el sistema de Posting de Contenidos de Prontus.

El sistema de Posting utiliza un archivo de configuración especial, cuyo objetivo es darle información a la CGI que crea el artículo, y definir como se comportará el sistema.

Ubicación del archivo de configuración:

/< prontus_id >/cpan/< prontus_id >-posting.cfg

Variable	Descripción
[NOMBRE_INSTANCIA] ... [/NOMBRE_INSTANCIA]	Como el sistema de Posting, permite múltiples instancias del mismo, se debe especificar un nombre único para cada instancia. Para ello se inserta dicho nombre entre paréntesis cuadrados, como se muestra en el ejemplo. Dentro de dichos delimitadores, van las variables de configuración de dicha instancia.
_USERS_ID	ID del usuario que será dueño del artículo creado. Esto tiene que ver con la perfilación de los artículos dentro de Prontus. Si se omite, será igual a 1 (admin)
_FID	FID asociado al artículo creado. Este es el FID que será asociado al artículo dentro del CMS Prontus.
_PLT	Plantilla asociada al artículo creado. Esta es la plantilla que será parseada para crear el artículo.
_ALTA	Define si el artículo tendrá automáticamente el ALTA, activado o desactivado. Si se deja vacío, el ALTA no estará activado.
_SECCION1	ID de la sección asociada por defecto al artículo creado. Debe ser un ID existente, ya que si el ID no existe, el artículo será creado sin sección sin tema taxonómica.
_TEMA1	ID del tema asociada por defecto al artículo creado. Debe ser un ID existente, ya que si el ID no existe, el artículo será creado sin tema taxonómico.
_SUBTEMA1	ID del subtema asociada por defecto al artículo creado. Debe ser un ID existente, ya que si el ID no existe, el artículo será creado sin subtema taxonómico.
_MSG_PLANTILLA	Plantilla del Mensaje de confirmación entregado al Usuario. Puede ser exitoso o de error, según el resultado de la creación del artículo. (ver siguiente tema)
_ERROR_PLANTILLA	Permite especificar la plantilla de mensaje de error entregado al usuario. Si no se define, se usa el valor de _MSG_PLANTILLA. Disponible desde la release 11.2.72.
_MSG_MARCA	Marca que se utilizará en la plantilla. esta marca será reemplazada por el mensaje de éxito o error.
_MSG_OK	Mensaje que se desplegará cuando el artículo sea creado exitosamente.
_PORT	Nombre de la Portada, incluyendo la extensión, en donde se quiere que el artículo quede publicado por defecto.
_AREA	Área de la portada en donde se desea publicar el artículo.
_REGEN_LIST *	Indica que se deben regenerar las portadas list. Valor por defecto: "S" (regenerar). Valores posibles: "S", "N".
_REGEN_TAXPORT *	Indica que se deben regenerar las portadas taxonómicas. Valor por defecto: "S" (regenerar). Valores posibles: "S", "N".
_REGEN_TAGPORT *	Indica que se deben regenerar las portadas tagonómicas. Valor por defecto: "S" (regenerar). Valores posibles: "S", "N".
_CLUSTERING *	Indica si se debe transmitir el articulo a los clusters configurados. Valor por defecto: "S" (regenerar). Valores posibles: "S", "N".
VTXT_MEDIA_SCRIPT	Indica si se usará el embed tradicional o JavaScript en el VTXT de los artículos.
USAR_PUBLIC_SERVER_NAME_VER_ARTIC	Define si al hacer click en "Ver Artículo" desde el FID se usará la ruta absoluta del artículo usando el nombre del servidor (PUBLIC_SERVER_NAME). Por defecto se usa la ruta relativa.

(*) No se recomienda el uso de las opciones de regeneración de salidas ni clustering si se hará ingreso masivo de artículos.

En el archivo de configuración se definió una variable llamada: _MSG_PLANTILLA. Dicha variable define el
nombre de la plantilla de mensajes para la página de confirmación entregada al cliente.

Las plantillas de mensaje para las diferentes instancias del sistema de Posting de Contenido, se ubican en el
directorio:

/< nomprontus >/plantillas/extra/posting/pags/Además, dichas páginas de mensaje deben tener la marca definida en la variable: _MSG_MARCA, para que sea
reemplazada por el mensaje de éxito o error, según sea el caso. Si se definió la variable _ERROR_PLANTILLA, disponible desde la release 11.2.72, se usará ésta para mensajes de error.

Para configurar el formulario de Posting, se deben seguir las siguientes recomendaciones y consideraciones:

• El formulario debe tener un < form > con su action igual a: /cgi-bin/prontus_art_posting.cgi
• Debe tener obligatoriamente, 2 campos input de tipo hidden:
• _IDF: Identificador de la instancia del Sistema de Posting.
• _NP: Nombre del Prontus asociado a este sistema de Posting de Contenidos.
• El resto de los campos se manejan igual que un FID. Los campos presentes, deben ser los que se utilizan en el FID definido en el archivo de configuración. TODOS los campos del Formulario serán mapeados al XML, pero hay que tener presente que si el FID no posee uno de esos campos, se perderá al guardar el artículo.
• Lo fundamental es hacer un correcto mapeo entre formulario, plantilla y FID.
• Con respecto a las limitaciones, se debe tener presente que la única forma de subir imágenes, es mediante el campo reservado: FOTO_N1, quedando en el “banco de imágenes” del artículo. La redimensión automática de las imágenes usando el prefijo FOTOFIJA, no está permitida.
• Además, el editor visual VTXT no está integrado dentro del Posting, pero basta con implementar su editor favorito dentro del Formulario y asignarle un nombre con prefijo VTXT para que pueda ser mapeado dentro
  del FID.

• Para subir imágenes, se debe utilizar la marca FOTO_POSTING_N1. La redimensión automática se logra utilizando la marca de esta manera FOTO_POSTING_N1(w,h), por ejemplo: FOTO_POSTING_N1(940,940). Otro ejemplo mas completo sería:

< input class="input" type="file" name="FOTO_POSTING_N1" / >
< input type="hidden" name="FOTOFIJA_MULTI940" value="FOTO_POSTING_N1(940,940)" / >
< input type="hidden" name="CHK_cuadrar_FOTOFIJA_MULTI940" value="si" / >

• Alternativamente se puede enviar un campo hidden CHK_cuadrar_FOTOFIJA_MULTI940, que tiene el mismo efecto que el checkbox de los FIDs.

Queda abierta la posibilidad de agregar nuevos archivos al sistema, como páginas de carga, hojas de estilos,
Javascript, etc. Así como también la posibilidad de agregar lenguajes para hacer páginas dinámicas como PHP,
ASP, JAVA, etc., para manejar una capa de identificación sobre la aplicación, etc.

Sin duda, uno de los detalles más recomendables es el de utilizar Javascript para validación de campos, ya sea
por tipo, o como obligatorios, limitar rangos o largos de los strings, etc. Usar Javascript para evitar sobrecarga del servidor o el envío de formularios sin datos, es una muy buena extensión y dependerá de los datos que se deseen validar y del tipo de artículo que se esté recibiendo.

La utilización de captcha está por defecto, para más información ver este artículo.