Releaser & uppdateringar
En översikt av förändringar i Radix. För fullständig historik och taggar/versioner, se GitHub‑releaser.
v1.5.0 Uppdaterad till Radix Framework v1.2.8
App Senaste
Radix App har uppdaterats till Radix Framework v1.2.8.
Den här uppdateringen innehåller framför allt förbättringar i ORM-lagret, med bättre stöd
för relationer, constrained loading och QueryBuilder på relationer.
Uppdaterat
Uppdaterat Radix Framework till v1.2.8.
Uppdaterat ORM-dokumentationen för att spegla de nya relationsförbättringarna.
Förtydligat hur load(), loadMissing(), eager loading och relationer med QueryBuilder fungerar.
ORM-förbättringar
Radix ORM har fått mer konsekvent hantering av relationer.
Förbättringar inkluderar:
bättre relationsstatus via relationLoaded()
möjlighet att rensa laddade relationer med unsetRelation() och withoutRelations()
säkrare kontroll av relationsmetoder
bättre stöd för load() och loadMissing()
query-stöd på centrala relationstyper
tydligare hantering av one/many-relationer
Relationer som nu har förbättrat query-stöd:
HasMany
HasOne
BelongsTo
BelongsToMany
HasManyThrough
HasOneThrough
Constrained loading
Relationer kan nu användas tydligare med QueryBuilder-constraints:
$user->load([
'posts' => function (QueryBuilder $query): void {
$query->where('published', '=', 1);
},
]);
Many-relationer lagras som Collection.
One-relationer lagras som Model|null.
Dokumentation
docs/ORM.md har uppdaterats med:
relationsexempel
relation state
isOne() / isMany()
QueryBuilder-constraints
skillnaden mellan relationsobjekt och laddad relationsdata
exempel för load(), loadMissing() och eager loading
Teststatus i frameworket
Radix Framework v1.2.8 är verifierad med:
PHPUnit: grönt
PHPStan: grönt
GitHub Actions: grönt
Infection: 5360 / 5360 mutanter dödade
Mutation Code Coverage: 100%
Covered Code MSI: 100%
Rekommenderat efter uppdatering
Kör:
composer update
composer dump-autoload
Och verifiera appen med:
composer test
composer stan
Den här uppdateringen innehåller framför allt förbättringar i ORM-lagret, med bättre stöd
för relationer, constrained loading och QueryBuilder på relationer.
Uppdaterat
Uppdaterat Radix Framework till v1.2.8.
Uppdaterat ORM-dokumentationen för att spegla de nya relationsförbättringarna.
Förtydligat hur load(), loadMissing(), eager loading och relationer med QueryBuilder fungerar.
ORM-förbättringar
Radix ORM har fått mer konsekvent hantering av relationer.
Förbättringar inkluderar:
bättre relationsstatus via relationLoaded()
möjlighet att rensa laddade relationer med unsetRelation() och withoutRelations()
säkrare kontroll av relationsmetoder
bättre stöd för load() och loadMissing()
query-stöd på centrala relationstyper
tydligare hantering av one/many-relationer
Relationer som nu har förbättrat query-stöd:
HasMany
HasOne
BelongsTo
BelongsToMany
HasManyThrough
HasOneThrough
Constrained loading
Relationer kan nu användas tydligare med QueryBuilder-constraints:
$user->load([
'posts' => function (QueryBuilder $query): void {
$query->where('published', '=', 1);
},
]);
Many-relationer lagras som Collection.
One-relationer lagras som Model|null.
Dokumentation
docs/ORM.md har uppdaterats med:
relationsexempel
relation state
isOne() / isMany()
QueryBuilder-constraints
skillnaden mellan relationsobjekt och laddad relationsdata
exempel för load(), loadMissing() och eager loading
Teststatus i frameworket
Radix Framework v1.2.8 är verifierad med:
PHPUnit: grönt
PHPStan: grönt
GitHub Actions: grönt
Infection: 5360 / 5360 mutanter dödade
Mutation Code Coverage: 100%
Covered Code MSI: 100%
Rekommenderat efter uppdatering
Kör:
composer update
composer dump-autoload
Och verifiera appen med:
composer test
composer stan
v1.4.9 Uppdaterad och synkad dokumentation
App
Den här releasen fokuserar på att göra dokumentationen mer komplett, konsekvent och
bättre anpassad till nuvarande Radix App/Radix Framework-struktur.
Ändrat
Uppdaterat dokumentationen under docs/ med tydligare uppdelning mellan:
radix-app som starter-applikation
radix-framework som Composer-baserat framework
Förtydligat installation, CLI, scaffolds och rekommenderade startflöden.
Dokumenterat säkrare scaffold-flöden med:
--force-placeholders
--all
--dry-run
försiktigare användning av --force
Uppdaterat dokumentation för:
routing
controllers
middleware
HTTP
databas, migrations och seeders
ORM
validation
templates
frontend
images och uploads
files
services och dependency injection
events och listeners
cache
logging
mail
security
API
geolocation
testing
Uppdaterat README med mer komplett översikt över:
installation
CLI
scaffolds
frontend
public assets och uploads
utveckling/test
kort deployment-flöde
Uppdaterat CI-dokumentationen i github-settings/ så lokala kommandon fungerar bättre
när de körs direkt från markdown-filer i github-settings/.
Justerat Infection-kommandon till att använda:
composer infect:pcov
composer infect:xdebug
Undviker nu det generella composer infect i CI-dokumentationen eftersom projektets
wrapper kräver explicit mode.
Lagt till exempel med:
composer -d ..
npm --prefix ..
så kommandon fungerar även när terminalen står i github-settings/.
Varför
Målet är att dokumentationen ska vara lättare att följa för nya projekt, tydligare vid
scaffold-installation och mer korrekt i förhållande till hur Radix App faktiskt används
tillsammans med Radix Framework.
Dokumentationen skiljer nu tydligare mellan appens ansvar och frameworkets ansvar, vilket
gör det enklare att förstå vad som ska ändras i appen och vad som kommer från
Composer-paketet.
Rekommenderat efter uppdatering
Kör gärna grundkontrollerna:
composer format:check
composer stan
composer test
Vid behov, kör mutation testing med explicit driver:
composer infect:pcov
eller:
composer infect:xdebug
bättre anpassad till nuvarande Radix App/Radix Framework-struktur.
Ändrat
Uppdaterat dokumentationen under docs/ med tydligare uppdelning mellan:
radix-app som starter-applikation
radix-framework som Composer-baserat framework
Förtydligat installation, CLI, scaffolds och rekommenderade startflöden.
Dokumenterat säkrare scaffold-flöden med:
--force-placeholders
--all
--dry-run
försiktigare användning av --force
Uppdaterat dokumentation för:
routing
controllers
middleware
HTTP
databas, migrations och seeders
ORM
validation
templates
frontend
images och uploads
files
services och dependency injection
events och listeners
cache
logging
security
API
geolocation
testing
Uppdaterat README med mer komplett översikt över:
installation
CLI
scaffolds
frontend
public assets och uploads
utveckling/test
kort deployment-flöde
Uppdaterat CI-dokumentationen i github-settings/ så lokala kommandon fungerar bättre
när de körs direkt från markdown-filer i github-settings/.
Justerat Infection-kommandon till att använda:
composer infect:pcov
composer infect:xdebug
Undviker nu det generella composer infect i CI-dokumentationen eftersom projektets
wrapper kräver explicit mode.
Lagt till exempel med:
composer -d ..
npm --prefix ..
så kommandon fungerar även när terminalen står i github-settings/.
Varför
Målet är att dokumentationen ska vara lättare att följa för nya projekt, tydligare vid
scaffold-installation och mer korrekt i förhållande till hur Radix App faktiskt används
tillsammans med Radix Framework.
Dokumentationen skiljer nu tydligare mellan appens ansvar och frameworkets ansvar, vilket
gör det enklare att förstå vad som ska ändras i appen och vad som kommer från
Composer-paketet.
Rekommenderat efter uppdatering
Kör gärna grundkontrollerna:
composer format:check
composer stan
composer test
Vid behov, kör mutation testing med explicit driver:
composer infect:pcov
eller:
composer infect:xdebug
v1.4.8 Förbättrad mobilstabilitet för header och paginering
App
Stabiliserat sidhuvudet på mobila enheter genom att använda fast positionerad header med
konsekvent höjd.
Minskat visuella hopp och korta vita flashar vid mobil paginering, sidledsswipe och navigering.
Infört gemensam headerhöjd via --header-h för mer konsekvent layout mellan olika vyer.
Justerat innehållets toppavstånd så det anpassas efter den fasta headern.
Förbättrat vertikal centrering av navigation och headerinnehåll.
Lagt till renderingstabilisering för fixed/sticky-liknande element på mobila webbläsare.
Minskat horisontell overscroll för att undvika oönskade visuella effekter vid touchinteraktion.
Förbättrat sidebar-layoutens anpassning till den fasta headern där sidebar används.
konsekvent höjd.
Minskat visuella hopp och korta vita flashar vid mobil paginering, sidledsswipe och navigering.
Infört gemensam headerhöjd via --header-h för mer konsekvent layout mellan olika vyer.
Justerat innehållets toppavstånd så det anpassas efter den fasta headern.
Förbättrat vertikal centrering av navigation och headerinnehåll.
Lagt till renderingstabilisering för fixed/sticky-liknande element på mobila webbläsare.
Minskat horisontell overscroll för att undvika oönskade visuella effekter vid touchinteraktion.
Förbättrat sidebar-layoutens anpassning till den fasta headern där sidebar används.
v1.4.7 Uppdateringar javascript pagination
App
Uppdaterar javascript pagination till att använda radix-framework klasserna.
Uppdaterat färgschemat för search-profiles.
Uppdaterat färgschemat för search-profiles.
v1.4.6 Åtgärdat mobilproblem
App
Åtgärdat mobilproblem där sidan kunde hoppa/blinka vid klick på pagination.
Förbättrat horisontell scrollhantering och touch-beteende i paginationen.
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.
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.4.4 Frontend uppdatering
App
Updatering av js tooltip för att fungera inuti tables.
Uppdatering av devDependencies i package.json.
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
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.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')
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')
Saknar du en detalj här? Se GitHub‑releaser för komplett historik.