VRV - B100: due richieste di vitti (04/09/2026)

Ricognizione fatta PRIMA di toccare codice, su richiesta di vitti.

Nessun file modificato: qui ci sono solo i numeri e le strade possibili.

Le due richieste sono:

A) il VRV e' chiaro mentre wiz_foto e share sono scuri: portare

il VRV in dark, cosi' la piattaforma ha un feeling solo;

B) rimaneggiare il layout di modifica_post.php per fare posto

al bottone della musica.

Sono indipendenti: si possono fare separate, e conviene.

A) Il dark sul VRV

Come sono vestiti i servizi, oggi

wiz_foto/theme.css dark, con variabili in :root

--bg #1e2127 --panel #2a2e37 --txt #e6e8ec

--accent #2196F3 --gold #eccb8c

share/vrs-chrome.css dark: pannelli traslucidi su sfondo scuro

vv (VRV) CHIARO: verde/carta

--vrv-text #243224 --vrv-accent #3f6b46

pannelli bianchi translucidi rgba(255,255,255,.78)

Il chiaro del VRV non e' un caso: e' il vestito del DIARIO, pensato per

leggersi come carta sopra le foto di sfondo del post.

Quanto costa, in numeri

CSS del VRV: 36 file, 8.309 righe.

Colori scritti a mano (hex o rgba) contro colori presi da variabile:

theme-default.css 114 a mano 0 da variabile

content.css 103 a mano 0

vrv-modifica-post-barra.css 63 a mano 0

theme-default.d/diario.css 58 a mano 0

theme-default.d/vrv_utenti.css 57 a mano 0

theme-default.d/vrv_admin.css 52 a mano 0

theme-default.d/media_popup.css 42 a mano 0

theme-default.d/vv-actions.css 40 a mano 0

vv-editor-toolbar.css 35 a mano 0

vrv-cofanetto.css 33 a mano 0

vrv_modifica_post.css 33 a mano 10

... (altri 25 file, code lunghe)

TOTALE ~880 a mano 24 da variabile

vrv_base.css le variabili le DICHIARA (--vrv-bg-panel, --vrv-text,

--vrv-accent...), ma praticamente nessuno le usa: 24 usi su 8.309 righe.

Il tema non ha un interruttore, ha 880 interruttori.

Le tre strade

1. DARK VERO, fatto bene

Prima si variabilizza (880 colori -> ~20 variabili), poi si scrive il

secondo tema in venti righe. E' il lavoro giusto, ma e' un lavoro di

giorni, non di un pomeriggio, e tocca ogni pagina del diario: il

rischio di sfregiare qualcosa sotto gli occhi di Elena e' alto.

2. DARK SOLO SULLE PAGINE DI LAVORO (consigliata)

Il diario che legge Elena (visualizza_post, diario_lista_guest, il

contenuto con gli sfondi) resta chiaro: e' il prodotto, e il chiaro

e' voluto. Vanno in dark le pagine dove si LAVORA, quelle che oggi

stonano accanto al wizard e allo share:

admin.php, admin_post.php, admin_utenti.php, admin_config.php,

diario_lista_admin.php, profilo.php

Sono le stesse pagine della nota "livrea admin comune". Si riusano

di peso le variabili del wiz_foto, cosi' il feeling e' identico

davvero e non "simile".

Costo: un file nuovo (vrv-admin-dark.css) piu' le poche correzioni

che salteranno fuori. Mezza giornata, e non tocca il diario.

3. MISURARE PRIMA

Prima di decidere, mettere il dark su UNA pagina sola (admin.php) e

guardarla. Un'ora. Se convince si continua con la 2, se non convince

si e' buttata un'ora sola.

Da chiedere a vitti: il dark lo vuole anche sul diario che legge Elena,

o solo sulle pagine di lavoro? La risposta cambia tutto il resto.

RISPOSTA di vitti (04/09/2026): solo le pagine di lavoro,

e admin.php come assaggio. FATTO.

Cosa e' cambiato, in tutto e per tutto:

NUOVO public/vv/css/vrv-admin-dark.css (~290 righe)

TOCCATO public/vv/admin.php (una riga di enqueue

+ un commento aggiornato)

BACKUP admin.php.bak_20260904_134932_darkassaggio

Il file e' un CAPPOTTO, non un tema: si carica per ULTIMO e ridipinge

solo quello che si vede, tutto sotto body.page-admin. Per tornare

indietro si toglie la riga dalla enqueue: non c'e' altro da disfare, e

nessun'altra pagina del VRV se ne accorge.

I colori sono quelli di wiz_foto/theme.css, copiati NEI VALORI:

--vrvd-bg #1e2127 --vrvd-panel #2a2e37 --vrvd-panel2 #333845

--vrvd-txt #e6e8ec --vrvd-mut #9aa3b2 --vrvd-accent #2196f3

--vrvd-gold #eccb8c --vrvd-ok #3fae5a --vrvd-err #e0533d

Non si sono presi i NOMI del wizard apposta: legherebbe due servizi che

oggi non si conoscono. Copiando i valori il feeling e' uguale davvero,

non "simile".

Il wallpaper del VRV RESTA: sopra ci vanno pannelli scuri traslucidi,

come fa il wizard. La foto traspare, il testo si legge.

Cose che il cappotto ha dovuto sistemare, e che torneranno su ogni

pagina che vestiremo:

la variabile --vv-container-alpha da sola non basta: il colore va

riscritto tutto;

e vrv_admin.css poi rischiara i select per rimediare: il cappotto

rifa' il giro una volta sola;

sparivano: stessi ruoli, tinte piene;

ogni regola deve salire di specificita' (body.page-admin ...) per

non farsi scavalcare;

scurito SOLO in admin, cosi' l'assaggio non tocca il resto.

Verifiche fatte: php -l pulito, il CSS risponde 200 (7.825 byte), le

graffe tornano, nessuna variabile usata senza dichiararla. Il collaudo

vero e' guardarla: admin.php da loggato.

Correzione dopo lo sguardo di vitti (04/09, "c'e' una cornice

bianca di troppo")

Il fondo pagina restava bianco. Causa: body.theme-default chiede il

wallpaper con una shorthand background:, e una shorthand AZZERA il

background-color. Se l'immagine non arriva resta il bianco del foglio,

e attorno al pannello scuro si vede una cornice.

Su lab l'immagine non arriva MAI:

/vittrosviaggi_shared/wallpaper/home-default.jpg -> 404 sulla 8443

(il file c'e' sul disco, ma quella porta non serve quella cartella)

Rimesso il solo background-color sul body: scuro dove l'immagine

manca, immagine dove c'e'. html non ha un fondo suo, quindi il browser

lo propaga al foglio intero - niente bianco nemmeno oltre la piega.

Il wallpaper sparito dalle liste - LA CAUSA VERA (04/09)

vitti: "nelle liste ci doveva essere un wallpaper, quello dei cappelli

sulla plancia del Rene', non c'e' piu'". Non era il dark: era cosi' su

TUTTE le pagine del VRV, vestite o no.

La piattaforma lo sfondo lo mette gia' lei, da config, e lo faceva

bene. vrp_service_bg() (platform/lib/vrp_services.php, chiamata dal

boot di piattaforma) bufferizza l'output del servizio e prima di

</head> inietta:

body{background:url("/lab/public/wallpapers/home-default.jpg")

center/cover fixed no-repeat;}

Verificato sull'HTML servito: c'e', ed e' giusto.

Ma theme-default.css cablava a sua volta lo sfondo:

body.theme-default { background: url(

'/vittrosviaggi_shared/wallpaper/home-default.jpg') ... }

body pesa 0,0,1. body.theme-default pesa 0,1,1. Vinceva il tema, e

il suo indirizzo sulla 8443 e' un 404 (quella porta non serve

/vittrosviaggi_shared/). Risultato: pagine nude.

CORRETTO: tolta l'immagine cablata dal tema, che ora dichiara solo il

colore di ripiego. L'immagine la comanda la CONFIGURAZIONE - che e'

anche il posto giusto per cambiarla (pagina Config. della piattaforma,

campo "Sfondo" del servizio: e' da li' che vitti ha rimesso i cappelli)

e vale per tutte le pagine del VRV senza toccare CSS.

TOCCATO public/vv/css/theme-default.css (una riga tolta, un commento)

BACKUP theme-default.css.bak_20260904_..._wallpaperconfig

Da guardare: con lo sfondo tornato, in admin la "cornice di nero un po'

diverso" dovrebbe sparire da sola. Era lo stacco fra il fondo pieno

(#1e2127) e il pannello traslucido (~#20242c): due neri quasi uguali

fanno un alone, mentre sopra una FOTO lo stesso pannello e' esattamente

l'effetto del wizard. Se l'alone resta, si rende il pannello opaco.

Il file ha cambiato nome: vrv-dark.css

Da un file per pagina si e' passati a UN FILE SOLO a sezioni (paletta

comune, poi una sezione per pagina, il nome della sezione e' la classe

del body). Una riga di enqueue per pagina, e togliendola quella pagina

torna chiara.

modifica_post.php - SOLO IL TELAIO (fatto, 04/09)

Vestito: barra dei comandi, tendine, testata col titolo, cornice

dell'editor, modale della nota di salvataggio, segnalibri di

scorrimento, segnaposto del cofanetto.

NON vestito, di proposito:

vestito da content.css: questo file li' dentro non arriva nemmeno

volendo. Ed e' giusto cosi', altrimenti Elena scrive su un colore e

pubblica su un altro.

suo; cambiarlo e' un lavoro a parte, e se va storto Elena non trova

piu' i bottoni. Cosi' com'e' si legge come un foglio con i suoi

ferri, appoggiato su un tavolo scuro. Da guardare insieme: se

stona, si fa in un secondo giro.

Il regalo: vrv_base.css dichiara le --vrv-* e quasi nessuno le usa

(24 volte su 8.309 righe), ma i pochi che le usano sono proprio quelli

che servivano - .vrv-panel e .vrv-panel--strong in vrv_layout.css

(la testata del titolo e la card dell'editor) e i testi in

vrv_components.css. Ridefinite quelle nove variabili, quei pezzi si

sono vestiti da soli.

I bottoni della barra sono un CODICE COLORE (media azzurro, anteprima

rosa, cofanetto marrone, lingue verde, mappa turchese, versioni viola,

salva/chiudi arancio): la tinta NON e' cambiata, e' cambiata solo la

luce - fondo scuro tinto, scritta chiara tinta. Elena li ritrova dove

li lasciava. Stessa cosa per «Butta via la bozza»: era rosso scuro su

chiaro, ora e' rosso chiaro su scuro, ma resta l'unica voce diversa

dalle altre.

Toccato: modifica_post.php (una riga di enqueue).

Backup: modifica_post.php.bak_20260904_171200_darktelaio.

Le prossime, quando vitti da' l'ok all'assaggio

admin_post.php, admin_utenti.php, admin_config.php,

diario_lista_admin.php, profilo.php

ATTENZIONE su modifica_post.php. E' pagina di lavoro, ma dentro ci sta

il FOGLIO del post: l'editor mostra il contenuto con i suoi sfondi

chiari, che sono il diario vero. Li' il dark deve fermarsi al TELAIO

(barra, tendine, cornice) e NON entrare nel foglio, altrimenti Elena

scrive su un colore e pubblica su un altro.

B) Il bottone della musica in modifica_post.php

Com'e' fatta oggi la musica

separati da barra verticale, es.

Pancrazio, Tiberio e Orazio.mp3|Pancrazio, Tiberio e Orazio (1).mp3

oggi: .mp3, .m4a, .mpeg)

basename per sicurezza, e passa la lista a vv_audio.js

nuda, dove i nomi dei file si battono a mano

del cofanetto intero)

Il buco

In modifica_post.php - la pagina dove Elena SCRIVE - della musica non

c'e' traccia. Per mettere una canzone sotto un post bisogna uscire

dall'editor, andare nel pannello del post e battere a mano il nome

esatto del file, virgole e maiuscole comprese. Il 🎵 in alto a destra

non e' questo: e' la Radio VV, la playlist generale del sito

(lib/header_badge.php r.73), e non c'entra col post che si sta

scrivendo.

Com'e' fatta la barra, oggi

modifica_post.php r.317-437, tre gruppi:

[ gruppo edit ] [ versioni ] [ uscita ]

Media... Anteprima Cofanetto v Versioni (n) v Salva/Chiudi v

Lingue v Mappa v

Le tendine sono tutte fatte con lo stesso stampo:

<div class="vrv-dd" id="vrv-XXX-dd">

<button class="vrv-btn vrv-btn--XXX" id="vrv-XXX-btn" aria-expanded>

<div class="vrv-dd__menu vrv-dd__menu--XXX" id="vrv-XXX-menu" aria-hidden>

e le apre TUTTE un solo gestore, js/vrv-modifica-post-barra.js.

Aggiungerne una e' seguire lo stampo, non inventare niente.

Un vincolo da ricordare: vrv-modifica-post-barra.css tiene

padding: 4px 240px 4px 6px

cioe' 240px di rispetto a destra per il badge utente e la Radio VV.

La barra e' gia' a sei comandi: il settimo la manda a capo sugli

schermi stretti. Se si aggiunge "Musica", conviene guardare se

"Media..." e "Anteprima" possono stare loro stessi in una tendina, o

se la Musica sta meglio DENTRO il Cofanetto (che e' gia' il posto dei

dischi).

La strada consigliata

Tendina "Musica" sullo stampo delle altre, con dentro:

per ciascuno (Elena sceglie, non batte a mano)

Cosi' sparisce anche il campo a mano di admin_post.php, o almeno

smette di essere l'unica strada.

Da chiedere a vitti: la scelta dei brani la vogliamo dentro il

Cofanetto (dove stanno gia' i dischi) o come tendina sua nella barra?

RISPOSTA di vitti (04/09/2026) e LAVORO FATTO

"La musica e' per post, non per gruppi di post, quindi nel cofanetto

non va bene". E' un argomento migliore di quello dello spazio: il

cofanetto raggruppa PIU' post, la musica e' di UNO solo - metterla li'

insegnerebbe una cosa falsa. Tendina sua.

Lo SPAZIO non e' stato un problema: nello screenshot della barra c'e'

un buco di ~200px fra «Mappa» e «Versioni» (il gruppo di sinistra ha

flex: 1 1 320px e i bottoni stanno a sinistra). La tendina ci e'

entrata senza toccare niente. Il padding-right: 240px della barra

resta com'era: si potra' rendere condizionale

max(6px, calc(240px - (100vw - min(94vw,1280px))/2))

il giorno che a finestra stretta desse davvero fastidio. Non oggi.

Cosa e' cambiato:

NUOVO lib/musica_widget.php elenco brani + HTML del pannello

NUOVO ajax/post_musica.php l'unica porta che scrive post.musica

NUOVO js/vrv-musica.js spunta, ordina, ascolta, salva

TOCCATO modifica_post.php la tendina + due righe di enqueue

TOCCATO js/vrv-modifica-post-barra.js i QUATTRO elenchi

TOCCATO css/vrv-modifica-post-barra.css livrea chiara del pannello

TOCCATO css/vrv-dark.css livrea scura del pannello

COME FUNZIONA

trenta file in una cartella, il server li ha gia' sottomano. Nessuna

chiamata all'apertura della tendina.

allineati. Spuntare un brano lo manda in fondo alla scaletta,

togliere la spunta lo rimanda fra gli altri in ordine naturale. Le

frecce su/giu' funzionano solo dentro la scaletta.

volta; chiudendo la tendina si ferma).

i nomi separati da barra verticale.

LE ESTENSIONI: non si filtra sul solo .mp3. La cartella ha .m4a (tutti

gli Aizpute) e .mpeg, e ajax/post_audio.php lo dice chiaro - "il campo

post.musica non promette un formato". vv_list_mp3() di lib/audio.php

NON e' stata riusata proprio per questo: filtra mp3 e basta, e avrebbe

fatto sparire meta' archivio dall'elenco.

LA VALIDAZIONE E' UNA SOLA E FA TUTTO: un nome si salva solo se esiste

davvero nella cartella. Cosi' non ci si arriva a scrivere niente di

inventato, e i brani spariti (file rinominato o spostato) non svaniscono

in silenzio: il pannello li mostra marcati "non trovato" e il

salvataggio dice quali ha scartato.

PERMESSI: stesso metro di ajax/cofanetto_azione.php - loggato, e ruolo

admin/editor. (NON quello di update_sfondo.php, che ha i controlli

commentati "lasciare soft": qui si scrive sul post.)

VERIFICATO: php -l pulito sui tre file, node --check sui due js, le

graffe dei css tornano, i QUATTRO elenchi della barra hanno tutti la

voce Musica (righe 52/59/66, 221, 261, 294), l'endpoint da non loggato

risponde "Devi essere loggato", e il pannello del post 146 si stampa con

30 righe di cui 14 in scaletta nell'ordine giusto.

DA COLLAUDARE DAL VIVO: la tendina si apre, si spunta, si salva.

RESTA IL CAMPO A MANO in admin_post.php (r.258): non l'ho tolto. Finche'

la tendina non ha fatto un giro vero e' la via di fuga, e toglierlo e'

una riga il giorno che vitti dice di si'.

B-bis) Le tendine che non si chiudevano (04/09, trovato da vitti)

IL SINTOMO, provato una per una: Cofanetto e Mappa si aprono e si

chiudono col clic sul bottone; Lingue, Versioni e Salva/Chiudi si

aprono, ma per chiuderle bisogna cliccare ovunque TRANNE che sul

bottone.

LA CAUSA: erano proprio quelle tre ad avere DUE gestori addosso.

js/modifica_post.js, dentro initVrvDropdowns(), agganciava

bindDropdown("vrv-lang-dd", ...), ("vrv-versions-dd", ...),

("vrv-exit-dd", ...)

mentre js/vrv-modifica-post-barra.js le aggancia tutte. E i due

tenevano lo stato in due posti diversi: il primo nella classe

.is-open, il secondo nell'attributo aria-hidden. Nel CSS

.vrv-dd.is-open > .vrv-dd__menu pesa 0,4,1

.vrv-dd__menu[aria-hidden="true"] pesa 0,3,1

Al clic su una tendina APERTA: il primo gestore toglieva is-open; il

secondo, vedendo il menu ormai chiuso, lo RIAPRIVA. Cofanetto e Mappa,

con un gestore solo, non avevano il problema.

Era un lavoro lasciato a meta': il commento in quel punto diceva gia'

"NIENTE Cofanetto qui, due gestori si pestano i piedi" - il Cofanetto

era stato staccato, le altre tre no.

LA TRAPPOLA DENTRO LA TRAPPOLA: initVrvDropdowns() in quel file e'

dichiarata DUE VOLTE, e fra due dichiarazioni con lo stesso nome

JavaScript tiene l'ULTIMA. Corretta la prima non sarebbe cambiato

niente. Sono state sistemate entrambe, e sulla copia morta c'e' ora un

avviso che dice che e' morta.

Non si e' perso niente per strada: keepMenuInViewport(), l'unico

extra che bindDropdown dava alla tendina Versioni, e' una funzione

vuota da tempo.

TOCCATO js/modifica_post.js

BACKUP modifica_post.js.bak_20260904_175613_ddoppio

VERIFICATO: node --check pulito, e bindDropdown("...") non e' piu'

chiamata da nessuna parte.

C) «I diari di Elena» - condividere una CATEGORIA, non un post

Chiesto da Elena il 04/09/2026: vuole mandare agli amici tutto il

diario di viaggio, non un articolo alla volta.

Buona notizia: meta' del lavoro e' gia' fatto

diario_lista_guest.php filtra GIA' per categoria, da URL:

diario_lista_guest.php?categoria=viaggi

Il filtro si legge da $_GET['categoria'] (r.63), si ripulisce, e

viene perfino ricordato in un cookie per 90 giorni. Le categorie in

lab, con i post che hanno:

viaggi 10 vittrossera 41

varie 5 elena 2

test 8 (nascosta)

Quindi Elena PUO' GIA' mandare un link solo. Da collaudare: che da

ospite non loggato la pagina si apra e mostri solo i post pubblici

della categoria (il servizio vrv e' dichiarato "auth": "public" nel

suo manifest, quindi dovrebbe).

E la cartolina in home?

Le cartoline della piattaforma NON sono codice: sono un file di

configurazione. platform/config/vrv.json e' tutto qui -

"manifest": { "slug", "label", "icon", "blurb", "url",

"auth", "wallpaper", "self_esci", "enabled" }

Quindi una cartolina «I diari di Elena» che punta a

?categoria=viaggi e' una VOCE, non un lavoro. E la preoccupazione di

vitti ("poi la vorranno anche Mr Heidi, Jerry Luis, UtoOne e

UbiOne...") si rovescia: se ogni cartolina e' una riga di config, farne

una per categoria costa quanto farne una. VittRos Sera ne ha 41, di

post: quella cartolina se la merita piu' di tutte.

FATTO il 04/09/2026 - «I diari di Elena»

NUOVO platform/config/diari.json il manifest della cartolina

TOCCATO platform/boot/env.json una riga nel registro services

BACKUP env.json.bak_20260904_*_diari

Il nome e' quello chiesto da vitti, con la sua correzione: prima aveva

scritto «diarii», poi "mi ero sbagliato". Slug e nome del file sono

diari, cosi' non resta traccia dello sbaglio nemmeno nei percorsi.

La domanda che era aperta ha risposta: 'lib' e' OPZIONALE.

vrp_load_service_libs() fa if ($lib === '') continue; - una

cartolina senza codice suo e' prevista dal caricatore.

⚠️ L'URL TIENE IL .php APPOSTA. vrp_current_service() riconosce il

servizio di una pagina confrontando lo SCRIPT con l'url della targa PIU'

LO SLASH: un url che finisce in .php non puo' vincere quel confronto,

quindi la cartolina non ruba al VRV le sue pagine. Verificato sull'HTML

servito: su ?categoria=viaggi lo sfondo iniettato resta quello del VRV

(i cappelli), non quello della cartolina.

VERIFICATO: i due JSON sono validi, la home risponde 200 e mostra la

cartolina col link giusto, e da ospite non loggato il filtro da' 8 post

su viaggi (34 senza filtro).

Per farne un'altra si copia il file, si cambiano slug/label/url e si

aggiunge la riga in env.json. Il VittRos Sera, con 41 post, la merita.

Nota di servizio, fuori tema

Il backup sacro di stanotte e' andato bene, ma il pruning si e'

fermato su un errore:

rm: impossibile rimuovere

'/mnt/nas_backups/manG3/snapshots/20251116_031000/leNostre/2020/0824 Sentiero Valtellina':

Directory non vuota

Gli snapshot vecchi non si ripuliscono del tutto e col tempo il NAS si

riempie. Da guardare con calma.