Message-ID: <393077808.3266.1485852553861.JavaMail.confluence@ip-10-127-227-164> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3265_1730849935.1485852553861" ------=_Part_3265_1730849935.1485852553861 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Beta
Instructions and scripts used here are provided as a preview and is curr= ently undergoing internal and community testing, comments and suggestions w= elcome.
Instructions for upgrading from eZ Publish to eZ Platform and eZ Studio = is in preview starting release 16.02. The status of the upgrade is:
If you are migrating from a legacy eZ Publish version, this page contain= s the information you need. However, first have a look at an overview of th= e process in Migrati= on from eZ Publish.
This section describes how to upgrade your existing eZ Publish= Platform 5.4/2014.11 installation to eZ Platform and eZ Studio.= Make sure that you have a working backup of the site before you do = the actual upgrade, and that the installation you are performing the upgrad= e on is offline.
The easiest way to upgrade the distribution files is to extract a clean = installation of eZ Platform / eZ Studio to a separate directory.
If you have code in src folder, move that over:
<old-ez-root>=
;/ src =3D> &l=
t;new-ez-root>/
src
Assuming you have own composer packages
composer <=
/code>
require
--no-update
"vendor/package:~=
1.3.0"
Adapt the command with your =
vendor
, package
, version number, and add&nb=
sp;"=E2=80=93dev"
if a given package is for dev use. Also chec=
k if there are other changes in composer.json
you should move =
over.
While no longer bundled, the XmlText= Field Type exists and is needed to perform migration from eZ Publish's Xml= Text to the new docbook-based format used by RichText Field Type. From <= new-ez-root> execute:
composer <=
/code>
require
--no-update --dev
"ezsystems/ezplatform-xmltext-fi=
eldtype:^1.1.0
"
To move over your own custom configurations, follow the conventions belo= w and manually move the settings over:
<old-ez-=
root>/ ezpublish/config/parameters.yml =3D=
> <new-ez-root>=
/ app/config/parameters.yml
<old-ez-root>=
;/ ezpublish/config/config.yml =
=3D> <new-ez-root>/<=
/em> app/config/config.yml
<old-ez-root>=
;/ ezpublish/config/ezpublish.yml =3D&g=
t; <new-ez-root>/ =
app/config/ezplatform.yml
Changes to repository configuration
When moving configuration over, be aware that as of 5.4.5 a= nd higher, repository configuration has been enhanced to allow configuring = storage engine and search engine independently.
ezpublish: # Repositories configuration, setup default repository to support solr = if enabled repositories: default: # For storage engine use kernel default (current LegacyStorageE= ngine) storage: ~ # For search engine, pick the one configured in parameters.yml,= either "legacy" or "solr" # see SolrBundle for further info: https://doc.ez.no/display/TE= CHDOC/Solr+Bundle search: engine: %search_engine% connection: default=20
Make sure to adapt siteaccess names
In the default configurations in ezplatform=
.yml you'll find existing siteaccesses like site,=
and depending on installation perhaps a few others, all under site group <=
strong>site_group. Make sure to change those to what you had in ezpublish.yml to avoid issues with having to login to your w=
ebsite, given user/login policy rules will need to be updated if you change=
names of siteaccess as part of the upgrade.
Move over registration of bundles you have from src and from composer pa= ckages, from old to new kernel:
<old-ez-root=
>/ ezpublish/EzPublishKernel.php =3D> <new-ez-root>/ app/AppKernel.php
Binary files can simply be copied from the old to the new installation:<= /p>
<old-ez-=
root>/ web/var[/<site_name>]/storage =3D> <new-ez-roo=
t>/ web/var[/<site_name>]/storage
In the eZ Publish Platform 5.x install web/var
is a symlink=
to ezpublish_legacy/var
, so if you can't find it in path abov=
e you can instead copy the storage files from the similar ezpublish_l=
egacy
path.
Since writable directories and files have been replaced / copied, = their permissions might have changed. Re-apply permissions as explained in = the installation instructions. TODO: LINK
When that is done, execute the following to update and install all packa=
ges from within <new-ez-root>
*:
composer update -=
-prefer-dist
Add the following new bundle to your new kernel file, <new-ez-root>/ app/AppKernel.php:
new EzSystems\EzPlatformXmlTextFiel=
dTypeBundle\EzSystemsEzPlatformXmlTextFieldTypeBundle(),
Import to your database the changes provided in one of the follow= ing files, optionally read inline comments as you might not need to run som= e cleanup queries:
MySQL: <new-ez-root>/vendor/ezsystems/ezpublish-kernel/d=
ata/update/mysql/dbupdate-6.1.0-to-6.2.0.sql
Postgres: <new-ez-root>/vendor/ezsystems/ezpublis=
h-kernel/data/update/postgres/dbupdate-6.1.0-to-6.2.0.sql
Instructions on purpose does not use dbupdate-5.4.0-to-6.2.0.s=
ql
as it contains issues with the sql, and the sql update fi=
le above contains all relevant schema updates.
For migrating content from the XmlText format to the new RichText format= , a migration script exists, execute the following from <new-ez-root>= :
php app/console ezxmltext:convert-t=
o-richtext -v
The migration script is currently in beta, which is why command example = is suggested with verbose flag. Feedback on how it works and on how we can = improve it is welcome on the repository= .
If you have Page field (ezflow) content and an eZ Enterprise subscriptio= n, you can use a script to migrate your Page content to eZ Studio Landing P= age. See Migrating legacy Page field (ezflow) to eZ St= udio Landing Page for more information.
If you use Varnish, the recommended Varnish (3 and 4) VCL configuration =
can be found in the doc/varnish
folder. See also the=
Using Varnish pag=
e.
The officially recommended virtual configuration is now shipped in the&n=
bsp;doc
folder, for both apache2 (doc/apache2
) and nginx (doc/nginx
). Both are built to be easy to un=
derstand and use, but aren't meant as drop-in replacements for your existin=
g configuration.
As was the case starting 5.4, one notable change is that SetE=
nvIf
is now used to dynamically change rewrite rules depending =
on the Symfony environment. It is currently used for the assetic production=
rewrite rules.
Assets from the various bundles need to be made available for the webser= ver through the web/ document root, execute the following commands from <= ;new-ez-root>:
php app/console assets:install --env=3Dprod --symlink php app/console assetic:dump --env=3Dprod=20