Radix
radixphp.se

Releaser & uppdateringar

En översikt av förändringar i Radix. För fullständig historik och taggar/versioner, se GitHub‑releaser.

v1.4.6 Åtgärdat mobilproblem

App Senaste
Åtgärdat mobilproblem där sidan kunde hoppa/blinka vid klick på pagination.
Förbättrat horisontell scrollhantering och touch-beteende i paginationen.

v1.4.5 Cross-Origin-Resource-Policy-stöd i Radix App

App
Denna release uppdaterar Radix App med standardkonfiguration för den nya säkerhetsheadern
Cross-Origin-Resource-Policy som stöds av Radix Frameworks SecurityHeaders middleware.

Syftet är att ge nya Radix-projekt en säkrare grundkonfiguration direkt från start och göra
det enklare att kontrollera hur resurser från applikationen får användas av andra origins.

Ny miljövariabel

Radix App innehåller nu följande rekommenderade standard i .env.example:

SECURITY_CORP=same-origin

Tillåtna värden är:

same-origin
same-site
cross-origin
off

Rekommenderad standard för vanliga installationer är:

SECURITY_CORP=same-origin

Det passar när webb, API och statiska resurser ligger på samma origin, exempelvis:

https://example.com
https://example.com/api/v1/...
https://example.com/assets/...

Konfiguration

Radix App läser nu in SECURITY_CORP via appens säkerhetskonfiguration och skickar värdet
vidare till frameworkets SecurityHeaders middleware.

Om variabeln lämnas tom eller sätts till off sätts ingen Cross-Origin-Resource-Policy-header
av frameworkets middleware.

Apache och statiska filer

För Apache-installationer har public/.htaccess uppdaterats så att statiska resurser kan få
motsvarande header även när de serveras direkt av webbservern.

Det innebär att resurser som JavaScript, CSS, bilder, fonter och manifest kan omfattas av
samma skydd även utan att requesten passerar PHP-applikationen.

Standardvärdet i appens Apache-konfiguration är:

Cross-Origin-Resource-Policy: same-origin

Tester

Testerna för SecurityHeaders middleware har uppdaterats för att stödja den nya
SECURITY_CORP-konfigurationen.

Testsviten verifierar nu både att Cross-Origin-Resource-Policy-headern sätts när
SECURITY_CORP är konfigurerad och att headern inte sätts när värdet saknas eller inte är aktiverat.

Det säkerställer att den nya funktionen fungerar utan att bryta befintligt beteende för CSP,
HSTS och övriga säkerhetsheaders.

När ska andra värden användas?

Använd same-site om applikationen är uppdelad över flera subdomäner inom samma site,
till exempel:

https://app.example.com
https://api.example.com
https://static.example.com

Använd cross-origin endast om resurser från applikationen behöver kunna användas av
externa domäner.

Använd off om headern inte ska sättas av Radix Frameworks SecurityHeaders middleware.

Bakåtkompatibilitet

Ändringen är bakåtkompatibel för befintliga applikationer.

Projekt som redan har en egen .env påverkas inte automatiskt förrän SECURITY_CORP läggs
till eller konfigureras. Nya projekt som skapas från denna starter får däremot en
rekommenderad säker standard direkt via .env.example.

Rekommendation

För de flesta Radix App-installationer rekommenderas:

SECURITY_CORP=same-origin

Om applikationen använder CDN, externa bilddomäner, inbäddade resurser eller flera
subdomäner bör värdet ses över utifrån den faktiska deploymentsituationen.

v1.2.7 Fix: SecurityHeaders

Framework
Liten fix i middleware SecurityHeaders tagit tagit bort dublicerade setHeaders.

v1.2.6 Säkerhet: stöd för Cross-Origin-Resource-Policy

Framework
Denna release lägger till stöd för att konfigurera HTTP-headern Cross-Origin-Resource-Policy
via Radix SecurityHeaders middleware.

Headern kan användas för att styra hur resurser från applikationen får användas av andra
origins, och ger ett extra skyddslager mot oönskad cross-origin-användning av resurser.

Ny valfri miljövariabel: SECURITY_CORP=same-origin

Tillåtna värden:

same-origin
same-site
cross-origin
off

Rekommenderad standard för vanliga installationer är same-origin.

Det passar när webb, API och statiska resurser ligger på samma origin, exempelvis:

https://example.com
https://example.com/api/v1/...
https://example.com/assets/...

Använd same-site om applikationen är uppdelad på flera subdomäner inom samma site,
exempelvis:

https://app.example.com
https://api.example.com
https://static.example.com

Använd cross-origin endast om resurser från applikationen behöver kunna användas av
externa domäner.

Använd off om headern inte ska sättas av frameworkets SecurityHeaders middleware.

Ändringen är bakåtkompatibel. Befintliga applikationer som saknar SECURITY_CORP
påverkas inte automatiskt. Headern sätts endast när värdet är konfigurerat.

EnvValidator har uppdaterats för att validera SECURITY_CORP när variabeln är satt.
Ogiltiga värden stoppas tidigt med ett tydligt konfigurationsfel.

Testsviten har utökats för att säkerställa att SECURITY_CORP=same-origin accepteras, att
ogiltiga värden nekas och att befintlig bakåtkompatibilitet bibehålls.

För de flesta projekt rekommenderas:

SECURITY_CORP=same-origin

Om Apache eller annan webbserver används för att servera statiska filer direkt kan
motsvarande header även sättas på webbservernivå för att även omfatta exempelvis
JavaScript, CSS, bilder och fonter.

v1.4.4 Frontend uppdatering

App
Updatering av js tooltip för att fungera inuti tables.

Uppdatering av devDependencies i package.json.

v1.4.3 Liten csp fix för e-postblockering.

App
Tagit bort style och script i ta bort e-postblockering för csp.

v1.4.2 CSP, canonical URL och neutral pagination

App
Den här uppdateringen förbereder Radix App för striktare CSP, bättre canonical URL-hantering och den nya framework-neutrala
pagination-renderingen i radix-framework.

Canonical URL via middleware
Radix App använder nu frameworkets CanonicalUrl-middleware:

'canonical.url' => \Radix\Middleware\Middlewares\CanonicalUrl::class

Middlewaret aktiveras på webbroutes och använder APP_URL som canonical källa.

Exempel:

APP_URL=https://example.com

Om en request kommer in på fel host eller scheme kan middlewaret redirecta till den URL som motsvarar APP_URL.

Canonical middleware är aktiverad för webbroutes, men inte för API-routes. Det gör att API-anrop undviker onödiga redirects,
vilket är bättre om API:et senare används av externa klienter.

Striktare CSP
CSP-konfigurationen för webben är nu striktare och tillåter inte längre inline CSS:

style-src 'self'

Det innebär att inline-style som exempelvis style="display:none" och style="line-height:1" har tagits bort eller ersatts med
CSS-klasser.

Scripts använder fortsatt nonce via csp_nonce().

Pagination-styling flyttad till Radix App
radix-framework renderar nu pagination med framework-neutrala Radix-klasser i stället för Tailwind utility-klasser och inline-style.

Radix App innehåller styling för dessa klasser.

Klasser som används:

radix-pagination
radix-pagination--mobile
radix-pagination--desktop
radix-pagination__inner
radix-pagination__link
radix-pagination__link--active
radix-pagination__link--disabled
radix-pagination__link--first
radix-pagination__link--previous
radix-pagination__link--next
radix-pagination__link--last
radix-pagination__ellipsis
Det gör att radix-framework inte längre behöver anta Tailwind, medan Radix App fortfarande får färdig styling.

Både server-renderad pagination och JavaScript-renderad pagination har uppdaterats för att använda samma
Radix pagination-klasser.

Honeypot och CSP
Honeypot-fält använder nu CSS-klass i stället för inline-style.

Exempel:

class="radix-honeypot"

Radix App döljer fältet via CSS, vilket gör honeypot-helpern kompatibel med strikt CSP.

.htaccess och webroot
Root-.htaccess finns kvar som fallback för enklare webbhotell där document root inte kan sättas till public/.

Rekommenderad setup är fortfarande att peka serverns document root direkt till public/.

Men om det inte går skickar root-.htaccess requests vidare internt till public/.

Uppdaterad ansvarsfördelning
Den här releasen tydliggör uppdelningen mellan framework och app:

radix-framework

CanonicalUrl middleware
pagination-logik
neutral pagination-markup
CSP-vänliga helpers
radix-app

aktiverar middleware
sätter APP_URL
stylar pagination med Tailwind/CSS
innehåller .htaccess-fallback
tillhandahåller appens frontendstruktur
Att tänka på vid uppgradering
Om du har egna vyer eller egen CSS som förlitar sig på gamla pagination-klasser som pager-base, pager-active, pager-disabled
eller Tailwind-klasser direkt från frameworkets HTML-output behöver du uppdatera stylingen till de nya radix-pagination*-klasserna.

Efter uppdatering, kör:

composer update

npm install

npm run build

Om autoloadade helpers har ändrats kan även detta vara bra:

composer dump-autoload

v1.2.5 Canonical URL middleware, Redirect responses

Framework
Redirect responses
RedirectResponse har uppdaterats för att stödja valfri redirect-statuskod.

Tidigare skickade RedirectResponse alltid 302. Den kan nu ta emot en andra parameter för statuskod, med
fortsatt bakåtkompatibel default på 302.

Exempel:

new RedirectResponse('/login') ger 302
new RedirectResponse('/new-url', 301) ger 301
Även redirect()-helpern har uppdaterats på samma sätt:

redirect('/login') ger 302
redirect('/new-url', 301) ger 301
Statuskoden valideras så att endast redirect-koder inom intervallet 300–399 accepteras.

Detta gör det möjligt att använda permanenta redirects utan att behöva bygga en vanlig Response manuellt.

Canonical URL middleware
Ett nytt middleware har lagts till:

Radix\Middleware\Middlewares\CanonicalUrl

Middlewaret använder APP_URL som canonical URL och redirectar inkommande requests till rätt scheme och host när de inte matchar.

Exempel:

APP_URL=https://example.com

En request till:

http://www.example.com/about

redirectas permanent till:

https://example.com/about

Redirecten använder 301 via RedirectResponse.

Middlewaret hanterar bland annat:

canonical scheme och host från APP_URL
case-insensitive jämförelse av scheme och host
HTTPS=on, HTTPS=ON, HTTPS=1 och HTTPS som integer 1
HTTP_X_FORWARDED_PROTO=https
host med port, t.ex. example.com:8080
saknad eller ogiltig APP_URL
saknad eller ogiltig current host
tom eller icke-sträng REQUEST_URI
lokal utvecklingsmiljö där redirect ska undvikas
Följande hosts behandlas som lokala och redirectas inte:

localhost
127.0.0.1
*.test
*.local
Exempel på registrering som middleware-alias:

'canonical' => \Radix\Middleware\Middlewares\CanonicalUrl::class

Exempel på användning:

$router->middleware('canonical')

eller som del av en middlewaregrupp, t.ex. web.

Pagination
Pagination-renderingen i paginate_links() har uppdaterats för att vara mer framework-neutral och bättre kompatibel med strikt CSP.

Tidigare renderades pagination med Tailwind-specifika utility-klasser och inline-style, t.ex. style="line-height:1". Det är nu borttaget.

paginate_links() renderar nu semantiska Radix-klasser i stället:

radix-pagination
radix-pagination--mobile
radix-pagination--desktop
radix-pagination__inner
radix-pagination__link
radix-pagination__link--active
radix-pagination__link--disabled
radix-pagination__link--first
radix-pagination__link--previous
radix-pagination__link--next
radix-pagination__link--last
radix-pagination__ellipsis
Det gör att radix-framework inte längre förutsätter Tailwind för paginationens markup. Styling kan i stället läggas i
applikationen, t.ex. i radix-app.

Exempel på enkel CSS-styling i en app:

.radix-pagination { display: flex; justify-content: center; }

.radix-pagination__inner { display: flex; align-items: center; gap: 0.25rem; }

.radix-pagination__link { display: inline-flex; align-items: center; justify-content: center; min-width: 2.25rem; height: 2.25rem; padding: 0 0.75rem; border-radius: 0.375rem; text-decoration: none; }

.radix-pagination__link--active { font-weight: 600; }

.radix-pagination__link--disabled { opacity: 0.5; pointer-events: none; }

.radix-pagination__ellipsis { padding: 0 0.5rem; }

Honeypot helper
honeypot_field() har uppdaterats för att vara kompatibel med strikt CSP.

Tidigare renderades honeypot-fält med inline-style, t.ex. style="display:none;".

Det har ersatts med en CSS-klass:

radix-honeypot

Applikationen ansvarar för att dölja fältet via CSS.

Exempel:

.radix-honeypot { display: none; }

Det gör att helpern kan användas tillsammans med en CSP som inte tillåter inline CSS, t.ex. style-src 'self'.

CSP-kompatibilitet
Flera delar har uppdaterats för att fungera bättre med striktare Content Security Policy.

Fokus har varit att ta bort inline-style från framework-genererad HTML och i stället använda semantiska klasser som
applikationen kan styla själv.

Detta påverkar framför allt:

pagination via paginate_links()
honeypot-fält via honeypot_field()
redirect-flöden där permanenta redirects nu kan skapas direkt med RedirectResponse
Quality
Ändringarna har täckts med tester för både normalfall och edge cases.

Följande har körts och verifierats:

composer stan
composer test
composer infect
Tester har lagts till för bland annat:

default redirect-status 302
explicit permanent redirect 301
redirect-statusens gränsvärden 300 och 399
ogiltiga redirect-statuskoder
canonical redirects
pass-through när request redan matchar canonical URL
lokal utvecklingsmiljö
proxy headers
uppercase scheme/host/header-värden
saknade eller ogiltiga servervärden
pagination-rendering utan Tailwind-specifika klasser och inline styles
honeypot-rendering utan inline styles

v1.4.1 Förbättrad struktur för assets och uploads

App
Den här releasen uppdaterar Radix App med en tydligare och säkrare standardstruktur för
publika frontend-assets och användaruppladdningar.

Nytt och förbättrat
Appens egna frontend-assets ligger nu samlat under:

public/assets
CSS och JavaScript byggs nu till:

public/assets/css/app.css
public/assets/js/app.js
Favicons ligger nu under:

public/assets/favicons
Statisk app-grafik, till exempel default-avatar, ligger nu under:

public/assets/images/graphics
Användaruppladdningar ligger nu separat under:

public/uploads
Uppladdade avatarer sparas som standard under:

public/uploads/users/{id}/avatar.jpg
Default-avatar använder nu:

/assets/images/graphics/avatar.png
versioned_file() används nu konsekvent med nya asset-paths:

versioned_file('/assets/css/app.css')
versioned_file('/assets/js/app.js')
versioned_file('/assets/images/graphics/avatar.png')

v1.2.4 Förbättrad view-cache och asset-hantering

Framework
Den här releasen förbättrar RadixTemplateViewer och versioned_file() för mer flexibel och robust hantering av frontend-assets.

Nytt och förbättrat
versioned_file() är nu mer generell och stödjer dynamiska paths bättre.
Assets kan placeras i t.ex. /assets/css, /assets/js, /build och /dist.
View-cache-key påverkas nu av relevanta CSS/JS/MJS-assets.
Asset-signaturen skannar endast relevanta asset-kataloger och ignorerar tunga mappar som uploads, images och media.
Asset-signaturen cache:as per viewer-instans för bättre prestanda.
Förbättrad stabilitet mellan Linux och Windows genom konsekvent path-normalisering.
Filter-cache-key inkluderar nu både filternamn och filtertyper.

Cache
View-cache ligger fortsatt som standard i:

text ROOT_PATH/cache/views

VIEWS_CACHE_PATH stöds fortfarande, och APP_ENV=dev/development inaktiverar fortsatt view-cache.

Kvalitet
Verifierat med:

PHPUnit grönt
PHPStan grönt
Infection på RadixTemplateViewer: 5153/5153 mutanter dödade, 100% MSI

Bakåtkompatibilitet
versioned_file() har nu tom sträng som standardfallback. För specifika fallback-värden, ange dem explicit:

php versioned_file($avatarPath, '/images/graphics/avatar.png')
Saknar du en detalj här? Se GitHub‑releaser för komplett historik.

Cookies & integritet

Vi använder nödvändiga cookies för grundfunktioner och säkerhet (t.ex. att komma ihåg ditt val här och skydda formulär). Om du använder administrativa delar kan sessionscookies även förekomma vid inloggning. Läs mer.