You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The practical experience when using the Migration Tool results in creating multiple zip archives, one for every Content Type. Inside each zip archive is some selection of assets representing pages and a duplicated folder structure. With all of the content spread out over multiple zip archive files, it's difficult to see the larger picture of the website since it's broken up into multiple parts.
Right now, you provide separate lists of the file extensions you want to use to identify which assets will be converted into a particular Content Type and which will be converted into XHTML Blocks. Everything else in the zip archive that doesn't match one of the extensions for a Content Type or an XHTML Block will get uploaded as a File.
If we offered a third input field to provide a list of extensions for Files, we could offer a way for a single zip archive to be used instead of multiple. This small addition would use the Migration Tool's existing functionality/programming/approach without needing to rewrite how it fundamentally processes assets for conversion.
This addition would be useful for all customers doing migrations, but the example use case that sparked adding this issue is Northampton Community College. They want to do as much work as possible prior to us finishing their Quickstart. I told them they could map out their directory structure locally on their computer and zip it up for mass upload into the CMS as a File Asset (and choosing to unpack instead of literally upload). Then I talked about the Migration Tool being used if they also wanted to create the Page assets. They could get a placeholder Page created with the correct asset name in the correct location ready for edits to be made for page migration. (This approach would happen after the QS was finished so there are actual Content Types to use.)
The approach I thought would work is to provide file extensions identifying the Content Type to be used. For example, index.home, index.landing, page.interior, page.program, page2.program, etc as file names in the zip archive. These file extensions separate the pages by type. However, again, anything that doesn't match one of the extensions for a Content Type or an XHTML Block will get uploaded as a File. So when you pick .home to upload as a Homepage Content Type, all other pages get uploaded a Cascade File assets and are not ignored.
Adding an option for what is allowed for File assets would allow you to skip over other asset types and circle back around to them on a limited basis using a single zip archive. Identifying assets ahead of time by adjusting their file extension instead of separating everything out into # number of zip archives. Again, all of this as a suggested addition that is a tiny change using the current implementation strategy without reworking the fundamental way the tool does conversions to Cascade assets.
The text was updated successfully, but these errors were encountered:
The practical experience when using the Migration Tool results in creating multiple zip archives, one for every Content Type. Inside each zip archive is some selection of assets representing pages and a duplicated folder structure. With all of the content spread out over multiple zip archive files, it's difficult to see the larger picture of the website since it's broken up into multiple parts.
Right now, you provide separate lists of the file extensions you want to use to identify which assets will be converted into a particular Content Type and which will be converted into XHTML Blocks. Everything else in the zip archive that doesn't match one of the extensions for a Content Type or an XHTML Block will get uploaded as a File.
If we offered a third input field to provide a list of extensions for Files, we could offer a way for a single zip archive to be used instead of multiple. This small addition would use the Migration Tool's existing functionality/programming/approach without needing to rewrite how it fundamentally processes assets for conversion.
This addition would be useful for all customers doing migrations, but the example use case that sparked adding this issue is Northampton Community College. They want to do as much work as possible prior to us finishing their Quickstart. I told them they could map out their directory structure locally on their computer and zip it up for mass upload into the CMS as a File Asset (and choosing to unpack instead of literally upload). Then I talked about the Migration Tool being used if they also wanted to create the Page assets. They could get a placeholder Page created with the correct asset name in the correct location ready for edits to be made for page migration. (This approach would happen after the QS was finished so there are actual Content Types to use.)
The approach I thought would work is to provide file extensions identifying the Content Type to be used. For example,
index.home
,index.landing
,page.interior
,page.program
,page2.program
, etc as file names in the zip archive. These file extensions separate the pages by type. However, again, anything that doesn't match one of the extensions for a Content Type or an XHTML Block will get uploaded as a File. So when you pick .home to upload as a Homepage Content Type, all other pages get uploaded a Cascade File assets and are not ignored.Adding an option for what is allowed for File assets would allow you to skip over other asset types and circle back around to them on a limited basis using a single zip archive. Identifying assets ahead of time by adjusting their file extension instead of separating everything out into # number of zip archives. Again, all of this as a suggested addition that is a tiny change using the current implementation strategy without reworking the fundamental way the tool does conversions to Cascade assets.
The text was updated successfully, but these errors were encountered: