SPFx Field Customizer stopped working on February 3, 2025

[ruby-yama]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

• SPFx version　1.20.0
• Node.js version　v18.20.5

Describe the bug / error

Hello,

I have been using an SPFx Field Customizer (for a group field) in a SharePoint list, and it was working fine until last week. However, as of today (February 3, 2025), it has stopped working. The custom field no longer renders.

I suspect this might be due to a SharePoint update, but I would appreciate any insights or solutions to resolve this issue.

From debugging, it seems that the onInit method is not being triggered. Could this be a bug, or is there an update-related issue affecting SPFx Field Customizers?

Any guidance or workarounds would be greatly appreciated.

Thank you!

Steps to reproduce

1.Run gulp serve to start the SPFx Field Customizer.
2.The onInit method is expected to execute, but it does not trigger.
3.Before reaching onInit, the process fails without logging anything to the console.

Expected behavior

The toggle field should be rendered correctly in the SharePoint list.

[Mazecreator]

I am having a similar issue, I wrote it up on probably the wrong issues list. I will copy it here as there is debugging information as well as the DEMO in the training has the same failure to help with reproducing the error and debugging:

=========== Added rather than creating a new ticket as it appears related ============

SharePoint/sp-dev-training-spfx-extensions#89

TITLE: 03-listviewcommandset Fails to add COMMANDs and fire onInit()

I was having problems with several SPFx Extentions with ListViewCommandSet type where the onInit() wouldn't fire. After spending a long time trying to debug, make sure IDs match, etc and rebuilding new scripts with Yeoman, I found this training sample.

Digging deeper and reviewing some other peoples experiences it seems like adding commands to the commandbar in the Extension will work under very non-user friendly conditions which will not work as a product, you need to directly link to the page (some rumor you have to use classical list view), if you go off of that page to another page and return you have the same issues again.

The best way to test this is to:

build the 03-liverviewcommandset
configure serve.json to point to a single library page with 3 or more documents in it
use "gulp serve" to start the process
After loading you will need to do a ctrl-F5 to flush the buffer and wake up the system at times
You should be able to see the buttons in the commandbar based upon the demo logic
navagate away to the "Site contents" or something and then return and you will see that the buttons no longer appear on the commandbar
NOTE: No errors show in the console related to the failed addition to the commandbar or the extension failing, it is quiet failure as best I can tell.

(Related link from Webpart: #10077)

Failing example:
https://github.com/SharePoint/sp-dev-training-spfx-extensions/tree/master/Demos/03-listviewcommandset

I am hoping someone else can try this example to help confirm the problem. I don't mind bringing the bug somewhere else as I don't think this is a problem with this DEMO, but with the underlying framework, I just don't know where to bring it from here.

[tristian2]

i too am experiencing the issue for an Application Customizer. if i follow the simple example from Microsoft using the yeoman generator, oninit() is not triggered.

link to the "helloworld" example from Microsoft https://learn.microsoft.com/en-us/sharepoint/dev/spfx/extensions/get-started/build-a-hello-world-extension

[Ashlesha-MSFT]

Hello @ruby-yama,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.

[Ashlesha-MSFT]

Hello @ruby-yama,
We were able to reproduce the issue, and we are investigating it. We'll keep you updated on our progress and share findings.

[Mazecreator]

@Ashlesha-MSFT , I just wanted to make sure you saw the similar issue I posted above regarding the 03-liverviewcommandset demo failure that is impacting one of my projects.

Thanks,
-Greg

[Balkoth]

I am running into the same bug when following https://learn.microsoft.com/en-us/training/modules/sharepoint-spfx-extensions/5-exercise-field-customizer

[ryanexner]

Any update to this?

We're not able to get our current or new Field Customizers to fire. It loads the file, but the onInit() doesn't fire. We have a project awaiting for this to be resolved.

[PKOITC]

I've got the same problem - any updates ?

[JiaRichard]

@Ashlesha-MSFT Any update? It seems more and more users are hitting this issue.

[reedpamsft]

Hey Folks,

If you're debugging, can you try adding "?allowSpfxDevFallback=true" to your URL to see if that clears the issue up. Make sure you refresh at least twice so you don't end up with a cached page result.

If it still repro's, can you please take a quick screenshot of your UX and also send over a network trace (.har) of the issue?

[ruby-yama]

@reedpamsft
Sorry for jumping in! I just wanted to share that when I added ?allowSpfxDevFallback=true during debugging, it did work on my end after refreshing a couple of times.

However, I'm not sure if it will still work after packaging and registering the app in SharePoint.
Do you happen to know if this flag is also effective in that scenario?

[reedpamsft]

@ruby-yama the URL param is only necessary for debugging because of the way that debug customizers are loaded onto the page. A deployed package should not need that URL param. If it does, please let me know because that's a bug.

[JiaRichard]

@reedpamsft Did you confirm it works well after packaging and registering the app in SharePoint?

[reedpamsft]

@JiaRichard it does in our test cases, yes. If you're seeing something else, please let me know.

[PKOITC]

Sadly ?allowSpfxDevFallback=true didn't work for me, my field customizers onInit() still doesn't fire.

[ruby-yama]

Field Customizer is currently working correctly in the serve environment even without query parameters, as Microsoft has temporarily reverted a previous change. However, to ensure long-term stability, it is recommended to package and deploy your Field Customizer as an SPFx app.

Note: We successfully rendered a Field Customizer demo during a screen sharing session with Microsoft support, by deploying it to a different site.

Below are two deployment methods for Field Customizers as apps:

Method 1: Deployment with "skipFeatureDeployment": false

Steps:

In package-solution.json, set "skipFeatureDeployment": false

Package and deploy the solution to the SharePoint App Catalog

Add the app to the target SharePoint site

Go to List settings > Add from existing site columns and add the custom column

The Field Customizer will be automatically applied to the column

Advantages:

Can be configured entirely through the GUI by site administrators

Clear and explicit behavior from the user's perspective

Method 2: Deployment with "skipFeatureDeployment": true and binding via PnP PowerShell

Steps:

Note the component ID (GUID) from serve.json

Package and deploy the solution to the SharePoint App Catalog

Add the app to the target SharePoint site

Use PnP PowerShell to associate the Field Customizer with the column:

Install-Module -Name "PnP.PowerShell" -Force
Connect-PnPOnline -Url "https://.sharepoint.com/sites/" -UseWebLogin
$list = Get-PnPList -Identity ""
$field = Get-PnPField -List $list -Identity ""
$field.ClientSideComponentId = ""
$field.Update()
Invoke-PnPQuery

Advantages:

Minimal impact on existing production systems

No need for changes through GUI

Offers greater flexibility for development and testing

Note: Although Field Customizers currently work in debug mode without query strings, we highly recommend adopting an app-based deployment approach to ensure compatibility with future changes.

[Mazecreator]

Is there another possible work around by rolling back the SPFx version? I think this problem is on V20, has anyone rolled back to V19? Is this easy? We have clients waiting for a fix to this problem.