Un CMS (sistema de gestión de contenidos) es un programa que guarda piezas de contenido —títulos, párrafos, imágenes— y las presenta con una plantilla. Quien escribe no tiene por qué tocar el HTML de cada página. Quien diseña la plantilla no reescribe la crónica cada vez que cambia una fecha. Esa separación es el núcleo de la lección, no el nombre de un producto comercial.
WordPress, un wiki del centro o el editor de una intranet son CMS distintos con la misma idea. En el aula no vamos a instalar ninguno: exigiría un servidor, una base de datos y una cuenta. El decreto nombra el gestor; esta materia lo explica con rigor y lo practica con un editor de bloques en la propia página. Los bloques viven en la memoria del navegador. Si recargas, se pierden. Esa limitación es honesta: una base de datos real persistiría, y aquí no hay base de datos.
Guarda contenido estructurado: el título en un campo, el cuerpo en otro, la fecha en otro. No debería guardar «el párrafo ya pintado de azul en 18 puntos». El color pertenece al tema (la plantilla, el CSS). Si el contenido lleva el color dentro, cambiar el tema del instituto obliga a editar todas las crónicas. Por eso, en el laboratorio, el bloque es un tipo (h1, p, cita, pie) más un texto. El aspecto lo pone una hoja fija de la vista previa.
También hay roles. En un CMS de centro no todo el mundo publica: hay quien redacta, quien revisa y quien administra temas y cuentas. En clase basta con nombrarlos. No vamos a simular contraseñas. Lo que sí simulamos es el gesto de «añadir bloque», «reordenar» y «ver la página montada», que es el trabajo de redacción, no el de administración del servidor.
Cuando pulsas publicar en un CMS real, el sistema rellena una plantilla y produce HTML. El visitante no descarga la base de datos: descarga una página. Por eso las lecciones 1 y 2 no sobran. Si la plantilla genera dos h1 o un enlace con ruta absoluta al ordenador de quien la programó, el fallo está en la plantilla, no en «internet». Saber leer el HTML de salida te permite corregir un tema aunque el botón del CMS se llame de otra manera.
Los tipos de bloque de esta lección son pocos a propósito. Un título de página (h1, uno), subtítulos (h2), párrafos, una cita y un pie. Reordenar importa: en una crónica, el titular va antes que el detalle del aforo. Borrar un bloque no borra «la web»; borra una pieza. Esa granularidad es la ventaja frente a un único documento de Word pegado dentro de un iframe.
No hay usuarios, ni historial de versiones, ni medios en una biblioteca compartida, ni comentarios del público. Nombrarlos evita la ilusión de que el editor de clase es WordPress. La ventaja didáctica es la contraria: ves el mecanismo sin cuenta y sin red. Cuando en la lección 11 se hable de alojar una web estática, podrás comparar: o subes HTML que escribiste tú, o subes lo que un CMS generó en otro entorno. En ambos casos el resultado público es un archivo que el servidor entrega.
Criterio de calidad del bloque: se entiende el texto si se lee solo la lista de bloques, de arriba abajo, sin mirar la vista previa. Si hace falta el color para entender el orden, el contenido está mal partido. Un CMS no arregla una idea confusa; solo la guarda.
CMS. Sistema de gestión de contenidos. Guarda piezas y las pinta con una plantilla.
Plantilla. El molde visual. Equivale, en nuestra práctica, a la hoja fija de la vista previa.
Bloque. Una pieza con tipo y texto. No es la página entera.
Campo. Hueco con oficio: título, cuerpo, fecha. No un cajón único.
Tema. Conjunto de plantilla y estilos. Se cambia sin reescribir las crónicas.
Rol. Oficio de quien usa el sistema: redactar, revisar, administrar. No es un botón mágico.
Publicar. En un CMS real, generar la página que verá el público. Aquí, pintar la vista previa.
Base de datos. Donde un CMS persistiría los campos. Esta página no tiene: al recargar se pierde.
HTML de salida. Lo que el visitante recibe. Sigue siendo HTML de las lecciones 1 y 2.
Editor de bloques. La práctica de esta lección. No es un producto; es el gesto de partir el contenido.
Cada caso es una entrega realista del proyecto del IES Duero. Lee la situación antes de mirar la decisión.
Situación. La fecha va al final de un párrafo sobre el taller de luz.
No conviene. Dejarla: «está escrita».
Decisión. Un bloque propio, aunque sea un párrafo, solo con cuándo y dónde.
Por qué: Si la fecha vive al final de un párrafo del taller, cambiar el jueves obliga a reescribir el taller. Un bloque propio, aunque sea un párrafo corto, deja cuándo y dónde separados del relato. Quien actualiza el acto no debería cazar la cifra dentro de la crónica.
Situación. Una frase del director se marca como título de página.
No conviene. Porque es importante.
Decisión. Tipo cita. El h1 sigue siendo el acto.
Por qué: Importante no es lo mismo que «tema de la página». El h1 dice de qué va el documento; una frase del director, por buena que sea, es una cita. Si la cita ocupa el h1, el acto desaparece del esquema y el título de la página miente.
Situación. El pie queda arriba porque se añadió primero.
No conviene. Porque el editor lo puso ahí.
Decisión. Bajar el bloque hasta el final y comprobar la vista previa.
Por qué: El editor coloca el bloque donde lo añades, no donde debe leerse. El pie queda arriba solo porque nació primero, y el orden de la lista es el orden de lectura. Hay que bajarlo al final y mirar la vista previa, porque el CMS no adivina la importancia.
Situación. Se discute la contraseña del gestor en vez del texto.
No conviene. Porque sin clave no hay lección.
Decisión. Redactar los bloques aquí. La clave, si existe en el centro, es otro oficio.
Por qué: El criterio 1.1 mira el contenido que se puede leer, no el panel de usuarios del gestor. Discutir la contraseña no redacta ni el título ni la hora. Los bloques se escriben aquí; la clave, si el centro la tiene, es otro oficio.
Las ocho piezas son el contenido de la Semana de la Ciencia del IES Duero (Aranda de Duero). Se repiten en el bloque A para que compares decisiones, no para que copies el mismo archivo doce veces. Debajo va el documento marcado, listo para abrirlo en local, y la lectura de cada pieza.
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="utf-8"/>
<title>Semana de la Ciencia · IES Duero</title>
<!-- Capa de esta lectura: lección 03. El texto del acto no cambia; cambia la decisión. -->
</head>
<body>
<header>
<p>IES Duero · Aranda de Duero</p>
<h1>Semana de la Ciencia</h1>
</header>
<nav aria-label="En la página">
<a href="#b1">Apertura en el salón de actos</a>
<a href="#b2">Taller de luz</a>
<a href="#b3">Taller de temperatura</a>
<a href="#b4">Visita al patio meteorológico</a>
<a href="#b5">Datos en la pizarra</a>
<a href="#b6">Preguntas</a>
<a href="#b7">Créditos y licencia de los materiales</a>
<a href="#b8">Cómo llegar</a>
</nav>
<main>
<section id="b1">
<h2>Apertura en el salón de actos</h2>
<p>A las 17:00 se abre el salón, no el laboratorio. El h1 de la página es el nombre del acto; este taller es un h2. Hay que decir el aforo (120 butacas) y que no se reserva sitio por mensaje: se entra por orden hasta completar. Quien llegue a las 17:20 oye el inicio, así que el primer párrafo no puede depender de un chiste que solo entiende quien estaba en la fila. El enlace interno #apertura permite saltar desde el nav.</p>
</section>
<section id="b2">
<h2>Taller de luz</h2>
<p>En el laboratorio de física hay una fotorresistencia de demostración. La página no enciende el sensor: explica la hora (17:30) y el grupo máximo (16 personas). El detalle del pin GPIO se cuenta en la lección 4 con un LED simulado; aquí, en la estructura, basta un párrafo y una lista de dos normas: no tocar la protoboard y anotar la lectura en el cuaderno, no en el móvil de otra persona.</p>
</section>
<section id="b3">
<h2>Taller de temperatura</h2>
<p>Segundo grupo, misma franja, aula de al lado. Si los dos talleres se mezclan en un solo párrafo, nadie sabe a qué puerta ir. Van en sections distintas, cada una con su h2. La temperatura se mide con un sensor digital de demostración del departamento; la página no publica la marca como si fuera un anuncio, solo el lugar y la duración (25 minutos).</p>
</section>
<section id="b4">
<h2>Visita al patio meteorológico</h2>
<p>Si llueve, este bloque se cae. Por eso el texto tiene la alternativa escrita (vídeo de tres gráficos en el salón), no un «ya veremos». En HTML la alternativa es una frase dentro de la misma section, no una imagen que sustituye al aviso. Plano general: el patio está detrás del gimnasio, puerta verde.</p>
</section>
<section id="b5">
<h2>Datos en la pizarra</h2>
<p>Al final se apuntan tres números: luz, temperatura y aforo real. Son una lista ordenada si el orden es el del acto, o desordenada si son datos sueltos. Elegimos ol porque se leen en ese orden en la puesta en común. Cada li es una frase corta, no un párrafo disfrazado.</p>
</section>
<section id="b6">
<h2>Preguntas</h2>
<p>Diez minutos. El heading es h2 «Preguntas», no h1: la página ya tiene dueño. Se recuerda que no hay turno de fotos al alumnado. Esa frase es texto, no un icono. Quien imprima la página en blanco y negro tiene que leerla igual.</p>
</section>
<section id="b7">
<h2>Créditos y licencia de los materiales</h2>
<p>El footer nombra al departamento de tecnología del IES Duero y dice que los textos de esta página son del centro para el acto. No se pega música ni fotos de banco de imágenes. Si más adelante hay un plano, será un SVG hecho en clase. La licencia concreta se estudiará en el bloque B; aquí basta no atribuirse lo que no es del instituto.</p>
</section>
<section id="b8">
<h2>Cómo llegar</h2>
<p>Calle San Francisco, Aranda de Duero. El autobús urbano deja en la plaza; desde allí, seis minutos a pie. No incrustamos un mapa de un proveedor externo: exige red y cookies. Un párrafo con la referencia basta, y en la lección 7 el mismo dato cabe en el cartel. La ruta relativa no interviene; esto es contenido, no un archivo.</p>
</section>
</main>
<footer><p>Material del departamento de Tecnología para el acto. Copia local, file://.</p></footer>
</body>
</html>A las 17:00 se abre el salón, no el laboratorio. El h1 de la página es el nombre del acto; este taller es un h2. Hay que decir el aforo (120 butacas) y que no se reserva sitio por mensaje: se entra por orden hasta completar. Quien llegue a las 17:20 oye el inicio, así que el primer párrafo no puede depender de un chiste que solo entiende quien estaba en la fila. El enlace interno #apertura permite saltar desde el nav.
Desde esta lección. En el CMS, este bloque es un campo «párrafo» distinto del título. No pegues título y cuerpo en el mismo campo «texto libre».
En el laboratorio de física hay una fotorresistencia de demostración. La página no enciende el sensor: explica la hora (17:30) y el grupo máximo (16 personas). El detalle del pin GPIO se cuenta en la lección 4 con un LED simulado; aquí, en la estructura, basta un párrafo y una lista de dos normas: no tocar la protoboard y anotar la lectura en el cuaderno, no en el móvil de otra persona.
Desde esta lección. En el CMS, este bloque es un campo «párrafo» distinto del título. No pegues título y cuerpo en el mismo campo «texto libre».
Segundo grupo, misma franja, aula de al lado. Si los dos talleres se mezclan en un solo párrafo, nadie sabe a qué puerta ir. Van en sections distintas, cada una con su h2. La temperatura se mide con un sensor digital de demostración del departamento; la página no publica la marca como si fuera un anuncio, solo el lugar y la duración (25 minutos).
Desde esta lección. En el CMS, este bloque es un campo «párrafo» distinto del título. No pegues título y cuerpo en el mismo campo «texto libre».
Si llueve, este bloque se cae. Por eso el texto tiene la alternativa escrita (vídeo de tres gráficos en el salón), no un «ya veremos». En HTML la alternativa es una frase dentro de la misma section, no una imagen que sustituye al aviso. Plano general: el patio está detrás del gimnasio, puerta verde.
Desde esta lección. En el CMS, este bloque es un campo «párrafo» distinto del título. No pegues título y cuerpo en el mismo campo «texto libre».
Al final se apuntan tres números: luz, temperatura y aforo real. Son una lista ordenada si el orden es el del acto, o desordenada si son datos sueltos. Elegimos ol porque se leen en ese orden en la puesta en común. Cada li es una frase corta, no un párrafo disfrazado.
Desde esta lección. En el CMS, este bloque es un campo «párrafo» distinto del título. No pegues título y cuerpo en el mismo campo «texto libre».
Diez minutos. El heading es h2 «Preguntas», no h1: la página ya tiene dueño. Se recuerda que no hay turno de fotos al alumnado. Esa frase es texto, no un icono. Quien imprima la página en blanco y negro tiene que leerla igual.
Desde esta lección. En el CMS, este bloque es un campo «párrafo» distinto del título. No pegues título y cuerpo en el mismo campo «texto libre».
El footer nombra al departamento de tecnología del IES Duero y dice que los textos de esta página son del centro para el acto. No se pega música ni fotos de banco de imágenes. Si más adelante hay un plano, será un SVG hecho en clase. La licencia concreta se estudiará en el bloque B; aquí basta no atribuirse lo que no es del instituto.
Desde esta lección. En el CMS, este bloque es un campo «párrafo» distinto del título. No pegues título y cuerpo en el mismo campo «texto libre».
Calle San Francisco, Aranda de Duero. El autobús urbano deja en la plaza; desde allí, seis minutos a pie. No incrustamos un mapa de un proveedor externo: exige red y cookies. Un párrafo con la referencia basta, y en la lección 7 el mismo dato cabe en el cartel. La ruta relativa no interviene; esto es contenido, no un archivo.
Desde esta lección. En el CMS, este bloque es un campo «párrafo» distinto del título. No pegues título y cuerpo en el mismo campo «texto libre».
| Criterio | Aún no | En proceso | Conseguido | Notable |
|---|---|---|---|---|
| Separación | Un pegote | Título y cuerpo juntos | Bloques con tipo | El orden se lee sin la preview |
| H1 | Varios o ninguno | Uno, pero no el primero | Un h1 arriba | Los h2 son secciones reales |
| Límite | Se cree guardado | No se menciona | Se dice que al recargar se pierde | Se compara con una base de datos |
| Salida | No se mira el HTML | Se mira y no se reconoce | Se reconocen h1, h2, p | Se corregiría una plantilla ajena |
| Rol | Se habla solo de la clave | Se mezcla todo | Redactar ≠ administrar | Se nombra quién haría cada cosa en el centro |
Empieza por el texto en bruto, en el cuaderno, no en el editor. Cuatro líneas bastan: nombre del acto, dónde, cuándo, una norma. Solo después abre el laboratorio y crea un bloque por línea. Si una línea contiene dos datos que podrían cambiar por separado (la hora y el aforo), pártela antes de añadirla. El editor no es el sitio donde se piensa el corte: solo lo registra.
Cuando la lista tenga el h1 arriba y el pie abajo, lee los bloques en voz alta sin mirar la vista previa. Si tropiezas, el orden está mal o falta un h2 que avise del cambio de tema. Sube o baja. Luego sí, mira la vista previa y comprueba que no han aparecido dos títulos grandes. Recarga la página a propósito una vez, para ver desaparecer el trabajo, y vuelve a montarlo en dos minutos. Esa segunda vez sale más corta y es la prueba de que los bloques estaban bien partidos.
En el cuaderno, al margen, escribe tres palabras que un CMS real añadiría y esta página no: usuario, fecha de modificación, borrador. No hace falta simularlas. Hace falta no entregar el ejercicio diciendo que «ya está publicado en el gestor del centro».
Al cerrar la sesión, compara tu lista de bloques con la de otra persona sin mirar la vista previa: si las dos convocatorias se pueden obedecer (saber a qué hora ir y qué norma cumplir), el contenido está partido. Si hace falta el color para entender cuál es el título, el tipo de bloque está mal elegido.
Un CMS separa piezas de contenido y plantilla. Aquí las piezas son bloques en memoria. El HTML de salida se sigue pudiendo leer.
Abre cada pregunta, responde en el cuaderno y después mira la solución. El párrafo «Por qué» es la parte que se estudia.
Respuesta. No. Evita que todo el mundo tenga que escribirlo a mano. Alguien mantiene la plantilla, y esa plantilla es HTML y CSS.
Por qué: Un CMS no evita saber HTML: evita que todo el mundo tenga que escribirlo a mano cada vez. Alguien mantiene la plantilla, y esa plantilla sigue siendo HTML y CSS. Si la plantilla falla, el error se ve en todas las páginas, no en un solo párrafo.
Respuesta. Porque los bloques están en la memoria de la pestaña, no en una base de datos ni en un archivo.
Por qué: Al recargar, el laboratorio pierde los bloques porque viven en la memoria de la pestaña, no en un archivo ni en una base de datos. Un CMS real guardaría el contenido; esta página no finge ese almacén. Anotar esa diferencia es parte de la lección, no un fallo del navegador.
Respuesta. Un oficio claro: título, párrafo, cita, pie. No un trozo a medias ni un color.
Por qué: Un bloque tiene un oficio claro: título, párrafo, cita o pie. Un trozo a medias, un color o un adorno no son un bloque, porque no se pueden reordenar sin romper el sentido. Si no sabes nombrar el oficio, todavía no has separado el contenido de la plantilla.
En la vida real
Escribes y dibujas aquí mismo: no hay salto a otro módulo. La misma herramienta, a pantalla completa, está en l03-cms-concepto-y-editor-de-pagina.html y en el marco (útil si el navegador permite file:// en iframes).
Monta en el laboratorio la convocatoria del acto con un h1, dos h2 y al menos tres párrafos, en un orden que se entienda leyendo solo la lista de bloques. Luego inviértelo a propósito y vuelve a dejarlo bien. En el cuaderno, escribe qué guardaría un CMS de verdad (los campos) y qué no (el color). Una buena entrega no esconde la fecha dentro de un párrafo que habla de otra cosa.
reto_id: bach1-tic-L03