U4-3428 - Macro Parameter Types aren't set correctly when a (legacy) package installs them

Created by Douglas Robar 06 Nov 2013, 14:30:43 Updated by Shannon Deminick 07 Nov 2013, 05:08:26

Relates to: U4-3438

Umbraco 7.0.0RC

Installing an existing package (that works with v6... for instance, XSLTsearch) that makes a macro and sets macro parameters doesn't set any macro types.

I suspect this is because of the change from MacroTypes to DataTypes in v7, but it's a big breaking change for any existing packages.

Installing XSLTsearch, for instance, appears this way in v6.1.5: [file:macro_params_v615.png]

And this way in v7.0.0RC: [file:macro_params_v700rc.png]

Most types can (hopefully) be auto-converted, such as text and bool and numeric. Others may be more difficult, such as the contentTree that XSLTsearch uses. Also, the order of parameters is very different; they should be in the order specified in the package manifest, as they are in v6 rather than in alphabetical order. Hopefully the package dev was thoughtful about the order of params and that should be honoured in the UI.

2 Attachments


Douglas Robar 06 Nov 2013, 19:26:28

Quick update to say that the old 'contentTree' macrotype did indeed send in an xml fragment, beginning with the selected node.

Shannon Deminick 07 Nov 2013, 04:10:56

Thx doug, does seem strange that it didn't map the parameter types, probably something simple.

The bigger thing is all of the old macro parameter types - currently we've just mapped them like this:

Content All Content Picker Content Random Content Subs Content Tree

-> all are mapped to content picker

Media Current -> media picker Number -> number property

As you say the xml fragment stuff would have to be mapped to a new one that exposes that data. I'll chat to the guys and see what they think. Otherwise of course you could use a library method to get the xml fragment based on the selected id inside of the xslt.

Shannon Deminick 07 Nov 2013, 05:08:18

Fixed in rev: 164b630d5e394fe45b367880ffffb7231d4c5803

The ordering must have been a side affect since the ordering is now corrected now that the mapping is corrected.

So this all now works - apart from the 'contentTree' parameter type mapping to a picker. I'll create a separate issue for that and ask the guys about it.

Priority: Normal

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.0.0

Due in version: 7.0.0


Story Points: