ezp5 transition from client project perspectivetechnical, when to use ezp5, when to use legacy. when to switch

in ezp5, still possible to run legacy as before.will be in 5.0 and 5.1 at least

Some performance issues with context switching symfony/legacyrecommendation: use either legacy completely, or ezp5. avoid mixing.use reverse proxy caching, which is well supported

for "serious use": starting 5.1 (or "middle release" 5.0.x)

missing: image variations, some data types (field types), ezstarrating

ezp5 is completely rewritten, no copy paste

Storage engine interface, currently just one that can interface with legacy. In-memory used for (abstraction) tests.

all existing extensions use legacy kernel, and admin is still legacy.

cookbook for making ezp5 extensions is in the works

mix and match: you can write a legacy extension with twig templatesusing ezp5 features in legacy is easier than the opposite

From ezp5, you want to reduce time spent on legacy code, but ezp5 is still not fully ready - legacy will be needed still for some things (like image variations)

be aware of terminology changes:data types -> field typesnode -> locationclass -> typecontent object -> contentsome 10x of theses. someone started a dictionary?

look at your feature requirements - if it fits symfony well, go that route

extension architecture: designed to be more obivious/consistent/transparentinterfaces show you how things should be doneyou can replace/extend pretty much anything in ezp5

site accesses work more or less like before. we have siteaccess groups now.

we have reduced the amount of available settings, to make things easier.

ezp5 is a symfony app with legacy inside

support: new and old stack. some parts of the new stack that are either not used by ezp, or still experimental, may not be supported. this will be clear by the release.

new: rest api uses the new stack

demo design allows "all" features, but performance is not good yetyou have to make sure you cache your things properly - each controller must send correct headers, so that varnish etc can cache them: etagsstandard http cachinghttp purge will be supportedsubrequests (renders) replaces fetches. each can be cached. etags can be controlled by you, so expiration strategy can be whatever you wantyou have to learn the new caching system - it is different, but not more complicated.