CMS support for the update that needs to go live.
A saved change should reach the people who need it. WebXd helps your team investigate editing and publishing problems in Cascade CMS and other platforms within an agreed scope. We follow the update from its content fields to the live page, identify the part that needs attention, and verify the resolution with the editor who raised the request.
Bring the update that won’t reach the live page.
Start with the task someone was trying to finish. Perhaps an editor changed an application deadline, but visitors still see the previous date. A useful support request records what was expected and what appeared instead. That gives the investigation a specific question to answer, rather than a general instruction to fix the website.
We compare the saved value, the preview, and the public URL before proposing a change. The editor’s steps and the time of the attempt help us reproduce the problem. If the issue affects only one account or one page type, that difference is evidence worth keeping. Screenshots should show the relevant state without exposing passwords or private records.
Include with your request
- The public URL and CMS asset path
- The action attempted and the expected result
- The exact error text or publish report
- The affected editor role and time of the attempt
- Recent template, workflow, or platform changes
- 01Saved contentThe new deadline is stored.
- 02CMS previewThe new deadline renders.
- 03Publish evidenceCheck output, destination, and access.
- 04Live pageConfirm the public deadline changes.
Find the layer before choosing the fix.
Similar symptoms can come from different parts of a content management system. A missing date may be an empty field, a rendering rule, or a failed publish. We use the evidence to narrow the request and explain which change is likely to address it.
Layer 01Content and editing
Check whether the intended value was saved in the right place. A shared block, a draft, or a separate language version can explain why an edit appears elsewhere. Support can cover a broken editing field or a specific content correction, with the content owner confirming what should be published.
Layer 02Templates and rendering
If the saved content is correct but the preview is wrong, inspect the rules that assemble the page. In Cascade, that may involve a Data Definition, a Block assignment, or a Velocity or XSLT Format. A shared template change needs checks on other pages that use it, as well as the reported example.
Layer 03Publishing and connections
If the preview is correct but the live page is stale, follow the publishing path and check the delivery evidence. An unavailable destination, a queued job, or a connection error calls for a different investigation from an editing problem. External feeds and integrations may also need their system owner involved.
In Cascade, follow the destination.
Cascade publishes content to an environment that runs separately from the CMS. A correct preview therefore doesn’t prove that the public page received the change. We inspect the selected page Output and Destination, then read the publish report for errors or missing items. The public URL is checked against the location the site is actually configured to publish to.
A Destination’s applicable groups determine which editors can publish to it. We review the affected user’s group and role with your CMS administrator before changing access. The proposed permission should match the task and your approval rules. Giving every editor broader privileges can hide the original problem while creating a different one.
A change to shared content may also require the pages using it to be published. We inspect those relationships and agree which affected pages to include. If delivery fails, the Destination’s connection test and relevant error evidence help separate CMS configuration from a transport or hosting issue. Your infrastructure or vendor contact may need to resolve the next dependency.
Retest the request before closing it.
A fix needs a clear way to prove it worked. We agree the expected result before implementation and use a suitable test environment where available. For the deadline example, the check follows the same edit through preview and publishing to the live page. It also confirms that another page using the same component still renders correctly.
The editor should repeat the task with the role they normally use. An administrator’s successful test alone can miss a permissions problem. We record the result, any remaining dependency, and the changes made. If an integration is involved, verification extends to the receiving system rather than stopping at a success message inside the CMS.
Evidence for closing the request
- The original task succeeds for the intended editor
- The public page shows the approved content
- Related pages still display correctly
- The change and recovery approach are recorded
- Any unresolved dependency has a named owner
Leave the explanation where the next editor can find it.
The support record should explain the cause in terms your team can use. We document the affected assets, the change, and the checks that confirmed the result. A short note about which field to edit or which destination to select can make the next request easier to understand and prevent an avoidable repeat.
Recurring requests can reveal a larger need. If editors repeatedly struggle with the same publishing step, we can propose a focused workflow improvement or a separate training session. If the underlying component needs to be rebuilt, we define that development work before expanding the support request. Your team can then decide how much change to take on.
- 01Cause
- What prevented the expected update
- 02Change
- Assets or settings changed, with approval
- 03Verification
- Editor task and public-page checks
- 04Next time
- A short instruction and escalation owner
Questions that define the support request.
Can you support a CMS other than Cascade?
Yes, other platforms can be included after we review the implementation and the request. For WordPress, a publishing issue may involve a theme or plugin conflict. For Drupal, it may involve configuration or an editorial workflow. We confirm the relevant platform, version, custom code, and access before agreeing on the work.
Can you investigate a website another team built?
We can review an inherited implementation to determine a workable scope. Existing documentation, code access, and a known administrator help establish how the site operates. If a vendor controls a necessary component, we identify that dependency and agree who can contact them before promising a resolution.
How do we agree timing and access?
Tell us the impact of the problem and any publishing deadline. We assess the request and agree availability, priorities, and dependencies in the engagement. Access should use an approved account with the permissions needed for the work. Credentials belong in your approved secure channel, not in the initial inquiry.
Does CMS support include routine maintenance or training?
CMS support addresses a defined editing, rendering, or publishing request. Routine updates and ongoing site care belong in a maintenance scope. A planned program for teaching your team belongs in a training scope. We can identify those needs during diagnosis and outline the appropriate next step.
Will a support request require moving platforms?
Many CMS problems can be investigated within the current platform. If the evidence suggests a broader rebuild or migration, we explain the reason and define a separate proposal. A request to correct a publishing problem does not automatically authorize replacing the system your team uses.