1. Unfortunately, file sets aren't something that is included in the importer at this time. You could add them through specific code in the install() method, however – but this might be the only way.

2. Not at this time – the only thing that really gets captured is the filename.

3. This is interesting – maybe the topic tree that the attribute is attached to doesn't exist? Right after you import if you go to the Dashboard > Files > Attributes screen do you have a topic attribute for files?

Thanks, Andrew! I was afraid that #1 & #2 were unsupported. I can poke around and see if I can get the File Set thing working using the install() method. Is there any documentation on that, other than what's inline within core?

On #3, here's the XML node fragment from my content.xml file:

<attributekey handle="gallery_category" name="Gallery Category" package="" searchable="1" indexed="1" type="topics" category="file">
<tree name="Gallery" path="/"/>
</attributekey>

When I run the import, I can open up Dashboard > Files > Attributes and do, in fact, see Gallery Category in the list. I can view the details of the attribute and it all looks correct. However, the "Other Properties" heading and the Gallery topic tree are missing when viewing the properties of files in the File Manager. It's only after deleting the imported attribute and recreating it that I see it in the File Manager property panel.

Hey Andrew,

I finally did some more digging on the Topic Tree issue and found something. I noticed that I can manually add my topic tree as a file attribute via the admin and it works fine. So I compared the attribute data from the one my StartingPointPackage installs to the manually-created version and saw that the auto-generated has the akIsAutoCreated field set to 1. The manual version is set to 0. If I simply flip that bit on the auto-generated one, it magically appears in the Properties view of my image files.

For reference, here is how I define the attribute in my content.xml file:



The Topic Tree is defined farther down and I can provide that, too, if you need it. But the tree itself looks to be working like a charm as-is.

Any idea on what's going on with that akIsAutoCreated field and why that would prevent it from displaying within file properties?

Hey Andrew.

Do you have any details on when #2 might be supported? Currently, we'll have to write our own workaround for this, but if we knew that it would be supported by x date, it would help.

Thanks!

Currently on our roadmap is 5.7.3.1, and then we're focusing on 5.7.4 which should include some ways to actually import content from a 5.6 site. This will be approached at that time.

Hey Andrew.

Good to know. Just FYI, I was able to import File Attributes via a CLI script, but the function I wanted to use is protected! saveAttribute()

http://concrete5.org/api/source-class-Concrete.Core.Attribute.Key.F...

I ended up with the saveAttributeForm() function, but I don't really prefer this. Do you have a better workaround?

Thanks.

I think the best way is usually to just use $file->setAttribute('attribute_handle', $data);.

$data is usually a string but could also be something more complex (an array, object) based on the type of data.

I also wanted to mention a quirk about the Image block when doing an export/import:

If you have an Image block that uses an internal link to a page (like linking a logo to the Home page, for instance), the ContentExporter generates a node to set the target page like this:
<internalLinkCID><![CDATA[1]]></internalLinkCID>

However, after importing my project, I noticed that it sets the internalLinkCID value to 0 in the database. I poked around and found that the save() method in the Image block's controller tests for a linkType value (a UI-only parameter) and then uses a switch/case to set the external and internal ID values accordingly. Since linkType isn't specified in the db.xml schema file for the Image block, the ContentExporter doesn't include it.

If I set this manually in my content.xml file, like this:
<linkType><![CDATA[1]]></linkType>

The block imports correctly and it sets my internalLinkCID value as intended.

FYI this is actually a bug in the image block that I believe is fixed in 5.7.2.1. If you look throughout many of the core blocks you'll see code like this:



In this example, pageid corresponds to a field in the block (and in its database table) that holds a page ID. If you add $btExportPageColumns to your block controller, on export, the numerical value of the page will be replaced with a canonical path to the page – and on reimport, whatever the numerical ID of that page is will be substituted back. So you don't have to worry about IDs shifting between export and import. The image block didn't have this variable.