[alexg]

OK you have a somewhat strange problem indeed! Never come accross this one.

I find it very curious that your IPN history is empty. I assume that by “removed all data” you mean that you also emptied the wp_wallets_adds table. As I mentioned before, this data is not deleted when you uninstall the plugin.

Here’s what you can check:

Every time the plugin requests a new deposit address, a “callback address” is generated on the CoinPayments platform. You can then view these callback addresses via the dashboard. For Litecoin testnet, navigate to https://www.coinpayments.net/index.php?cmd=acct_balances&action=deposit&coin=LTCT

You should see your deposit address listed there. It’s type should be “commercial”. If that’s the case, then when you send funds to that address the platform should attempt an IPN to your site, regardless of what the plugin, or anything on your server, does.

[alexg]

Hello,

First of all yes, this is the right place to post issues with the plugin. For issues that are about the main plugin you may also post at the wordpress.org forums, but here is fine too.

As for your particular issue, the UIs will only show when there is at least one adapter that is in “responding” status. So this is expected behavior.

You may also refer to the “troubleshooting” section in the PDF documentation, under “I do not see the UI elements in the frontend.” I try to keep a record of the most common issues people face.

regards
Alex

[alexg]

Hello,

I believe what is happening is this: You generated a deposit address while you had entered an IPN URL. This didn’t work because the IPN URL, if present, should end with ?wallets-cp-ipn=1 . Then I told you to remove the IPN URL but the deposit address you had generated still had a faulty IPN. When you uninstall the plugin, the tables are not being deleted. This is done for safety. So the old deposit address remains. You could try to empty the addresses table. This will force the plugin to regenerate new deposit addresses. You can do this with the following SQL query:

TRUNCATE wp_wallets_adds;

making sure to replace wp_ with whatever your table prefix is. Then, try a new deposit to that address. If you want to test with LTCT, you can use this faucet to send testnet Litecoins: http://testnet.litecointools.com/

Try this and wait a few minutes. The deposit should work.

If not, we will need to look at the following:

1. Does the [wallets_deposit] shortcode show you deposit addresses?

2. Are there IPN attempts in your IPN history?

3. If there are IPNs what is their status? The CoinPayments platform lets you view whether an IPN message was received or not.

4. Are there any errors in your logs? Instructions for enabling the logs are here: https://codex.wordpress.org/Debugging_in_WordPress

Apologies, but I only offer support over email and the forums. This is also mentioned in the terms of service. There are good reasons for this. I do try to reply as quickly as possible whenever I am not sleeping or away from work.

Give this a try and let me know. Hopefully it will work now, but if not, please answer the above questions so we can find out what’s wrong.

kind regards

[alexg]

I have not yet found the reason why the plugin did not work to begin with.

The SQL I sent you was exported from my machine. Most of the collation and charset directives are not needed. Only the ones that refer to the latin1 charset. You should be OK with MySQL 5.5. I have edited the SQL code and removed any unnecessary charsets. Your system should now use whatever is default for the columns where it doesn’t matter.

So please do another attempt. Use the same pastebin link. I have edited it.

[alexg]

Additionally, try leaving empty the IPN URL altogether. There is no need to specify this as it is being set by the plugin on each callback address. The full IPN URL constructed by the plugin is something like http://example.com/?wallets-cp-ipn=1 but you do not need to worry about this.

[alexg]

Thanks, I didn’t know about this. I had never tried IPN with IP addresses instead of domain names.

To clear up any confusion:

Every time you send cryptocurrencies to a deposit address, CoinPayments will do an HTTP request to your site. We need to know 1) if it is being sent and 2) if it is being received. The “IPN history” page allows you to see both of these things. The screenshots you sent earlier indicated that no messages were being attempted. Probably due to the missing trailing slash.

At the very least you should now be seeing IPN attempts on CoinPayments, even if the messages do not arrive at your site.

Let me know how it goes.

regards
Alex

[alexg]

Hello,

A few people have reported this issue in the last couple of days but I was unable to reproduce the problem in a number of setups.

Is it possible for you to enable logs and send me whatever gets written out while you activate the plugin? Instructions for enabling logs are here: https://codex.wordpress.org/Debugging_in_WordPress This will help me know what’s wrong and what to fix.

Alternatively you can use the following SQL code in your console, to create the tables manually.

https://pastebin.com/huhbVPDT

The above code assumes that your DB prefix is wp_. If it is something else, you will need to replace the table names.

[alexg]

OK, first things first.

I only mentioned the csv export because I thought you wanted to migrate an existing transaction from one machine to another. If you have not performed any successful transaction yet, just ignore the export/import thing.

Also, if your IPN history is empty, that means that the CoinPayments platform never attempted to notify the plugin of any deposits. Could it be that you have not setup IPN correctly? Please confirm that you have followed the installation instructions on https://www.dashed-slug.net/bitcoin-altcoin-wallets-wordpress-plugin/coinpayments-adapter-extension/ and in particular the part where you create an IPN secret and set in the coin adapter settings.

[alexg]

If you have transferred the entire database contents then yes the transaction should show up. If you only did an export via the WordPress admin, that would not have transferred the transactions and addresses tables. The tables are normally named wp_wallets_adds and wp_wallets_txs.

You can also use the plugin to export the transactions to a csv file and reimport them to the new installation: To transfer the transactions, go to Wallets -> Adapters and choose the “export transactions to .cvs” next to each coin whose transactions you want to transfer. You can then go to the new installation to Wallets -> Transactions and at the end of the page, import the csv file. That should transfer your transactions.

As for IPN history, since you were running the plugin locally, there should be failed attempts listed in your history when you log in to coinpayments. But now that you are running the plugin on a server the IPN requests should succeed.

[alexg]

Hello,

Could it be that you are running WordPress on a machine in your local network?

Deposit notifications come to your WordPress from the CoinPayments platform via their IPN mechanism. This is HTTP/HTTPS requests coming from CoinPayments. If your installation is not facing the outside world you will either have to install on a VPS or otherwise set up your firewall to forward these requests.

Check your IPN history in CoinPayments and see if the notifications succeed.

let me know

regards,
Alex

[alexg]

This is now out, see https://www.dashed-slug.net/exchange-rates-yobit-cryptopia-bitcoin-altcoin-wallets-wordpress/

[alexg]

Hello,

In the next release of bitcoin and altcoin wallets, 2.8.0 there will be a possibility to also use exchange rates from yobit or cryptopia. This will be out tomorrow.

regards,
Alex

[alexg]

Thanks for providing all of this information.

The screenshots from the CoinPayments account are irrelevant. You wouldn’t expect to see anything there.

I see that communication with the API works (adapter status is responding). You mentioned that the issue was with internal transfers being stuck in the unaccepted state. This is an internal operation that should only affect the database.

I’m afraid that due to your setup being unusual, you have an unusual issue. I will have to ask you to insert some debug logs into the code. That’s the fastest way to debug this and move forward.

As I mentioned earlier, the code that should be transitioning your transactions from unconfirmed to pending is in includes/confirmations.php, in function confirm_transactions(). You could start by adding a debug log in that function, then check your logs to see if it executes. Add the following:

error_log( __FUNCTION__ );

and you should see the name of the function in your logfile. Make sure that logging is enabled in your wp-config.php first.

Also, if that function runs and fails it will print out “failed to update unconfirmed moves between users.” Look for that in your logs too. As well as any other suspicious errors.

Let me know what you find. This shouldn’t be hard to debug.

[alexg]

Before attempting anything else, update to the latest patch version, 0.4.1-beta.

[alexg]

Normally no, you shouldn’t do anything to make sure cron works. In fact the plugin will warn you if it doesn’t.

The WordPress cron mechanism is not exact – it executes pending actions on the next page refresh. Some people choose to force WordPress cron to execute more regularly by triggering a curl request on the site, but this is rarely necessary. You can read about it here https://developer.wordpress.org/plugins/cron/hooking-into-the-system-task-scheduler/

Have you been able to determine if there are errors in the logs and if wp_mail works on your system?

If you don’t find anything in the logs you could insert some error_logs into the confirm_transactions() function to see if it runs, what it does, and if it fails at some point. Normally it is the one that should be changing your transaction status from unaccepted to pending.

[Author]

Posts