What would you like?
Add dynamic to the list of WebDAV roots accepted by b2c webdav commands
(ls, get, put, mkdir, rm, zip, unzip), so that the per-site
Dynamic file location can be managed with the CLI:
https://<instance>/on/demandware.servlet/webdav/Sites/Dynamic/<site-id>/...
Today -r, --root only accepts
impex|temp|cartridges|realmdata|catalogs|libraries|static|logs|securitylogs,
so the Dynamic location is not reachable at all. The only workarounds are raw
curl with PUT/PROPFIND/MKCOL/DELETE, or mounting the WebDAV share
manually from Business Manager.
Since Dynamic is scoped per site, the command would need a site to resolve the
path — either an explicit flag (e.g. --site-id) or by requiring the site id
as the first path segment:
b2c webdav ls --root=dynamic --site-id=MySite mockData
b2c webdav put --root=dynamic --site-id=MySite ./mock.vm mockData/
Why?
The Dynamic location holds data that is deliberately not part of a code
version, and some Script API features can only read from there:
dw.template.Velocity#renderTemplate() resolves a template file name in
the Dynamic WebDAV location for the current site, and files included from an
ISML template via #parse / #include are always resolved in Dynamic with
no way to pass an absolute path
(see dw.template.Velocity in the Script API reference).- Consequently, Velocity templates used for mock/stub service responses,
and other site-scoped data files, must live under
Sites/Dynamic/<site-id>/, not under cartridge/templates/.
Our use case: we drive local/sandbox testing by swapping mock service responses
implemented as .vm templates rendered through Velocity.renderTemplate().
These files must be updated independently of code deployments — that is the
whole point of keeping them outside the code version — but every update
currently falls outside the CLI, which breaks otherwise fully scripted setup
and CI flows. Being able to list, upload, download, and remove these files with
b2c webdav would make the Dynamic location manageable with the same tooling
and credential resolution (dw.json / SFCC_* / b2c setup inspect) as every
other WebDAV root.
What would you like?
Add
dynamicto the list of WebDAV roots accepted byb2c webdavcommands(
ls,get,put,mkdir,rm,zip,unzip), so that the per-siteDynamic file location can be managed with the CLI:
Today
-r, --rootonly acceptsimpex|temp|cartridges|realmdata|catalogs|libraries|static|logs|securitylogs,so the Dynamic location is not reachable at all. The only workarounds are raw
curlwithPUT/PROPFIND/MKCOL/DELETE, or mounting the WebDAV sharemanually from Business Manager.
Since Dynamic is scoped per site, the command would need a site to resolve the
path — either an explicit flag (e.g.
--site-id) or by requiring the site idas the first path segment:
Why?
The Dynamic location holds data that is deliberately not part of a code
version, and some Script API features can only read from there:
dw.template.Velocity#renderTemplate()resolves a template file name inthe Dynamic WebDAV location for the current site, and files included from an
ISML template via
#parse/#includeare always resolved in Dynamic withno way to pass an absolute path
(see
dw.template.Velocityin the Script API reference).and other site-scoped data files, must live under
Sites/Dynamic/<site-id>/, not undercartridge/templates/.Our use case: we drive local/sandbox testing by swapping mock service responses
implemented as
.vmtemplates rendered throughVelocity.renderTemplate().These files must be updated independently of code deployments — that is the
whole point of keeping them outside the code version — but every update
currently falls outside the CLI, which breaks otherwise fully scripted setup
and CI flows. Being able to list, upload, download, and remove these files with
b2c webdavwould make the Dynamic location manageable with the same toolingand credential resolution (
dw.json/SFCC_*/b2c setup inspect) as everyother WebDAV root.