The Broken Relative Link After a Folder Reorganization
You inherit a Dreamweaver site whose local root folder is C:\Sites\northwind. A colleague renamed images/ to assets/img/ and moved products.html from the root into a new catalog/ subfolder. The site definition still lists the old root, and the Files panel shows a stale tree. In Live view, catalog/products.html renders with a broken logo and three broken product thumbnails, while index.html at the root still shows its logo correctly. The logo markup in both files reads <img src="images/logo.png">. Nobody edited the HTML itself. The client wants the site uploaded to a host whose document root maps to northwind/, and the staging URL is https://staging.northwind.example/ with the site living at the domain root.
1. Diagnose why `index.html` still shows the logo but `catalog/products.html` does not, and explain what must change in the site definition before any link repair is trustworthy.
Read the worked answer
Both files use the identical root-relative-looking string images/logo.png, but it is actually a document-relative path, so it resolves against each file's own location.
index.htmlsits at the site root, soimages/logo.pngresolves tonorthwind/images/logo.png.catalog/products.htmlsits one level down, so the same string resolves tonorthwind/catalog/images/logo.png, which does not exist.
The folder rename compounds this: the real folder is now assets/img/, so even the root file's path is stale on disk.
Before fixing links, correct the site definition: point the local site folder at the actual current root (C:\Sites\northwind), then use Recreate Site Cache so Dreamweaver re-scans the tree. If you repair links against a stale cache, Dreamweaver's link checker reports files that no longer exist and misses new ones, so your fixes are guesses. Only after the cache matches disk should you run Check Links Sitewide or fix paths by hand.
2. The client insists the site live at the domain root on staging. Which link style should the repaired logo and thumbnail references use, and why is that choice safer here than the alternative?
Read the worked answer
Because the site maps to the document root of https://staging.northwind.example/, root-relative paths such as /assets/img/logo.png are safe and preferable for shared chrome (logo, nav, global CSS). They resolve identically from index.html and from catalog/products.html, so a file moving between folders never breaks them.
The trade-off: root-relative paths break if the site is ever served from a subdirectory (e.g. example.com/northwind/), because the leading slash points at the host root, not the site folder. Document-relative paths (../assets/img/logo.png) survive subdirectory deployment but must be rewritten every time a page changes depth - exactly the bug you just fixed.
Given the stated constraint (domain root, both staging and production), use root-relative for sitewide assets and reserve document-relative for links that must remain portable. Whichever you pick, apply it consistently; mixing the two is what produced the confusing symptom.