El contrato de control de acceso
La única regla que toda integración debe cumplir.
La regla
Nunca renderices contenido de curso o lección sin preguntar a POM LMS si el usuario actual puede verlo.
if ( ! pom_lms_user_can_access_lesson( $lesson_id ) ) {
return '';
}Esto se aplica a los shortcodes, widgets, bloques, módulos de maquetadores de páginas, respuestas REST, feeds, resultados de búsqueda que incluyen contenido, exportaciones y cualquier cosa que incluya el texto de la lección o URLs de vídeo en un correo electrónico.
Por qué no puede reimplementarse
El acceso no es una bandera. Es una precedencia:
- Si el curso exige iniciar sesión y el visitante no ha iniciado sesión — no.
- En caso contrario, si se aplica una regla de permiso — la regla decide, y no se consulta nada más.
- En caso contrario, si el curso es de pago — la compra decide.
- En caso contrario — sí.
Las lecciones añaden su propia capa por encima, con las lecciones de vista previa como una excepción deliberada.
Cualquier integración que compruebe «¿este curso es de pago y lo compró?» resuelve mal el caso de la regla, y cualquiera que compruebe primero la regla resuelve mal la barrera de inicio de sesión. Los helpers existen precisamente para que haya una única implementación de este orden.
Si la precedencia cambia en una versión futura, el código que llama a los helpers la sigue. El código que la reimplementa empieza a filtrar contenido silenciosamente.
Los dos helpers
| Llamada | Para |
|---|---|
pom_lms_user_can_access_course( $course_id ) |
Contenido de curso |
pom_lms_user_can_access_lesson( $lesson_id, $course_id = 0 ) |
Contenido de lección |
Ambos devuelven un booleano, ambos se refieren al usuario actual y ambos son seguros de llamar con visitantes que no han iniciado sesión.
Usa el helper de lección para el contenido de lección incluso cuando ya sepas que el curso es accesible — las lecciones llevan anulaciones y banderas de vista previa de las que el helper de curso no sabe nada.
Solo responden por el usuario actual
Ninguno de los dos helpers acepta un ID de usuario. Evalúan la solicitud actual.
Esto tiene una consecuencia práctica: no puedes usarlos en un trabajo en segundo plano, una tarea de cron o un envío de correo electrónico para preguntar si otro usuario tiene acceso. No hay una forma compatible de responder esa pregunta para un usuario arbitrario, y construirla leyendo los datos subyacentes reimplementa la precedencia — justo lo que este contrato existe para evitar.
Diseña las integraciones para comprobar el acceso en el momento de la renderización, en la propia solicitud del visitante.
Protege la propia función
POM LMS puede no estar activo. Falla cerrado:
if ( ! function_exists( 'pom_lms_user_can_access_course' ) ) {
return '';
}Devolver contenido porque falta el helper es el peor modo de fallo posible.
Qué debe ser una respuesta bloqueada
No inventes tu propio mensaje. Si estás sustituyendo contenido que el plugin habría bloqueado, o bien:
- no devuelvas nada y deja que se aplique el manejo de «sin acceso» de la propia página; o
- renderiza el texto de «sin acceso» configurado en el curso, que es el mensaje que el propietario del sitio escribió exactamente para esta situación.
Inventar un tercer mensaje significa que los propietarios del sitio tienen un texto que no pueden encontrar y no pueden cambiar.
Las vistas previas son contenido, no pruebas
Una lección marcada como vista previa es accesible para todo el mundo, incluidos los visitantes que no han iniciado sesión. Si tu integración muestra lecciones, espera que las lecciones de vista previa superen la comprobación de acceso para solicitudes anónimas — ese es el comportamiento correcto, no un error que haya que sortear.