Migration of other Fellows contents
This task is part of the FellowshipHacks/Projects/ContentMigration project.
Goal
Help Fellows to migrate the content hosted in the current Fellows home pages. (here we are talking about everything except Fellows blogs, see FellowshipHacks/Projects/Blog for this).
People
People working on this task.
Volunteers are always welcome! Have a look at FellowshipHacks to know how you can help
Status
This is now DONE.
Subtasks
DONE
Make a list of the kind of contents to migrate (see #Notes)
Make a list of possible tools to host the contents in the new Fellowship infrastructure (see #Notes)
Look for possibility of automated extraction of content from the current EZ platform
Decide the best option for each kind of content, and prepare a migration plan
- Automated migration
- Manual migration by the Fellows (in this case we should provide instructions and support)
- Implement the migration plans / prepare support for Fellows
Analysis
Contents to be migrated and possible solutions
Here is a list of the kind of contents (and corresponding EZ "classes") and possible targets for migration.
Folders
Folders (ez class: "folder"), and their content (ez class: "file"; about 170 published objects)
Possible targets:
- Fellowship blogs
- Wordpress can also host generic files in its "Media library" section
- We can also put a quota limit on each Fellow disk space
See: http://codex.wordpress.org/Using_Image_and_File_Attachments
- Fellowship wiki
- The wiki can host any kind of contents (by means of attachment to pages; for images we have a dedicated plugin to create image galleries).
- Each Fellow automatically has a homepage on the wiki
Solution:
- Set up a mirror and let Fellows migrate content where they prefer
Articles
Articles (ez class: "article"; about 170 published objects)
Possible targets:
- Fellowship blogs
- Wordpress can also host static "Pages" (besides blog posts)
cri: the automated migration procedure for blog posts could be re-used to migrate "static" EZ articles as WP "pages" ("pages" in the WP database are treated just like blog posts, only with a "page" flag) or as blog posts.
- This would spare us the conversion work!
- Fellowship wiki
- The wiki can host textual content (arrangeable in pages, subpages etc)
- Each Fellow automatically has a homepage on the wiki
- Problems:
- Textual content should be converted (from html/XML to wiki markup)
Solution:
- Set up a mirror and let Fellows migrate content where they prefer
Events
Events (ez class: "event"; about 50 published objects)
Possible targets:
- Forthcoming calendar application
- We haven't yet chosen the application
- Must aim at I/O format compatibility, avoiding manual conversion work
- Fellowship wiki
- This could be a second best solution, for temporary storage in case the calendar component is not yet ready at the time of the migration
Automated extraction from ez
Whatever target system we choose for each kind of content, we should find a way to help Fellows to extract their content from EZ.
From the EZ admininstration panel it is possible to create "packages" of content: see http://ez.no/doc/ez_publish/technical_manual/3_8/features/packages
We should try to automate this, either in batch mode (e.g. run a procedure that cretes a "package" for each Fellow and provides it to the Fellow), or in a decentralised way (e.g. providing each Fellow a button to create its own package; we can't delegate the creation of packages to the system administrator).
Update: this is not useful; since the content format of EZ packages is not user-friendly.