Nice URLs in the core…

… finally?!

Andreas Wolf / @andreaswo
July 13th, 2017 – TYPO3 Developer Days, Malmö/Sweden

Speaking URLs 101

Examples

/my/awesome/page.html
⇕
page id "123"

/news/2017/new-company-office.html
⇕
news article "34" on page "56"

Speaking URLs

resolution in both directions:
- routing (URL → record)
- link generation (record → URL)
relatively simple for pages
extensions make the game complex

Speaking URLs in TYPO3

mainly: RealURL, CoolURI
using hooks in the TYPO3 core
map parameters 1:1 to URLs
RealURL: autoconfig for extensions

Frontend rendering in TYPO3

TSFE: TypoScript FrontEnd
centered around pages
configured with TypoScript

Frontend plugins

bunch of PHP files
embedded via USER TS object
return rendered content
only requirement: entry point
lax API core⟷plugins

TSFE + Speaking URLs

current solutions = only parameter mappers
hook into FE rendering process + typolink
core is absolutely URL-agnostic
conceptually hard to fix

Frontend rendering: problems

plugins = black boxes for the core
using FE functions in Backend/CLI is hard
(e.g. Solr indexer, generating URLs on CLI)
Site configuration is a mess

Site configuration

spread all over the system:

TS records, TS files
domain records
language records
$TYPO3_CONF_VARS

Conclusion

URL handling needs tight FE integration
TSFE does not offer required functionality
configuring sites is too complex

And now… what?

I can haz pretty URLs, please?

Yes, but…

… we need to work on FE rendering

Improving FE rendering

Fixing FE processing flaws

better interface core⟷plugins
streamline site configuration
better definition of “views”

1: Better plugin interface

more mutual communication
core must better understand plugins
plugins need to report info
core needs to provide better interfaces

Information reported by plugins

Parameter validation
Parameter usage
Action success/failure
Caching-related data

New interfaces for the core

define “main view” of a page
more structured return by plugin
possibly more

→ give more control to extensions

2: streamline site configuration

basic idea: one main config file per site

site = page subtree + language
get rid of TS records
replace domain records
better language selection
better config overrides for dev/stage

3: better definition of “views”

currently: only pages are distinctive

single view of record is like a page

→ plugins a different kind of “page generators”?

Views, pages and plugins

rendered page = some view of content

page w/ content = one view of page content
plugin = many views of different content

every distinct view needs a URL

Conclusion

core and plugins need to improve
shift responsibilities towards plugins
clearer interfaces for core/plugins

And now… nice URLs