This page explains how to get "self help".

If problems occurs, there are several things that you can do as a self help, before going on reporting the problems. Many problems are based on exceptions between Resurs Bank and the plugin, when it comes to business cases. For example, many problems comes from natural errors like the ones listed below. Many problems are therefore self explained and logs are there as a complement for you to check in. All of the logs are stored in your site, normally in the uploads folder: [WORDPRESS-ROOT]/wp-content/uploads/wc-logs. The plugin uses the internal logging systems and are therefor separated in several sections (or files) which are also reachable from within wp-admin ([WORDPRESS-URL]/wp-admin/admin.php?page=wc-status&tab=logs). The two mentioned paths here are the exact same, reachable in different ways.

Log Types

Those log types are available from within the Data class.

Type
Data::LOG_INFO
Data::LOG_DEBUG
Data::LOG_NOTICE
Data::LOG_CRITICAL
Data::LOG_ERROR
Data::LOG_WARNING

In normal cases, we use Data::setLogNotice/Data::setLogInfo to log notices, but from Data::setLogInternal we can also choose our own severity, and depending on the choice the logs are separated. But they is always there. The goal is to log as much as possible (on demand) so that it get easier to track problems to the correct source. Also, very much all customer events that is vital for "weird tracking" is being done; for example, a very common problem for merchants is when a customer decides to start a payment, but in the middle of the process further chooses to not proceed.

If a customer do not proceed while in the signing moment - or when starting to provide card data to external providers, end never returns to the store again, to fulfill an order no traces will neither become available. Therefore, the plugin also logs the moment when customers are leaving your store to sign or use another payment provider to complete the process. When customer returns to the landingpage for success, we again log the landing moment. By doing this, we can keep track of a potential customer that has not completed the order. Order statuses are also marked with those actions so logs don't have to be the first necessary step in troubleshooting.

Step 0: First time running should be a dedicated test environment

If you are entirely new to this plugin, I'd suggest you to run it in a dedicated test environment that is supposedly equals to a production environment when you install the plugin AFTER testing. Primary newly detected errors should be discovered in TEST rather than production. If something fails in production it also means that YOU are the one that potentially looses traffic to your site.

Step 1: Consult the logs

The first step as mentioned here, unless the errors are displayed instantly on screen is to simply consult the logs. Most of the errors, both critical and less critical errors are logged here.

This screenshot is taken from the "fatal errors" logging:

The other current log is based on regular notes. These are logs mostly based on customer actions and other non critical events. As you can see in the below log file, there are INFO and NOTICE entries here and it is very much depending on which kind of logging you actually want.

If something goes wrong, the answer is almost guaranteed to be found here.

Step 2: Contacting the correct instance

2a. Collect data!

At this point, make sure you have the support data container and logs that might be essential for toubleshooting ready. Do NOT just email someone and say "something is wrong" or "I've got a pop up that says 'there is an error in this unknown function'. Why is this happening?". Make sure you really deliver something that could HELP with the troubleshooting. The "container" mentioned here can be found at /wp-admin/admin.php?page=wc-settings&tab=trbwc_admin&section=information and looks like this.

This container helps a lot to find out if you are compatible with the plugin, which drivers you have available and so on. This includes for example PHP version. If you for example is using PHP 5.5 at this point: Do not contact anybody. Just upgrade your site.

2b: Problems that comes from API requests, that indicates the Resurs Bank has problems

There are errors generated by Resurs Bank, that is forwarded through the API. As you can see, some of the messages above also refers to Resurs Bank own contact ways. This is often problems like "unauthorized" issues in the API or address data (example only) that has trouble to resolve during requests, and much more api related things. This, depending on if you are in test phase or in production, should be reported to Resurs Bank (onboarding@resurs.se for test and support@resurs.se for production). If this is not enough, there might be a chance that other bugs must be handled by the plugin developer. If this plugin has been imported to Resurs Bank as a step to make things better, you can stop here, since they will support this plugin equally to if you ended up on this page. If the plugin is not imported, you can keep reading.

2c: Report further problems to the "community" (or the developer)

The absolutely worst way to contact a developer is to send a mail. support@tornevall.net and sometimes tomas@tornevalls.se is usually available but comes with risks: The mailboxes are not checked everyday, and you could very simply get stuck in spamfilters. Instead, use the open contact channels:

Jira: Sign up and create a bug.
Github: If you feel JIRA is too complex for you. As JIRA-licenses for servers is about to expire, I work with both JIRA and Github in parallel.
WordPress plugin page (not yet created).

Browser not supported