Nice URLs in the core…

… finally?!

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

Speaking URLs 101



page id "123"

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

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


  • 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


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

And now… nice URLs

Nice URLs in the core

Primary goals:

  • transparent
  • predictable
  • reliable

How to get there

  • auto-generate URLs on save
  • no auto-generation on the fly!
  • store URLs for views (pages/records)
  • improve link building
  • small components, no monolith

What is a URL?

for us: pointer to a content view

must provide

  • root page
  • language
  • target page/record
  • (mountpoint[s])

Defining URLs

  • URL = domain + path
  • for us: site prefix + path
  • site prefix: domain [+ prefix path]

site prefix also defines language!

Storing URLs


  • site prefix
  • path


  • type (= table)
  • uid
  • (mountpoint)

Defining sites

uidDomain/pathLangRoot page [en-US]1 [de-DE]1 [fr-FR]123

Storing URLs


Resolving record URLs

  • URL points to target record
  • target page/plugin must be configured
  • either in TS or in URL (preferred)
  • no infrastructure currently present

Record URLs with plugin


two URLs
same site + record
but different plugins (CEs)

mp = mountpoint

Creating URLs

  • automatically on save
  • re-generate on rename/move
  • never break existing URLs!
  • never generate during rendering!
  • automatically phase out unused

Linking to content


e.g. t3:news:news?uid=123→ news record 123

  • link syntax with proper URIs
  • only specify record, no page
  • target plugin/action: configurable

Other topics

  • arbitrary plugin parameters
    (pagination, filters)
  • backend interface
    URL generation, management
  • fast(er) routing
    caches? static PHP route files?
  • logging

Much work ahead…

very much indeed…

How to proceed?

  • Prototype
  • Blueprint w/ full concept
  • after that: iterative process
  • I’m open for discussions!

How to get involved

  • review concept + prototype
  • discuss
  • provide test setups
  • funding!
  • invite me to your company!

Communication channels

  • talk to me during the DevDays
  • Slack:
    • #cig-speaking-urls
    • #typo3-cms-coredev for other topics
  • Mail: dev (at) a-w (dot) io
  • Twitter: @andreaswo



2018 will be “the year of the URL”