Possible to include manager customizations in a transport package?

Development
1

Is it possible to include manager customizations in transport packages? If so, how? Any examples? I can imagine writing a custom resolver, but that would be very tricky.

2

Just about anything that can be done in code can be done in a resolver – adding custom dashboard widgets, changing existing System Settings, adding new custom System Settings, main menu changes, and new custom menu items are all fairly straightforward.

What kind of Manager customizations are you thinking of?

3

Yeah, those are all pretty easy. Don’t know about manager customizations. I’m talking about things you would enter into the Manager Customizations (a.k.a. Form Customizations) screens. I move TVs all around, putting some in modx-resource-main-left or modx-resource-main-right, some under the content field, sometimes turning off the content field, assigning custom labels to fields and custom orders, sometimes create custom tabs and put fields there. You name, I’ve done it with customizations.

4

Yes, those would be much trickier. FWIW, I dislike calling them Manager Customizations at this point, because they’re limited to customizing the Create/Edit Resource Panel, though there could be wider uses for them in the future (maybe those already exist and I just don’t know about them).

It’s definitely doable, though.

I think the data is contained in the three fc_ tables (I could be wrong):

modx_fc_profiles
mods_fc_profiles_usergroups
modx_fc_sets

You’d have to create the FC rules, then look at those tables. Then look at the MODX schema to see the names of the three objects that use those tables.

After that, it’s just a matter of creating new objects with $modx->newObject() in your resolver, setting their fields with fromArray(), and saving them.

In the process, you’d have to get the IDs of some of your objects (e.g., user groups and fc profiles), since you probably can’t know them ahead of time.

As a first step, you might export a fresh MODX DB to SQL, create some rules, export it again, and do a diff on the two files to see what has changed that might relate to FC rules.

5

I know what you mean, although I don’t like “Form Customizations” much better!

Also:
modx_actiondom
modx_actions_fields

I think there has to be one more somewhere.

Yeah, that’s what I anticipated, and why I haven’t done anything yet. Dealing with all these tables and getting all that ID checking will take some time. It’s worth doing, though. Some kind of getObject() method for this would be great if it exists, but I don’t see that it does.

That’s a good suggestion!

6

There are xPDO classes for all the tables:

  • modFormCustomizationProfile (for the db-table “modx_fc_profiles”)
  • modFormCustomizationProfileUserGroup (for “modx_fc_profiles_usergroups”)
  • modFormCustomizationSet (for “modx_fc_sets”)
  • modActionDom (for “modx_actiondom”)

Study the MODx schema to see the fields and relationships of these classes.

$set = $modx->getObject('modFormCustomizationSet',$setId);
$rules = $set->getMany('Rules');
...
7

OK, thanks! That will be very helpful.