[alexg]

@realslug Hello, the 45 second delay is almost definitely a TCP timeout. This means that some firewall is blocking you. If your hosting plan is managed then you need to negotiate this with your hosting provider. If you are on an unmanaged machine (where you hold the root account), then you need to check your firewalls. In any case, this type of delay is always due to a firewall of some type.

Thank you @san for posting this link. It will be relevant after the OP manages to connect to the wallet directly.

with regards

[alexg]

Hello,

This is expected behavior:

The user has already submitted a withdrawal and it is in pending state, therefore this balance is now locked.

The site’s admin should now go to Tools -> Fiat Withdrawals and mark the withdrawal as done, once the fiat amount is sent to the user.

Alternatively, the admin can cancel the withdrawal and the funds will be again “available”.

The concept of unavailable balance is described in the glossary section of the manual.

with regards

[alexg]

Generally there are two difficulties:

1. Make sure that the firewalls on the wallet server allow incoming TCP connections to the wallet’s RPC API. Before trying to connect using WordPress, it might be worth trying to connect using bitcoin-cli or even nc. Check your firewalls, ip filters, etc.

2. Once you get the connection to work, the next problem is that it’s not encrypted. You can’t use SSL as it was removed from bitcoind. You can set up an ssh tunnel to encrypt the connection, but the difficulty here is to maintain the tunnel even after server restart. Have a look here to get an idea of what’s involved: https://gist.github.com/EnigmaCurry/bdd9fd28d7a73fe52eb4 The first step is to open the tunnel using ssh from your WordPress host to the remote wallet’s socket. Then make the plugin connect to the local port instead of the remote one. Once you get this to work, you can setup a unix cron job that checks if the tunnel exists and if not, recreate it. In the script above you can see how to use netstat to check if the port is open.

Best of luck!

[alexg]

That is correct 🙂

glad you found it

[alexg]

That’s ok, thanks! 🙂 As for updating to the latest version, the issue is fixed now. Thank you for reporting it!

After communicating with a representative from wordpress.org I found out that the problem was caused by too many svn tags on the repository.

I followed the official recommendation about deleting old versions. I have now retained only the latest patch release from each major version, plus all the recent minor and patch releases after 4.0.0.

If anyone needs to download the other releases of the plugin for historical reasons, they are always available in the download section and on github.

with regards

[alexg]

Hello,

I have investigated this issue and it seems to be a problem with wordpress.org. If you attempt to download the latest version it gives you 4.2.1. I have contacted the good people at wordpress.org and this should be sorted soon. I will keep you updated here about this.

In the meantime, if you wish to update to version 4.3.0, you can extract the files manually into your wp-content/plugins/wallets directory. The latest plugin zip file can be downloaded from here: https://www.dashed-slug.net/downloads/

The other warning coming from the Monero coin adapter is not related and does not seem serious. I will investigate. Did you experience any issues with the Monero adapter? If possible, in the future, please post issues with the Monero adapter here: https://www.dashed-slug.net/forums/forum/monero-coin-adapter-extension-support/

with regards

[alexg]

Version 4.3.0 has a fix for the bug with QR codes in static deposit UIs.

Additionally, it is now possible to set a site-wide default coin (Frontend Settings) or to set the default coin for a page or post (via a new meta box).

[alexg]

Hello Mirven,

Thank you for the suggestion. I am taking note of the guide you sent me.

Unfortunately, this feature would definitely take more time than you suggest, and I am currently very busy with other dashed-slug extensions.

If I do find the time to implement such a payment gateway, then I will let you know on this thread. However this is unlikely for the time being, as I have already provided a solution for multivendor shops, and there is much work to be done elsewhere.

with regards

[alexg]

Hello,

The correct way to display a QR code for a specific coin is to use the static template, as you discovered.

Since the static templates are new, it might be a bug. I will investigate and let you know here as soon as possible. Thank you for reporting this.

with regards

[alexg]

Hello,

If your database version is earlier than 5.6, then CONVERT_TZ() will not work and you can use DATE_SUB() or some other method. I believe you should remove some extra characters from your query, so rewrite your code like so:

$sql3 = "SELECT COUNT(*) FROM $walletTable WHERE DATE_SUB(created_time, INTERVAL 6 HOUR) >='$fromDate' AND DATE_SUB(created_time, INTERVAL 6 HOUR)<='$endDate' AND account='$account' AND category='move' ";

If you don’t trust your inputs, you should use $wpdb->prepare() instead of relying on PHP string interpolation to insert the variable values. But if you are in control the inputs it should not matter.

with regards

[alexg]

You could try something like

SELECT COUNT(*) FROM wp_wallets_txs WHERE CONVERT_TZ(created_time,'+00:00','-06:00')<= etc…

in your queries

[alexg]

Hello,

I see two problems here:

1. The times in your database are not “+6” hours, they are in UTC and your timezone is “-6” hours.

If all the database entries are in correct UTC time, rather than local time, then you should leave them as they are (i.e. not modify the original data).

Then, it is easy to construct a query that converts this data to any timezone and choose and export a particular day according to your local time.

2. This is not how you would construct such an SQL query. You’d have to use MySQL’s date/time functions. I would start by creating a temporary table or view or subquery with the offset data ( see CONVERT_TZ() ), then select from that data.

with regards

[alexg]

This is now fixed in 0.7.3-beta of the Exchange. Thanks again!

[alexg]

OK thank you for the screenshots. I’ll summarize some observations so we can be on the same page:

– The times in the database are meant to be stored in UTC.

– Your server’s timezone is set correctly to GMT-6.

– Your wallet server is in GMT-4, but this should not matter, since the RPC API of bitcoin-like wallets returns timestamps in GMT.

– Assuming the DB view you show me is sorted by primary key, it seems that all the times are stored in correct UTC.

– In the frontend, you see times for withdrawals offset by 4 hours. (This probably has to do with the timezone of the machine where the browser runs.)

Because I don’t know when you performed these transactions, it’s still unclear to me:

1. For internal move transfers, is the correct UTC timestamp shown in the database? If not, what’s the offset to the UTC time when you performed the tranasaction?

2. For deposits/withdrawals, is the correct UTC timestamp shown in the database? If not, what’s the offset to the UTC time when you performed the tranasaction?

Once I understand these two things I can determine what’s the right way to offset the times in the frontend and in your CSV export. I am still not clear on whether all the UTC timestamps are correct in the database, so please try to answer 1 and 2.

Thank you.

[alexg]

Thank you for all your feedback!

WordPress normally clears transients when the delete_expired_transients action fires, this is scheduled as a wp_cron event. I’m guessing that if for some reason cron is disabled, transients may not expire. I will investigate if forcing a call to delete_expired_transients() every now and then helps. Also, if you are very low on memory it is possible that WordPress is crashing before getting to run the wp_cron tasks.

with regards

[Author]

Posts