It would make sense to completely block custom scripts, but Microsoft will have to provide an updated API first because there are many capabilities that for some strange reason depends on custom scripts being enabled. Like writing to the property bag or adding a new menu item to the context/gear menu, both are often required but beats me why they are dependent upon custom scripts being enabled?
I think that SPFx can do all those things, though. I know it can access the property bag. Maybe the goal is to move these risky activities to the developers, who would package them up into SPFx.
There's a piece of the jigsaw missing from this story. What happens to applications that use scripts that run on a daily basis? What about Shargate if the migration takes more than a day?
You could add the "allow script" PS command to the beginning of your script. In terms of a "better" solution, especially when it comes to ShareGate and other popular apps, a better solution will be developed. There are better ways to solve the need for custom scripting. Custom scripting was a carry-over from the classic days, in my opinion.
That's a fair point! All Microsoft admins (regardless of product) should be comfortable with PowerShell. That being said, any time I can do something easier, I'll take it 🤣
This is actually bad news for those people who want to use custom scripts. THe modern script editor web part is no longer a viable web part. They've made the announcement that come november you can no longer change the configuration to prevent the toggle to be flipped back to blocked. So anything that relies on custom scripts you will need to have a powershell script running everyday to allow custom scripts for a given site. It's a UI change because people will need to do this ALL THE TIME for a given site.
What type of custom script are you running every day on a site? Just curious... I know there are better solutions. As another person commented, ShareGate will have to adapt as well.
Edit the solution itself - edit the manifest: "requiresCustomScript": false And then make a package "sppkg" and deploy the package to app catalog. Then the webpart you can add to the site where you did before allowed custom scripting. After several hours it is disabed, but the Script Editor still works - verified on my side.
Thanks a lot, Steve😊
Thank you so much for the support!!
It would make sense to completely block custom scripts, but Microsoft will have to provide an updated API first because there are many capabilities that for some strange reason depends on custom scripts being enabled. Like writing to the property bag or adding a new menu item to the context/gear menu, both are often required but beats me why they are dependent upon custom scripts being enabled?
I think that SPFx can do all those things, though. I know it can access the property bag. Maybe the goal is to move these risky activities to the developers, who would package them up into SPFx.
@@stevecorey365 Sorry, I forgot to mention that I was referring to the Premium language for M365, PnP.PowerShell 😁
@@KasperBoLarsen You're not baiting me into that argument... LOL
There's a piece of the jigsaw missing from this story.
What happens to applications that use scripts that run on a daily basis? What about Shargate if the migration takes more than a day?
You could add the "allow script" PS command to the beginning of your script. In terms of a "better" solution, especially when it comes to ShareGate and other popular apps, a better solution will be developed. There are better ways to solve the need for custom scripting. Custom scripting was a carry-over from the classic days, in my opinion.
If you dont like powershell - you cannot be a sharepoint admin! Adding the custom scripting button is literally the very least Microsoft could do.
That's a fair point! All Microsoft admins (regardless of product) should be comfortable with PowerShell. That being said, any time I can do something easier, I'll take it 🤣
This is actually bad news for those people who want to use custom scripts. THe modern script editor web part is no longer a viable web part. They've made the announcement that come november you can no longer change the configuration to prevent the toggle to be flipped back to blocked. So anything that relies on custom scripts you will need to have a powershell script running everyday to allow custom scripts for a given site. It's a UI change because people will need to do this ALL THE TIME for a given site.
What type of custom script are you running every day on a site? Just curious... I know there are better solutions. As another person commented, ShareGate will have to adapt as well.
Edit the solution itself - edit the manifest:
"requiresCustomScript": false
And then make a package "sppkg" and deploy the package to app catalog. Then the webpart you can add to the site where you did before allowed custom scripting. After several hours it is disabed, but the Script Editor still works - verified on my side.
@@Stepecek Awesome! Thanks for that!