[alexg]

For the record, this has been resolved in version 2.0.0 of the Exchange (and later), which is compatible with version 6.0.0 of the parent plugin (and later). Sorry for the long delay guys.

[alexg]

Hello,

I have since developed this stand-alone script.

Please study the instructions in the script carefully. If you decide to use it, take a backup of your site first.

The script will migrate balances only, not transactions. There is currently no way to migrate transactions quickly. If you have any questions, please let me know.

with regards,
Alex

[alexg]

Hello,

My apologies for the late reply. Your message was marked as spam for some reason.

Thanks for bringing this to my attention.

There were several issues involved. One was that it was not possible to disable the tor setting once enabled. However, tor was not being actually used unless you had it enabled in the plugin’s HTTP settings (Settings -> Bitcoin and Altcoin Wallets -> HTTP settings -> Tor enabled).

Please update the parent plugin to 6.1.1 and the CoinPayments wallet adapter to 2.0.6. These updates fix the issues mentioned above.

However, I do not believe that this will the issue you report (i.e. API key not having permission for get_basic_info). You should definitely re-check the permissions on the API key you are using.

Additionally, it is possible that this is a cached error. In the screen with the wallet adapter settings, click on “Clear Cache”.

If you do all of the above and you continue to face problems, please let me know.

with regards,
Alex

[alexg]

Hello,

Thank you for your continued interest in the plugins.

As per GDPR regulations, I delete all accounts with more than 2 years of inactivity.

Was your account inactive? If so, you would need to pay for new membership.

If you have been paying for membership until now and your account was deleted, please email me.

with regards

[alexg]

Hello,

From the title of the transaction in the screenshot, it looks like you have selected to transfer “Addresses and Balances” only, not “Addresses and Transactions”.

In this mode, the migration will look at each user’s balance and create a new deposit, giving to the user the balance that they had in the old ledger. The transactions are not migrated. This is the recommended way because the time this takes scales with the number of users on your system, not with the number of transactions. The obvious downside to this is that transaction history is not preserved.

If it is important for you to preserve all the transactions, you can:

1. Revert the migration. This will remove all Currencies, Addresses and Transactions with the migrated tag, effectively letting you start again. Reverting will take a few cron runs, but not too many.
2. Ensure that all the currencies are created. The migration process will try to guess currencies by their ticker symbol, but it’s better if you do it manually so that there won’t be any problems. Also, if you are using any currencies that are not on CoinGecko, then you should definitely define them yourself.
3. Finally choose to migrate “Addresses and transactions” instead. This will take longer. It is also possible that some transactions may not be migrated for whatever reason, in which case all the admins (users with the manage_wallets capability) will receive emails about these transactions.

For more information, please check the documentation: https://github.com/dashed-slug/wallets/blob/6.0.0/docs/migration.md#which-one

If, while migrating transactions, you do get any errors in your emails, please let me know, so we can see what’s wrong.

If, after all transactions are migrated, the sums of user balances on the old custom SQL ledger and on the new CPT ledger will be the same, then migration was successful.

Hope this makes things a little more clear. Please let me know if you have any more questions.

with regards,
Alex

[alexg]

Hello,

This is by design:

In versions 3.0.0 and later of the payment gateway, which are designed to work with version 6.0.0 of the plugin, the funds are simply subtracted from the user’s balance, with a credit transaction. Since the user will have deposited funds to gain that balance, any funds subtracted from their balance simply belongs to the site.

Also see the glossary definitions for “Hot wallet balance” and “User balance” for more details on this.

It’s best to think of it with an example. Say user A deposits 1 Litecoin. Then, their LTC balance is 1, and the site’s hot wallet balance for LTC increases by 1. Then, user A purchases a product that costs 0.5 LTC and checks out. Now the user’s balance is 0.5 LTC, but the hot wallet balance remains on the site, and can be withdrawn to an external wallet using the Cold Storage tool.

In case of a refund, the user’s balance is increased again and the order is marked as refunded. Nothing else changes. You can see an example of a checkout transaction and a refund transaction here:

(In versions prior to 3.0.0, the WooCommerce payment gateway did indeed transfer funds from the buyer to a designated admin account. This is no longer the case.)

Hope this is clear, please let me know if it’s not, or if you have any more questions.

with regards,
Alex

[alexg]

Hello,

Thank you for reporting this issue. I need more information.

1. To be clear, can you please tell me which wallet adapter the transaction was executed with? CoinPayments, Bitcoin-like, or other? Also, what was the currency?

2. Which version of the plugin and extensions are you using? The latest version for the parent plugin is 6.0.0 on WordPress.org, and the latest CoinPayments wallet adapter is at version 2.0.3.

Please check the plugin versions, because there was an issue related to this that I solved in RC9 (and therefore the current 6.0.0 stable).

3. Does this happen with all withrdrawal transactions? Do you have other withdrawals that succeed, and only this one got cancelled?

If you can, please email me screenshots of the transaction details in the plugin. If the withdrawal was done with the CoinPayments wallet adapter, please also show me the transaction details in the CoinPayments withdrawal history, or the IPN message.

Thank you.

with regards

[alexg]

Hello,

I’m sorry that you are experiencing this problem.

If you have decided to migrate all balances and transations, then it is possible that the old custom SQL balances and the new CPT balances may not match.

This will happen if, during migration, a transaction cannot be created as a CPT for some reason. Typically this will happen if the migration task cannot create the transaction because it can’t auto-create the associated currency. In any case, if any such error occurs, then the admins will be notified by email with details about the error. You can then go and see what the problem was, and maybe create the transaction manually. A good idea is to first create all currencies manually, and then let the migration task migrate the transactions. This will ensure that such errors will not occur. If you let the migration task auto-create the currencies, then things can go wrong in some cases.

If you have decided to migrate only the balances, then all the new balances should be equal to the old ones. You can revert the migration, and once it is fully reverted, you can retry by migrating only the balances.

The market_not_enumerable error indicates, again, that there is a problem with the currency associated with the market. Please check your market by visiting /wp-admin/post.php?post=5104&action=edit and re-assign the currencies to the market.

My recommendation is that you:

1. revert the migration
2. create manually all the currencies that the old system was using
3. rerun the migration (either transactions or balances only)
4. if you get any errors in the admins’ emails, then address them
5. check your markets and ensure that the correct currencies are assigned

If you choose to migrate the balances only, then it is almost certain that there won’t be any problems with balances, but the old transaction history will not be shown. In any case, pay attention to any migration-related emails.

Hope this helps.

with regards

[alexg]

Hello,

This makes sense. It’s good that you upgraded to 6.0.0, but this will not solve the network issue.

Assuming that 162.0.217.62 is the IP of the WordPress host, add the rpcbind config line:

rpcbind=162.0.217.62

And restart the wallet.

If it still doesn’t connect, then the issue is with some firewall, possibly one controlled by your hosting provider.

with regards

[alexg]

Hello,

If you are certain that the TCP port is open on any software firewalls onyour VPS, you should also check:

– If you have set the rpcbind config set correctly.
– Check with your hosting provider, they are likely running their own firewalls. They can add an exception for you.

Since you mentioned that you are on a VPS, know that during the IBD (Initial Blockchain Download), the wallet may use more resources (CPU, net) than you are allowed to use on a sliced host. In that case, your host may be auto-banned. Many hosts do this, depending on what rules they have. You may need to talk to them about this as well.

with regards,
Alex

[alexg]

Sorry about this. Fixed.

Please let me know if it happens again.

[alexg]

Hello,

Here is some CSS code that will set the text to blue and the background to red in all input fields, including currency dropdowns and textareas:

.dashed-slug-wallets input,
.dashed-slug-wallets textarea,
.dashed-slug-wallets label.coin select,
.dashed-slug-wallets label.coin select option {
	background-color: #f00;
	color: #00f;
}

Your code for the dropdowns did not work for two reasons:
1. You likely want to apply the background to both the select element and the option element.
2. CSS rule specificity: There was already a rule for .dashed-slug-wallets label.coin select which is more specific than .dashed-slug-wallets select. In CSS, more specific rules override less specific ones. If you inspect an element with your browser’s dev console, it will tell you which CSS rules apply to the element and in what order, and also where they are coming from (i.e. theme, plugin, browser, etc). There are multiple tutorials on rule specificity on the web. For example: https://css-tricks.com/specifics-on-css-specificity/

Regarding the input[type="submit"] button and the input[type="button"] button, you can again inspect the elements with your browser. Your theme may be applying styling to html form buttons, both in their normal state and the :hover state. To override these, you will likely need to match the specificity of the rules as they are used in your theme.

For example, I was able to apply colors to the buttons like so:

.dashed-slug-wallets input[type="submit"],
.dashed-slug-wallets input[type="button"]
{
	background-color: #f00;
	color: #00f;
}

.dashed-slug-wallets input[type="submit"]:hover,
.dashed-slug-wallets input[type="button"]:hover {
	color: #ff0;
}

The above gives the buttons blue text and red background, but on hover the text turns yellow.

But if there is a theme rule starting with article input[type="submit"] it will be more specific, so you need to match that in your rule if you want to override the theme rule.

Hope this helps.

with regards

[alexg]

I have included a table in the migration tool that shows the values before and after migration. This way you can verify if all the transactions were migrated correctly.

There are multiple reasons why migrating a transaction might not work, especially if you are attempting to migrate all transactions, rather than just the balance totals. Knowing why a transaction was not migrated depends on the specifics, i.e. you would have to go into each user’s transactions and look to see which transaction was not migrated. Looking at the verbose logs during migration may also help.

If you can identify a transaction that was not migrated, I may be able to help you understand why.

Did you attempt to migrate transactions or balance totals? I believe it’s safer for most people to migrate balance totals only, and then move forward from that, unless if it’s absolutely vital for you to preserve transaction history.

[alexg]

Hello,

I have tried to add some guard clauses in version 2.0.1. Hopefully this resolves your issue.

It looks like you were listing the markets in the admin screens, but a reference from a market to a (base or quote) currency was no longer available. Possibly a currency was deleted. The plugin can now handle this situation without crashing.

If the issue is not resolved, please let me know what you were trying to do when you saw the error, and whether you were on multisite.

with regards

[alexg]

Hello,

Looks like a market has no currencies assigned.

I will look at this and release a patch today.

Thank you for reporting this issue. I will notify you again here when the patch is out.

with regards

[Author]

Posts