O adresă absolută de imagine ar strica og:image și datele structurate

Schema de validare acceptă ca imagine de produs o adresă absolută http(s)://, dar cele două locuri care construiesc adresa finală presupun amândouă o cale internă și lipesc originul în față. Rezultatul ar fi https://hyperice.mdhttps://cdn.exemplu/poza.png — și în og:image, și în datele structurate.

Ce am găsit

backend/src/lib/schemas.ts:57-64:

const assetPath = z
  .string()
  .trim()
  .min(1, VALIDATION.required)
  .refine(
    (value) => value.startsWith('/') || /^https?:\/\//.test(value),
    VALIDATION.assetPath,
  );

Cele două locuri care nu se așteaptă la asta:

• backend/src/services/page-meta.ts — fileUrl(p) => \{origin}{p}``
• backend/src/services/render-page.ts:138 — \{origin}{meta.image ?? DEFAULT_SHARE_IMAGE.path}``

Nu e viu. Verificat pe API-ul de producție: 31 de produse publicate, zero cu adresă absolută, zero cu /uploads/. Se declanșează doar dacă cineva lipește în panou o adresă completă într-un câmp de imagine — ceea ce schema îi permite azi.

De făcut

• Decide care e regula: ori imaginile de produs sunt doar căi interne și schema se strânge, ori adresele absolute sunt permise și amândouă locurile de construcție le respectă
• Aplică decizia în ambele locuri deodată — reparat într-unul singur, celălalt rămâne cu aceeași greșeală și devine mai greu de văzut
• Test care trece o adresă absolută prin randare și verifică ce iese

Criteriu de acceptare

O imagine de produs cu adresă absolută fie e respinsă la validare cu mesaj clar, fie ajunge neschimbată în og:image și în image-ul din JSON-LD. Niciun caz nu mai produce o adresă lipită.

Desprins din #31 (closed), unde a fost găsit la auditul apariţiilor.