Helpdesk Best Practices

Choose the right tools for debugging

When you need to login to the customer site to debug an issue, use one of the tools below:

If you want to have a quick check at specific data, and you do not need to modify data on the client system, you can use the WP File Manager plugin and the adminer WordPress plugin.
That is the quickest way to get insights into the system.

If you need to modify data for debugging, it’s highly required to use the Tinyfilemanager and the Adminer as a standalone version. Both tools allow you to access the system database and file system even if things went wrong while debugging. Even if you mess up the system – which you should not do – you can recover it as you are still able to access it.

When a customer has an issue, you already checked the debug.log, and you are still not sure what to do next, have a first look into our documentation: https://wp-staging.com/docs/install-wp-staging/

The search function may bring up many relevant results.

If you are still unsure what it could be, ask your team member via Slack.

​Proofreading and Automatic Corrections of Typos

An excellent tool for doing automatic correction for typos and grammatic rules is Grammarly. It’s available as free chrome extension:
​https://chrome.google.com/webstore/detail/grammarly-for-chrome/kbfnbcaeplbcioakkpcpgfkobkghlhen?hl=en

 

When to activate the debug.log?

 

Activate the debug.log whenever the customer gets an error 500 on live or staging site.

Activate the debug.log on the customer live or staging site and check the log file for warnings or errors related to WP Staging:

How to activate the debug log and where to find it:
https://wp-staging.com/docs/enable-wordpress-debug-log-mode/

 

The error 400 often happens after successful pushing at the last step and happens because the user is logged out right after pushing the staging site to live. The copying should be successfully done and all the data properly copied over to the live site. We hopefully can fix this in the future