Enabling at the site collection doesn't apply for sub-sites about pnp-tools HOT 8 CLOSED

Thx for reporting this issue. We did do some modifications on the model recently, but the intention was not to change this to require one-by-one apply on site level. We'll have a look on the changes and will perform needed updates.

from pnp-tools.

It would make sense to have an option to make it recursive. I don't think it should apply recursively by default - in general you expect commands to not apply recursively by default.

from pnp-tools.

This solution relies on the UserCustomAction collection entry for the JS file. This was originally set at the site collection level in the original scripts, which meant that all sites in site collection had it. With the latest updates on the process, responsiveness is only applied in site level (Web.UserCustomAction), which is why @JessKCan is seeing a difference compared to older version.

This means that it's not specifically recursive, setting was rather applied in the site collection level in past. We'll work on having this option in the future as well.

from pnp-tools.

The current solution is just to enable you to use custom assets, so it is the underlying PowerShell cmdlet in SharePointPnP.PowerShell commands (Enable-SPOResponsiveUI) that needs to be re-visisted to include that behaviour. I suggest raising an issue against SharePointPnP.PowerShell for adding an optional -Recursive parameter to both Enable-SPOResponsiveUI and Disable-SPOResponsiveUI.

from pnp-tools.

I would not do this as recursive - rather as option to set it in site collection or in site level. Since if it's done recursively on site level, it's much more difficult to maintain and control than as one site collection setting.

from pnp-tools.

Okay, but assume still needs change to cmdlet because base class for that is SPOWebCmdlet. Perhaps by convention it could apply to site collection if the web is the root web? Or have to set an explicit parameter as well?

from pnp-tools.

Thanks so much for looking into it.

from pnp-tools.

This one was fixed in the October release. It targets again properly at the site collection level by default. This was a bug with the previous releases, but if you update to latest version, it works as expected again cross site collection in classic sites.

from pnp-tools.