Theme export/import difficulty

Of course this is not Markdown is it!

This is the link to the yaml:

http://gist.github.com/337440

If anyone is interested my custom theme appears to import ok after making some manual changes https://gist.github.com/337440/c55203d93c3e3a8e3be714c8373d4eb1aedcc320

Notably removing the default_folders seemed to do the trick. Am yet to conduct a thorough trial and error session to narrow this down any further but maybe this is a clue for you.

I also commented out the preferred flags that appear on all the entry_listings templates and the page template of the export generated yaml. This doesn’t make sense if it does what I think it does.

Would be good to know if errors from a failed theme import are logged anywhere with any detail of what the likely reduce the inevitable tedium of attempting to troubleshoot an auto exported theme.

Hello Oliver,

This is actually a really nice catch. This seems to be caused by YAML::Syck parser.
If the theme.yaml contains brackets ( [] ) , YAML::Syck parses them incorrectly. It is not written in the system log since it throws unexpected error.

By the way, it seems that YAML::Tiny can handle it properly. You can try it by adding the configuration directive in mt-config.cgi.

YAMLModule YAML::Tiny

I filed a fogbugz case though we are not sure whether we can fix it.

http://bugs.movabletype.org/default.asp?103797

Thanks Jun, Good to know what the trigger was, and easily avoided in the meantime.

However, removing these characters has had no impact on the secondary issue of the naming of the exported mtml files.

What exactly determines the naming of these files as generated by the theme export?

Just now I deduced that the Template Type as selected in the Template Options determines the file name of Index templates. The common factor between the Index templates that are named with the template_ prefix is are they both have a type of "Custom Index Template".

The system templates and archive templates are appropriately named.

The problem is with some of my Template modules. As yet, I can’t see anything in common between the templates that are named with the template_n.mtml pattern and the others where it is derived from the module title.

I’ve made a careful audit of the exported files to account for them all in my template list and noticed one oddity that may be a clue. One of the modules is named "Head" (without the quotes) but it is exported as "header.mtml".

Changing the template name to "Headr" in the mt admin and re-exporting the theme had the same result: header.mtml. In the listing where we can deselect a sub-set of the configured templates "Details" link I noticed it appears in that list as "Header".

On a hunch I tried changing the title of the template again (this time with a prefix) to "xHead" before re-exporting the theme. This time it appeared in the Details listing as "xHead", progress! But the exported file was still called "header.mtml".

Unchecking "Head" in the Details listing and exporting the theme once more - omits the file as expected. With no change to the naming of the other files.

I’m quite sure I remember this template being called Header at some point. I changed it a while back. Is it possible there is some sort of cache biting me here?

One thing I have not attempted is deleting and recreating the template… Something to try tomorrow!

I deleted the Template Module titled "Head" and recreated it. Now when I export the blog theme this template is included as a file called: template_858.mtml

So I guess there is some kind of connection here.

Okay another experiment that seems to be clarifying what might be happening.

I exported my blog theme once more. This time I re-checked [in Template set Details config modal] some of the old original templates I started with. These included some modules I did not create: "Sidebar - 2 Column Layout" and "Sidebar - 3 Column Layout". These exported as: "sidebar_2col.mtml" and
"sidebar_3col.mtml". Clearly not derived titles!

I realise now I was presuming the exported file names are derived from the template labels. They seem to come from somewhere else. As I have no theme assigned to the blog I’m exporting from, the labels must come from a default theme from a while back - probably in the MT4 I upgraded. If the module was part of that theme it carries it’s original label with it. Otherwise it generates one by iterating on some ID or other: template_n…

Hopefully this will be cleared up when I apply my manually fixed theme back onto my dev blog. Fingers crossed.

Hi Oliver,

I asked about this behavior to the Six Apart engineer. His answer is..

1. Exported template name is defined by the "Template Identifier".
2. The identifier is stored in DB for each template but not visible nor editable from MT App.
3. It is the one you can use at <$mt:Include identifier=""> attribute.

http://www.movabletype.org/documentation/appendices/tags/include.html#identifier

On the other hand, it might be possible to re-consider this exporting behavior to use some other parameter.
Do you have any idea to make it more friendly ?

Thanks for clarifying that Jun, the pieces are fitting together for me now.

For the benefit of anyone who might stumble upon this later: I’ve been playing with it some more today and confirmed that the template identifiers are set upon application of a theme. To verify this I renamed the template file names and the references to them in my original yaml file and applied the resulting custom theme to another test blog. As expected, subsequently exporting the theme from this blog generated files with the my selected file names.

For most MT users, as consumers of themes rather than creators, I expect the current system works fine. If you never change the label of a template or create a new template, exporting your modified templates as a theme won’t result in any surprises.

Basing the identifier on the template name, as I expected it was, would be more intuitive. Having said that I can see how making that value editable could make the references to that template more brittle. Changing the template name would break the links to it elsewhere.

To my mind it is a similar scenario to the entry Basename field - which MT handles beautifully. If I was going to suggest anything for friendliness it would be to reuse this UI device for the purpose of exposing the template identifier on the template detail page.

If this creates too much clutter how about only revealing this additional field when _creating_ a new template. This is in addition to a gentle note displayed upon editing the name of an existing template, demonstrating that the identifier was unchanged, would be enlightening to tinkerers such as myself.

I should point out, it’s been a number of years since I was last digging into Movable Type and the theme export/import is a high on my list of pleasant discoveries in the current version. It’s going to make it much easier to store and transport my blog customisations. Thanks :)

Notably removing the default_folders seemed to do the trick. Am yet to conduct a thorough trial and error session to narrow this down any further but maybe this is a clue for you.?