Having more than one web part 'preconfiguredEntries' does not work in classic pages

[shaipetel]

Category

• Question
• Bug
• Enhancement

Expected or Desired Behavior

We wanted to have one web part built, but with 2 or more preconfiguredEntries in the web part gallery.
Each one with a different title, description and different default values for properties.

Observed Behavior

This works well in modern pages, but in classic pages - no matter which web part you add from the gallery, it is always adding the first web part in the collection.
None of the default property values were taken.

Steps to Reproduce

Have a web part with property "wpName", that display this property's value.
Edit the webpart.manifest.json,
under preconfiguredEntries, add another object that is an exact copy of the first one.
In the first one, set default value for your property:
"properties": {
"wpName": "First option"
}
and set its title and description to "First option".

Do the same for the second web part definition - only replace "first" with "second.

Build and deploy the web part. Add the 2 to modern page - you will see both working as expected.
Add them both to classic page, you will see the first one is added twice.

In the web part gallery, when clicking "add web part" in the ribbon - the correct web part icon, title and description appear.

This is a major issue blocking our product release at the moment. Can someone please confirm reproduction and give an ETA on this fix?

[shaipetel]

@manishgarg1 @mcmynn83 Hey guys, this issue is very critical for us and preventing a release of an otherwise-ready product.
Can you perhaps assist in this or give me feedback?
Thanks!

[GrahamMcMynn]

@shaipetel - Would you mind mailing me your package that is failing at my Microsoft address (grahamc)? I'll take a look at the problem, can't give an ETA for it or even a guarantee that we will fix it until I investigate the issue.

[GrahamMcMynn]

@shaipetel - thanks for finding this issue. We are working on the fix and it should be rolled out to production in early June.

[spdevdocs]

We closed this issue as it had not activity within last 180 days. This is a generic process we have decided to perform for issues, which have not been explicitly marked still to be "work in progress" based on tags. We are performing this cleaning to make sure that old issues that have already been solved (but not closed) or are no longer relevant are cleaned out and make the issues more manageable. If this issue still valid, we would ask you to open a new issue and follow the guidance in the issue template related on the recommended location. We do apologize any inconveniences this might cause. Please do remember that issues in the issue lists are also messages for others in the community, so you can also check if you can assist on any of them. “Sharing is caring!”

[thriggle]

@shaipetel - thanks for finding this issue. We are working on the fix and it should be rolled out to production in early June.

@GrahamMcMynn Sorry for poking an old issue, but just wondering... was a fix for this ever actually shipped?

[shaipetel]

@thriggle yes I can confirm as of right now, it works as expected.

[thriggle]

@shaipetel Thanks for the reply.

I'm still running into the problem in SharePoint 2016 on-prem (happens on both the November 2019 and January 2019 patches)... but maybe it's my generator code that is out of date. I'll try updating my Yeoman generator (microsoft/generator-sharepoint) and then rebuild the solution from scratch to see if it still happens.

[shaipetel]

@thriggle I'm testing on SharePoint online with SPFx v1.8

SP2016 On premises uses SPFx v1.1, I suggest you open a separate new issue for that, and reference this issue in it.