What is your use case & what is wrong with current name? Why do you spend time on renaming the title without any added functionality. Yes recommended way is to overlay.
What is your use case & what is wrong with current name
Well, the Sidekick only supports 4 accordion tabs before it places all of the remaining components in the "Other" bucket. To resolve this (and frankly to make it more intuitive for our Authors), we'd want to consolidate the following components into a "Personalization & Social" componentGroup:
Multivariate Testing (We'd rename to "AB Testing")
4 of the components under the Social Plugins group
Test & Target mBox
4 custom social share/follow components we created.
As it stands, the 11 components above are represented in 4 separate component groups. Is it unreasonable to want to consolidate these and make it easier for the Author to locate and use?
Why do you spend time on renaming the title without any added functionality
Because there isn't a way to easily move components into the sidekick folders your customers wish; unless there is and I'm not aware of it (hence my question). You are correct that it is fairly inefficient to copy an entire component without adding functionality just to rename or set the sidekick folder hierarchy.
Yes recommended way is to overlay.
Not clear I'm understanding your response. If I have to copy the entire component, don't we become out-of-sync when 5.6 is released?
Your assumption "Sidekick only supports 4 accordion tabs" is wrong.
In CQ the component groups in the SideKick has some assigning rules like
* Groups with minimum components will be consolidated into the "Other" group.
* The allowed maximum of groups. Exceeding it introduces the virtual group "Other"
Both of this are configurable at  and variables are MIN_COMPS & MAX_GROUPS.
If there is a need to change, you can overlay  the script found in  and modify the constant value
CQ.wcm.ComponentList.MAX_GROUPS = 4;
CQ.wcm.ComponentList.MIN_COMPS = 3;
Poor wording on my part; true you can increase the number od tabs; however that does not solve the use case at hand. In teh scenario I just provides, I'd still have 11 compoennts spread out across 4 different tabs. So yes, increasing teh constants makes the componentGroup tabs visible, but consolidation is still needed (at least we think so).
1 person found this helpful
The feature you are looking to regroup does not exists oob. As you have informed earlier one option would be to modify at the components. The other options (just a guess) would be modify componentStore or explore sidekick to explicitly reset the value rather than modifying at each component. If i find time today I will research & update you. Please file a daycare for tracking this enhancement.