La capa de sitios web se configura con unas pocas claves encima de las que ya leen Teams y la base. Configura primero esas —Configure teams y The environment file— y luego las de abajo.
APP_URL decide cuál dominio es el tuyo
Aquí APP_URL es más que la raíz de tus enlaces. Su host es el dominio propio de la aplicación: el único en el que responden el panel de administración, /app, la página de inicio y las páginas de funciones. Cualquier otro host que llegue a la aplicación se lee como la dirección del sitio de un equipo. Ponle el host exacto que sirves, sin www.:
APP_URL=https://builder.example.com
Una petición a un host que no coincide con ningún equipo se devuelve a APP_URL con ?error=site_not_configured. Cómo un host se convierte en un equipo se explica en El sitio público.
Variables de entorno
| Variable | Valor por defecto | Qué hace |
|---|---|---|
CLOUD_FLARE_TOKEN |
vacío | Token de la API de Cloudflare que crea y borra el registro CNAME de cada subdominio gratuito. Lo lee config/services.php. |
PLOI_API_KEY |
vacío | Clave de la API de Ploi que agrega cada subdominio gratuito a tu sitio en Ploi y pide su certificado. |
PLOI_SERVER_ID |
vacío | El servidor de Ploi que corre la aplicación. |
PLOI_SITE_ID |
vacío | El sitio de Ploi que responde por el dominio de cada equipo. Cada subdominio gratuito se le agrega como tenant. |
MULTIMEDIA_ENABLE_MASK |
false |
Con true, el sitio de un equipo sirve los archivos de su biblioteca bajo su propio dominio, en /media/.... Con false esa ruta responde 404. |
Sin los valores de Cloudflare y Ploi el resto del builder sigue funcionando: un equipo aún puede guardar un subdominio gratuito, pero no se crea ningún registro DNS, entrada en el servidor ni certificado para él. Con ellos, eso se crea solo para un subdominio gratuito que tiene un registro de dominio, y hoy ninguna pantalla crea ese registro. Consulta Dominios y SSL.
config/app.php
'project' => 'weblabor-builder',
'available_domains' => [
['domain' => 'example.com', 'zone_id' => 'your-cloudflare-zone-id'],
['domain' => 'example.net', 'zone_id' => 'another-zone-id'],
],
| Clave | Qué hace |
|---|---|
project |
La carpeta de la que se leen este centro de ayuda y las páginas de funciones. Cámbiala cuando tu producto tenga su propio nombre, y copia las carpetas con ella. |
available_domains |
Los dominios base de los que un equipo puede tomar un subdominio gratuito, cada uno con el id de su zona de Cloudflare. El equipo elige uno en el selector de dominio; el id de zona es donde se escribe su registro CNAME. El kit viene con los dominios de Weblabor en esta lista: reemplázalos por los tuyos. |
El editor de páginas es un complemento
Escribir páginas se comprueba contra los complementos del equipo con la clave de función pages, mediante el mismo $team->hasFeature() que Teams usa para cualquier capacidad. Un equipo que lo tiene crea, edita y respalda sus páginas en /team/pages. A un equipo que no lo tiene se le niega toda acción sobre páginas, y su sitio muestra las páginas del tema por defecto en lugar de las suyas, así que nunca queda en blanco.
Las claves que se le pueden vender a un equipo son los métodos públicos de App\Classes\TeamPlanFeatures, y el kit trae esa clase vacía. Para vender el editor, o incluirlo en un plan, decláralo ahí:
namespace App\Classes;
class TeamPlanFeatures extends BasePlanFeatures
{
public function pages()
{
return true;
}
}
Después crea el complemento en el panel de administración con pages como su función, y asígnalo a los planes que lo incluyen. Cómo se ponen precio y se otorgan los complementos está en Sell add-ons, en el sitio de la base; cómo se asignan a un equipo está en Team plans and billing, en el sitio de Teams.
Interruptores que cada equipo activa por su cuenta
Los formularios y los campos personalizados no los configuras tú: cada equipo los enciende en Características dentro de /team/settings. Consulta Configuración del sitio y visitantes.
Los permisos que agrega la capa de sitios web
Las pantallas de páginas, formularios, registros, campos personalizados y visitantes son recursos del guard team, y sus permisos se generan a partir de ellos: retrieve page, create page, update page, delete page, y los mismos cuatro verbos para form, form_entry, form_entry_input, custom_field y team_visitor donde la pantalla permite la acción. form_entry_input decide quién lee los campos de un registro. Genéralos después de instalar, y otra vez después de agregar un recurso tuyo:
php artisan db:seed --class=PermissionSeeder
El rol de dueño de un equipo recibe todos los permisos de equipo que existen cuando se crea el equipo. Dáselos a otros roles desde /team/roles, como explica Team roles and permissions.
La cola
Las páginas por defecto de un equipo nuevo, y cada paso del aprovisionamiento de un subdominio gratuito, cuando corre —la entrada en el servidor, la solicitud del certificado y su comprobación— corren como trabajos en cola. Mantén un worker de la cola corriendo, como describe Deploy your project, o esos pasos se quedan esperando.