Posting de contenidos

El posting de contenidos es una funcionalidad de Prontus que permite a los usuarios de un sitio web crear artículos Prontus a través de un formulario externo al panel de administración. Esto ayuda a crear comunidades en donde la participación de los usuarios es fundamental. El administrador del sitio web sólo debe elegir qué contenido se publica y cuál no, ocupándose de la
moderación o filtrado del contenido antes de que sea visto por el resto de los usuarios, evitando que los colaboradores suban contenido equivocado, irregular o impropio de la temática del sitio.

Como el contenido aportado queda como artículos Prontus, se facilita enormemente la manipulación de la información y su posterior publicación.

En el posting de contenidos se combinan los datos provenientes del Formulario con la Plantilla Prontus utilizando la información obtenida de la configuración de posting, para obtener un artículo Prontus y toda su información en formato XML. También se genera una página de confirmación en donde se entrega al usuario el resultado de la creación del artículo en el publicador.

• Permite a los usuarios del sitio Web enviar formularios con información para que sea publicada por Prontus en el sitio Web.
• Mantiene compatibilidad con el sistema de publicación normal, lo que implica que no es necesaria una capacitación adicional o un sistema separado.
• El procesamiento de la información enviada por los usuarios es hecha por Prontus, por lo tanto el administrador sólo debe elegir qué se publica y qué no.
• Puede existir más de una instancia de posting de contenido en una instancia de Prontus, lo que posibilita, por ejemplo, publicar formularios temáticos.
• Se puede combinar fácilmente con una capa de autenticación en el sitio Web, para restringir el acceso o permitir sólo a algunas personas el envío del Formulario de Posting.
• Alternativamente, cuando las condiciones de seguridad lo ameritan, se puede dar la posibilidad de que el formulario se auto-publique (por ejemplo, un formulario especial para los usuarios más confiables).

• El manejo de imágenes es limitado respecto a las funcionalidades presentes en el administrador de artículos. Sólo se pueden subir imágenes como archivos asociados o bien como imágenes al “banco de imágenes” del FID, pero no como fotos de artículo, portada, etc. Es obligación del administrador asignar la imagen a alguna posición o ubicarla directamente en la plantilla del artículo, pero arriesgándose a que el tamaño de la imagen descuadre la diagramación.
• El editor de texto enriquecido presente en los FIDs tampoco está disponible por defecto para los usuarios de este formulario. Si se desea implementar un formulario que posea una estructura similar, es de responsabilidad del desarrollador del formulario implementarlo y dejarlo operativo.

• El usuario llena el Formulario de Posting y lo envía. En caso que se requiera, se pueden aplicar validaciones javascript al momento de enviar el formulario. También es posible agregar una capa intermedia de validación en lado server, por ejemplo un script PHP que reciba los datos del formulario, los valide, y los pase a la etapa siguiente.
• El formulario es recibido por la CGI, la cual detecta la instancia de Prontus asociada y el Identificador del sistema de Posting (recordar que puede existir más de uno al mismo tiempo).
• Utilizando los datos anteriores, lee el archivo de configuración para identificar el FID y el artículo asociado, junto con el resto de los parámetros de configuración.
• Luego, parsea los datos tomados desde el formulario, y los combina con los datos leídos desde el archivo de configuración, generando así un artículo Prontus. Esto incluye HTML, XML, actualización de taxonomías (si aplica), inclusión en la base de datos, etc.
• Finalmente, Prontus usa la información del archivo de configuración de posting para generar un artículo Prontus completo.

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]	Dado que puedes implementar múltiples instancias de form Posting distintas en un mismo Prontus, debes especificar un nombre único para cada instancia. Para ello, 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 lo omites, será igual a 1, el ID del usuario 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á procesada para crear el artículo.
_ALTA	Define si el artículo debe tener el atributo Alta activado o desactivado. Si se deja vacío, el ALTA no estará activado, y el artículo no quedará visible ni podrá ser incluído en portadas.
_SECCION1	ID de la sección taxonómica 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 taxonómica.
_TEMA1	ID del tema asociado 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 asociado 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.
_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".

(*) 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: /[nombre prontus]/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, se usará ésta para mensajes de error. Si no se definió un archivo en _ERROR_PLANTILLA, se usa el especificado en _MSG_PLANTILLA.

• El formulario debe tener un <form> con su action igual a: /cgi-bin/prontus_art_posting.cgi. El atributo method de este formulario debería ser POST.
• Debe incluir 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 otros FIDs. 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. Es fundamental hacer un correcto mapeo entre formulario, plantilla y FID.
• El editor visual VTXT no está integrado dentro del Posting, pero puedes implementar tu editor favorito dentro del Formulario y asignarle un nombre con prefijo VTXT para que quede mapeado dentro del FID.
• Para subir imágenes debes utilizar la marca foto_posting_n1. La redimensión automática se logra utilizando la marca de esta manera foto_posting_n1(ancho, alto), por ejemplo: foto_posting_n1(940,940). Un ejemplo mas completo sería el siguiente:

  <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 o para otros propósitos.

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 campos de texto, 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.

Suponiendo que la instancia del Sistema de Posting de Contenidos se llame “postingform”, se tiene un archivo de configuración como el que se muestra a continuación:

[postingform]
_USERS_ID = '1'
_FID = 'fid_general'
_PLT = 'general.html'
_ALTA = '0'

_SECCION1 = '1';
_TEMA1 = '';
_SUBTEMA1 = '';

_MSG_PLANTILLA = 'msg_posting.html'
_MSG_MARCA = '%%msg%%'
_MSG_OK = 'Gracias por enviar tus contenidos'

_PORT = 'inicio.html'
_AREA = '2'
_ORDEN = '1'
_VB = 'N'
[/postingform]

Esta instancia del formulario está asociada al artículo tipo general, ya que usa el mismo FID y plantilla. Además, puedes ver que tiene el _ALTA deshabilitado, y tiene asociada primera sección de la taxonomía.

También se pueden apreciar, en el tercer bloque, las configuraciones para la plantilla de mensajes. Se define el nombre de la plantilla, la marca del mensaje y el mensaje propiamente tal.

Finalmente, en el cuarto bloque, se encuentran la variables del comportamiento de publicación. Los nuevos artículos, serán publicados en la portada de inicio, en el área 2, desde la posición 1 y con _VB (visto bueno) activado. Sin embargo, los artículos no serán publicados inmediatamente en la portada, debido a que el _ALTA está desactivado. El administrador está en la obligación de abrir el artículo, activar el “alta” y guardar el artículo, obligándolo así a revisar los artículos antes de publicarlos.

También se pueden dar otras combinaciones en la publicación, como por ejemplo dejar _ALTA activada y el _VB desactivado, para una publicación más rápida del contenido.

La plantilla de mensajes es el elemento más simple del sistema:

<!DOCTYPE HTML>
<html>
<head>
<title>Altavoz - Posting de Contenidos</title>
<meta charset="UTF-8">
</head>
<body>
<h1>Posting de Contenidos a Prontus Ejemplo</h1
<p><strong>%%msg%%</strong></p>
<p><input type="button" value="cerrar" onClick="javascript:window.close();" ></a></p>
</body>
</html>

Esta vista cuenta con la marca donde irá el mensaje, así como también un botón para cerrar la ventana (imaginando que haya sido implementada como popup). Es responsabilidad del desarrollador habilitar una página visualmente más agradable u ofrecer otras opciones más sofisticadas.

La plantilla debe estar ubicada en /[nombre prontus]/plantillas/extra/posting/pags/msg_posting.html

A continuación te presentamos un formulario con algunas opciones predefinidas y algunos campos de un FID genérico:

<!DOCTYPE HTML>
<html>
<head>
<title>Altavoz - Posting de Contenidos</title>
<meta charset="UTF-8" >
</head>
<body>

<form method="post" action="/cgi-bin/prontus_art_posting.cgi"
enctype="multipart/form-data" name="form">
<input type="hidden" name="_IDF" value="postingform">
<input type="hidden" name="_NP" value="prontus_ejemplo">
<input type="hidden" name="tgeneral" value="1">

<h2>Posting de Contenidos</h2>
<p>¿Quiere enviarnos una noticia o un artículo escrito por ud.? Llene este formulario y su información será revisada por los administradores del nuestro sitio.</p>

<div>Nombre> <input type="text" name="nombre" size="30"> </div>

<div>Apellido: <input type="text" name="apellido" size="30"> </div>

<div>Título: <input type="text" name="_txt_titular" size="50"> </div>

<div>Descripción: <textarea name="_txt_bajada" cols="40" rows="2" wrap="VIRTUAL"></textarea> </div>

<div>Cuerpo del Artículo: <textarea name="vtxt_cuerpo" cols="40" rows="4" wrap="VIRTUAL"></textarea> </div>

<div>Sube una imagen: <input type="file" name="foto_posting_n1">
<input type="hidden" name="fotofija_multi940" value="foto_posting_n1(940,940)" >
<input type="hidden" name="fotofija_multi300" value="foto_posting_n1(300,300)" >
<input type="hidden" name="fotofija_multi72" value="foto_posting_n1(72,72)" >
<input type="hidden" name="chk_cuadrar_fotofija_multi72" value="si" >
</div>

<div>Sube tu artículo: <input type="file" name="asocfile_1"> </div>

<div>Sube un archivo para descargar: <input type="file" name="asocfile_2"> </div>

<div> <img src="/cgi-bin/prontus_captcha.cgi?_type=posting&_nocache=1" alt="código de verificación"> <input type="text" name="_captcha" maxlength="4" class="field">
</div>

<div> <input type="submit" value="Enviar"> </div>
</form>
</body >
</html>

Como puedes apreciar, la instancia del Prontus se llama: postingform, tal como se usó en el archivo de configuración descrito anteriormente. El Prontus de ejemplo se llama prontus_ejemplo. En base a esto, se puede definir que en este ejemplo, la ubicación del archivo de configuración y de plantilla de mensajes están ubicadas en /[nombre prontus]/cpan/prontus_ejemplo-posting.cfg y en /[nombre prontus]/plantillas/extra/posting/pags/msg_posting.html respectivamente. El formulario permite introducir el nombre y el apellido del usuario. También podrías extender al email de contacto o a cualquier otro dato. Si has implementado una capa de autenticación, podrías pre-llenar los datos del usuario o bien dejarlos en algún campo hidden.

Más abajo puedes ver las variables más comunes de Prontus: _txt_titular, _txt_bajada y vtxt_cuerpo, junto con la opción de subir 2 archivos asociados y una imagen. Finalmente el form presenta el botón para enviar los datos.

Cabe rescatar que la marca para asignar una foto fija al artículo es FOTO_POSTING_Nn. En el ejemplo se permite subir una foto de la siguiente manera:

<input class="combobox" type="file" name="foto_posting_n1"> 
<input type="hidden" name="fotofija_multi940" value="foto_posting_n1(940,940)" > 
<input type="hidden" name="fotofija_multi300" value="foto_posting_n1(300,300)" > 
<input type="hidden" name="fotofija_multi72" value="foto_posting_n1(72,72)" > 
<input type="hidden" name="chk_cuadrar_fotofija_multi72" value="si" >

Alternativamente se puede enviar un campo hidden CHK_cuadrar_fotofija, que tiene el mismo efecto que el checkbox del FID.

En este ejemplo, no se incluyó validación de ningún tipo, pero puedes agregarla sin ningún problema, ya que no afectaría al funcionamiento del sistema. Por el contrario, evitaría la recepción de artículos no válidos.

El formulario debe ubicarse en el directorio stat de la instancia Prontus, por ejemplo: /[nombre prontus]/stat/form/aporte.html.

Para realizar la publicación directa del contenido ingresado en una portada hay que definir en la configuración los valores _PORT y _AREA, y definir _ALTA en 1, como se mostró en la configuración de ejemplo. Además se debe enviar la fecha de publicación del artículo, utilizando un campo hidden, como se muestra a continuación:

<input name="_fechap" type="hidden" value="" >

El que sigue es un ejemplo de script que genera el valor correcto de _fechap utilizando jQuery:

$(document).ready(function() {
    var fecha = new Date();
    $('[name="_fechap"]').val(fecha.getFullYear() + '' + (((fecha.getMonth() + 1) < 10 ) ?
    '0' + (fecha.getMonth() + 1) : (fecha.getMonth() + 1)) + '' + ((fecha.getDate() < 10 ) ? '0'
    + fecha.getDate() : fecha.getDate()));
});

El valor de _fechap debe tener el formato AAAAMMDD para que prontus establezca correctamente la fecha de publicación.

El campo _fechap es obligatorio para generar un articulo con alta, de otra forma el articulo deberá guardarse manualmente en el publicador.

Si no se cumplen estas condiciones, el articulo no quedará publicado en la portada.

La plantilla de mensaje definida en _msg_plantilla no es procesada por el publicador, por lo que cualquier tipo de marca Prontus, y código PHP incluido no será procesado. En caso de necesitar una página de respuesta que se genere más dinámicamente se puede hacer una plantilla con redirect, y pasar el mensaje como query string a la página con la respuesta final. Por ejemplo:

<html>
<head>
<title>Redireccionando...</title>
</head>
<body>
<script type="text/javascript">
window.location.href = "/[nombre prontus]/site/extra/posting/pags/msg_posting.html?m=%
%msg%%";
</script>
<h >redireccionando...</h3>
</body>
</html>

Si el fid tiene campos adicionales, checkbox, combobox, etc, y quieres pasar un valor fijo, se pueden utilizar campos hidden al igual que para _fechap, esto aplica por ejemplo cuando el articulo tiene comentarios y necesitan activarse al publicar.