With a stable release of Plone 5 customers you should start planning to upgrade existing sites to Plone 5. In this talk I will discuss migrations in general and especially those from Plone 4 to Plone 5. When not to upgrade
and on the code-part of migrations. Mainly I will discuss what you can and should do in Upgrade-Steps and which problems await you when migrating from one Plone-Version to another. I will also discuss migrations from Archetypes to Dexterity.
This talk is for developers who don't regularly write Upgrade-Steps and want to know why they should be bothered. Also if you do not write upgrade steps without ftw.upgrade you need to see this talk.
This is a sequel to "Migrations, Upgrades and Relaunches" given 2013 in Brasilia (http://www.youtube.com/watch?v=1Qx0JALp3lQ) that discussed planning and why every non-trival upgrade should be a relaunch.
18. I T C A N ’ T B E T H AT E A S Y
LinguaPlone is hard to get rid of
Theming is tricky
Some add-ons work nicely in Plone 5
19. I S S U E S
KeyError: 'Interface
`plone.app.iterate.interfaces.IIterateSettings`
defines a field `checkout_workflow_policy`,
for which there is no record.'
20. I S S U E S
ComponentLookupError: (<InterfaceClass
plone.resource.interfaces.IResourceDirectory>,
'persistent')
21. I S S U E S
List of content to migrate from AT to DX is empty
22. L I N G U A P L O N E – O H M Y !
LinguaPlone ➟ plone.app.multilingual (2.x) in 4.3.x
Documentation: https://github.com/plone/
plone.app.multilingual/issues/181
wildcard.fixpersistentutilities to the rescue!
Can someone please sprint on this?
23. T H E U P G R A D E - G U I D E
http://docs.plone.org/manage/upgrading/
version_specific_migration/p4x_to_p5x_upgrade.html
Needs love at sprint
24. Your design will break unless it is a full diazo theme
T H E D E S I G N
With a stable release of Plone 5 customers you should start planning to upgrade existing sites to Plone 5. In this talk I will discuss migrations in general and especially those from Plone 4 to Plone 5. When not to upgrade
and on the code-part of migrations. Mainly I will discuss what you can and should do in Upgrade-Steps and which problems await you when migrating from one Plone-Version to another. I will also discuss migrations from Archetypes to Dexterity.
This talk is for developers who don't regularly write Upgrade-Steps and want to know why they should be bothered. Also if you do not write upgrade steps without ftw.upgrade you need to see this talk.
who am i
This is a sequel to "Migrations, Upgrades and Relaunches" given 2013 in Brasilia (http://www.youtube.com/watch?v=1Qx0JALp3lQ)
1. Lessons from part 1
----------------------
The most important lessons from part 1
Held in Brasilia at Ploneconf 2013 and available on video
Google for "Migrations, Upgrades and Relaunches"
Every non-trivial upgrade should be approached as a relaunch.
Be careful with words: Update, Upgrade, Migration, Redesign, Rewrite, Relaunch
Almost everything is a relaunch, at least you want it to be.
The primary challenge is not development but communication and project management
What does the client really want?
Bring time. And space
you will always forget hat you'll have to migrate multiple times.
Double your estimates.
Get lot's and lot's of Disk-Space (and a fast SSD)
Your DB will double during migrations and you need several copies of it.
Expect everything to break!
You will have to
- fix old javascript
- figure out what custom skin-templates actually did
Don't experiment, document
Write every problem and every solution down!
Make a Plan
Write down how you want to approach it A to Z and change the plan as you go.
Keep the plan for future reference.
Write your code as if your own kids will inherit the code one day.
Do you want them to hate you?
Write upgrade-steps!
I wrote a upgrade-step that migrated a site from P3->P4 and ran for 14 straight hours
It consisted of ~30 single steps including:
- migration to blobs
- migration of comments
- removal of old content
- running upgrade-steps for about 15 Addons
- Intermediary commits
You don't want to do that by hand
Divide and conquer
Write single upgrade-steps with commits after each one
If A works use a copy of the DB at that state to write B and so on
Combine to ABCDE when they work
Don't try to add more than two new technologies at once.
You will make your customer pay for your inexperience
Use the Help
plone.api
ftw.upgrade
Why would you want to migrate to Plone 5?
First mistake: It’s not about you. It’s about your client.
You want to play with the newest shiny toys and bang you head against the resource-registry!
But: Why would your customer want to migrate if she/he has a really nice running site based on Plone 4
Customers don't like paying for upgrades that give them no real benefit.
They don't want you to have fun using the newest toys
The want Design, Usability, Functionality
Is Plone 5 an easy sell for a customer with a existing site?
Great responsive design ootb -> Meh
They probably have a great responsive design
Web Editors -> Meh
TinyMCE 4 not perfect either
Security -> Meh!
Is taken for granted.
TTW Features -> Meh!
Great for prototyping and clients who want to do stuff themselved.
Not very important in most our setups.
Dexteriy -> Meh!
The probably use it already
UX and Usability > That increases productivity \o/
Demo of P5 for a client. At the time I showed the new folder_contents it was a done deal.
Most relevant for people who work with content.
Not always an easy sell!
We could discuss the marketing-side of upgrading to Plone 5
It's ok to wait with migrating until 5.0.1 is out.
It's not ok to use P4 in new projects unless you have no budget at all to deal with new stuff
When not to upgrade:
No budget
Many incompatible Addons
Short site-lifespan
No developer-resources
I did not migrate any client-project yet.
Show 4.3 demo-site
$ cd buildout43
$ ./bin/instance fg
http://localhost:8080/Plone/
http://localhost:8080/Plone/ein-oerdner/ein-termin
Migrate live to 5.0
$ cd ..
$ cd buildout/var
$ extract 43.tar.gz
$ cd ..
$ ./bin/instance fg
http://localhost:8080/manage
Upgrade and show
http://localhost:8080/Plone/ein-oerdner/ein-termin (comment, static portlet, workflow state)
http://localhost:8080/Plone/ein-oerdner/a-newsuetem/@@sharing (local roles, image migrated to behavior)
Then migrate to DX
install pac
migrate types
show same links
Summary: Easy as a pie!
Can it really be that easy?
Another example: Starzel migration
$ cd ~/workspace/starzel
$ ./bin/instance fg
$ open http://localhost:8080/starzel
$ open http://localhost:8080/starzel/portal_quickinstaller/manage_installProductsForm
These are the add-ons
For this talk I migrated our company-site and this was my experience:
- LinguaPlone is hard to get rid of
- Theming is tricky
- Some addons actually work nicely in Plone 5:
- collective.plonetruegallery
- collective.disqus
- Products.PloneFormGen
- collective.js.jqueryui
Use checkouts or newest versions
Main issues:
- Products.LinguaPlone
- plone.app.theming was not installed by migration
- Theme breaks everything -> Concentrate on content and logic first, design later
If everything works as it should in Barceloneta then focus on the theme
Not possible for people without developer skills!!!
Reinstall plone.app.iterate (outdated version)
install plone.app.theming (was not installed in old site)
Remove Language-Index!
Another issue: thousands of old spam comments
skip migration of comments or upgrade-step to remove them (before migrating from 4 to 5)
LinguaPlone > plone.app.multilingual !!!
You should migrate from LinguaPLone to Plone.plone.app.multilingual 2.x before migrating from 4 to 5!!!
Needs more work
Needs more documentation
Please sprint on this
Wishlist:
Working complete uninstall-method for LinguaPlone
Documentation
Don't expect people who wrote packages to take care of them forever!
Someone please adopt/shepherd the maintenance of p.a.m!
You still need wildcard.fixpersistentutilities to remove LP
*phew*!
We already migrated several 4.x-sites from LP to p.a.m but it is always a adventure and never fun.
Read the Upgrade-Guide!
Needs some more work!
During the sprint: Write down all issues you encounter when upgrading add-ons (google-doc, we'll merge it into the rst after the sprint).
Once the migration is done you can re-enable and fit it.
The Theme will break
Sunburst does not work in P5.
structure of many elements has changed (html5!)
Disable your custom theme before migrating!
For www.starzel.de:
The Design probably sucked anyways.
Create a new one or keep default until we find time for that.
Content
Default AT content will work as before.
The main thing is that you should actually migrate to Dexterity (next part)
Settings
When you modified plone-setting via GS (either with portal_properties or portal_registry)
portal_properties is deprecated but works for you custom settings
All plone-settings are kept and migrated to portal_registry
add custom types to navigation
api.portal.get_registry_value("plone.displayed_types")
No code-examples. Would be too many…
Before you work on custom code figure out if it is actually needed any more!
Example: custom code replaced by LanguageSwitcher in plone.app.multilingual
Use plone.api!
Some imports changed (CMFDefault is gone). formlib is gone: controlpanels and custom forms should be moved to z3c.form
portlets also moved to z3c.form
your overrides/patches will likely break
Install plone.app.contenttypes (@@pac_installer)
Installs pac but only replaces types without any instances
Migrate content with form: @@atct_migrator
In code use the view @@migrate_from_atct:
migration_view = api.get_view('migrate_from_atct', portal)
results = migration_view(content_types=['News Item', 'Image'])
Only works for default-types!!!
Allows migration of schemaextendend types (contentleadimage -> leadimage-behavior). Is extendable.
Has several in-place patches (linkintegrity, notifyModified, UUIDIndex etc...)
Might be modified so that it is better reusable for custom types)
Partial migrations
Choose which types you want migrated. The others stay AT (not recommended but may be necessary if you have heavily customized types)
Custom migration form
form: @@custom_migration
Show Example?
Migrate
ATEvent to NewsItem
Create Site with ATCT:
- Disable "setup_content"
- Enable "Archetypes-based default content for Plone"
@@pac_installer
@@custom_migration
Maybe has bugs. Please test and fix instead of writing custom addons
Custom migrations
Products.contentmigration is great!
use field migrators in plone.app.contenttypes.migration.field_migrators!
migrate relations with plone.app.contenttypes.migration.utils.link_items
Migrate the branch you are standing on... e.g. all references are stored in an annotation on the portal and restored from there
memory useage
PR to add transactions after every X items and after each type is ready for review (thanks Daniel Jowett!)
Create tickets please! And fix them as well.
This is the main sprint topic.
Does it solve a problem that actually still exists (collective.contentleadimage)?
If there are content-types:
- AT works in P5 (Example: Products.PloneFormGen)
- Maybe migrate them to DX (provide a custom migration using the code-examples above) -> Warning: that means a lot of extra work!
Fix resources (css/js)
Functionality tied to content-types (e.g. a special field) -> turn into a behavior
Some add-ons are not worth migrating since there are similar addons that already work with P5