Handling transition between 4.x and 5.x.

441 views

Published on

Handling Transition between 4.x and 5.x

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
441
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Handling transition between 4.x and 5.x.

  1. 1. ezp5 transition from client project perspectivetechnical, when to use ezp5, when to use legacy. when to switchin ezp5, still possible to run legacy as before.will be in 5.0 and 5.1 at leastSome performance issues with context switching symfony/legacyrecommendation: use either legacy completely, or ezp5. avoid mixing.use reverse proxy caching, which is well supportedfor "serious use": starting 5.1 (or "middle release" 5.0.x)missing: image variations, some data types (field types), ezstarratingezp5 is completely rewritten, no copy pasteStorage 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 worksmix and match: you can write a legacy extension with twig templatesusing ezp5 features in legacy is easier than the oppositeFrom ezp5, you want to reduce time spent on legacy code, but ezp5 is still notfully ready - legacy will be needed still for some things (like imagevariations)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 routeextension architecture: designed to be more obivious/consistent/transparentinterfaces show you how things should be doneyou can replace/extend pretty much anything in ezp5site 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 insidesupport: new and old stack. some parts of the new stack that are either not usedby ezp, or still experimental, may not be supported. this will be clear by therelease.new: rest api uses the new stackdemo design allows "all" features, but performance is not good yetyou have to make sure you cache your things properly - each controller must sendcorrect headers, so that varnish etc can cache them: etagsstandard http cachinghttp purge will be supportedsubrequests (renders) replaces fetches. each can be cached. etags can becontrolled by you, so expiration strategy can be whatever you wantyou have to learn the new caching system - it is different, but not morecomplicated.

×