Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for naming file asset extensions #32

Open
charlieholder opened this issue May 16, 2023 · 0 comments
Open

Add support for naming file asset extensions #32

charlieholder opened this issue May 16, 2023 · 0 comments

Comments

@charlieholder
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant