nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Quick back up and restore options for livesite sites with user updates

Srinivasa Talla

Could you please share your experience with backing up the individual sites with user updates.

I am not talking about backing up the whole store or teamsite related things.

Here is one example :

We have 3 individual sites running on our livesite servers. Our users may be updating and submitting them through PLC, it may be css, js or xslt. In between we may have caching issues. PLC will take all the dependents along with a page. If user updated a css and submitted, the web site is not displaying properly because of css issues or something else. if user submits 20 pages along with dependents, web site got some issue and we don't know what happend.

Usually we will go through the log files and try to fix the issues. If we want to put the site back running immediately, what are the best quick options? Some of the options may be snapshot, folder copy on livesite server. Any issues with these or alternates?

Find more posts tagged with

Comments

Rick Poulin

Not to sound silly, but the real solution is to better understand the platform. Under no circumstances should a content publishing activity break the site. Your users should first preview the impact of their changes within TeamSite to determine if they've just broken something. Or you can build a standalone 'preview' runtime and integrate that into your workflow, so they can validate on the preview server instead of the live one.

The bandaid solution I would suggest is this: don't kill your workflow after a successful publish. transition to a user task where you ask the user to validate the runtime and then if they click "not good", you can have a task revert the files that are already attached to the workflow.

Srinivasa Talla

We are previewing on Test server through workflow and then publishing on PROD with PLC workflow. But sometimes, some of the items may not be updated due to the caching issues. Some of the pages, we invalidated. Still, we are not seeing the new update. So we can figure out where is the problem and fix it. But if it is taking beyond 30 min or 1hr, what is the simple solution to put PROD back with recent copy of that particular application on livesite server?

Rick Poulin

I don't understand how it can take you over an hour to identify a cache-clearing problem frequently enough to have to code around it.

How do you expect republishing the old versions of pages would help with a caching problem anyway? If you want to republish the old version of the full site, you might as well just clear the whole site cache manually instead via /iw/admin/JCS.jsp.

Srinivasa Talla

I don't know, just asking if it take more time than 1hr, what would be the best way!

So you guys are not supporting server snapshot or livesite folder copy before doing the big deployment. True?

Rick Poulin

To be honest, I don't know what you're asking now.

There are ways to do various backups and restores for various use cases, but most of those situations are for disaster recovery (i.e. losing an hour's worth of data or taking an hour to bring the site back online is 'normal').

The point I'm trying to make is that a regular content publishing activity (or generally, any activity triggered by a business user) should under no circumstances corrupt your website or cause developers to scurry around for upwards of an hour. This shouldn't happen ever, let alone on a regular basis. Fix your implementation problems instead of patching the symptoms.

Srinivasa Talla

Users have the ability to change the CSS, JS and XSLT files also. So worrying about that. No problem, thanks for the suggestions.

CrossTab7.zip

Rick Poulin

The users which have access to change CSS/JS/XSL should have the capacity to understand how to properly validate those changes before pushing them live. And the workflow that pushes these things live should be properly set up to clear the cache on any affected pages, if not all. And in the worst case, that user should also understand how to revert changes in TeamSite and publish essentially the old version.

I don't mean to be confrontational, I just don't understand how you get into a 1hr panic situation if the above holds true.

nipper

No question, you need to use a Dev LS server for this. Why am I reminded about closing the barn door after the horse is gone......

LeftOuterJoin.zip

Srinivasa Talla

They have access but we told them not to modify. But few users may be proactive. So just worried about that. Anyway thanks for the suggestions.