[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

[alexg]

Hello,

Your last payment was on the 19th of September and your account is currently inactive.

Next time you need to download something you can pay with cryptocurrencies.

with regards

[alexg]

Hello,

Unfortunately it is not possible to connect omni layer assets at this time.

What would be required, would be for someone to develop a wallet adapter for such assets.

In case you are interested, instructions for developing wallet adapters are here:

https://github.com/dashed-slug/wallets/blob/6.0.0-RC5/docs/developer.md#developing-wallet-adapters-wallet-adapters

A wallet adapter is a PHP object that derives from a base class provided in the plugin. Its main jobs are to discover deposits for the plugin and to perform withdrawals at the request of the plugin.

Unfortunately I do not have time to develop an omni layer wallet adapter. Whenever I have time for development, I am working on a bitcoin lighning (lnd) adapter, and its natural continuation will probably be to connect to tarot assets. Only time will tell what I actually manage to develop, since everything is fluid right now. I have also been looking into the infura API for ERC-20 assets, but this requires significantly more work, mostly key management.

Hope this answers your question. Let me know if you have additional questions.

with regards

with regards

[alexg]

Hello,

If I understand correctly, you want users to be able to set a single withdrawal address per currency, that is then locked using a 2FA code. Subsequent withdrawals will only be allowed to that address, until the address is changed again using a 2FA code.

Such functionality does not exist yet, but I will add it to my backlog and will try to implement it when I can.

Thank you.

[alexg]

Hello,

I no longer accept feature requests, but I believe most of the functionality you describe is already in version 6.0.0:

In the settings for each Currency, there is a section titled “Withdrawal limits”. You can set a daily limit overall, or per user role. If you set a user role, the Primary role of the user is taken into account.

As for 2fa, if you can give a different user role to users who have enabled 2fa, then you can set a higher limit to these users.

Hope this helps.

with regards

[alexg]

Hello,

You can find the shortcode reference for version 5.x here:

Wallet shortcodes

I just had to escape the old shortcodes, since I’m now using the plugin on the site.

Thanks for noticing this issue.

with regards

[alexg]

Hello,

For consistency reasons, the UI always shows the dropdown, but you can easily hide or remove it.

A simple CSS rule to do this would be:

.dashed-slug-wallets .coin { visibility: hidden; }

Hope this helps. Let me know if you have any more questions.

with regards

[alexg]

Hello,

I have tested the faucet again using settings like those in the above screenshot, and the payout was correct on my end.

Can you please show me the Currency page for Dogecoin?

At a minimum please check the following:

1. Under “Decimal places” you should have 8.

2. Under “Exchange rates”, next to EUR, you should have a value close to 0.084 currently, based on recent prices.

3. Under “CoinGecko ID”, you should write dogecoin, which is the CoinGecko ID for dogecoin. This will allow the latest exchange rates to be updated for dogecoin.

4. Please check if the cron jobs are running. If you go to Dashboard → Bitcoin & Altcoin Wallets → Debug → Cron jobs last ran on, the time shown there should be recent. That is the last time the exchange rates were updated.

The exchange rates come from CoinGecko.

If you believe everything to be correct on your end, and the payout is still wrong, you can email me some credentials and I can log in to your site and check.

with regards,
Alex

[Author]

Posts