[alexg]

Hello,

I hope you have a great year too.

Yes, you are referring to the setting “WCMp” -> “Settings” -> “Payment” -> “Payment Gateway Charge”. I have not implemented this. I will look at it as soon as I can.

Thank you.

with regards

[alexg]

Thanks, that’s an excellent question. In fact, I might have to add this information to the documentation.

I am not certain how you plan to dockerize your WordPress, but if all the WordPress containers connect to a single MySQL database and a single wallet, you will not have any problems.

DEPOSITS:

You can designate one instance to be responsible for receiving notifications. This instance will be inserting deposit transactions into the DB. All other instances will immediately see the transactions in the DB.

Alternatively, if you prefer, you could have more, or all the instances receive the notifications, if you think this is needed. To do this, you would modify your curl command so that it is now two or more curl commands, running in parallel with the Unix shell & operator. This would look something like:

walletnotify=curl -sk 'http://FIRST.IP.ADDRESS.HERE/?__wallets_action=notify&__wallets_symbol=BTC&__wallets_notify_type=wallet&__wallets_notify_message=%s&__wallets_api_version=3' & curl -sk 'http://SECOND.IP.ADDRESS.HERE/?__wallets_action=notify&__wallets_symbol=BTC&__wallets_notify_type=wallet&__wallets_notify_message=%s&__wallets_api_version=3'

If a transaction has already been written to the DB, then another instance attempts to write it too, the transaction row will simply be updated with the latest confirmation count. Only the first instance that inserts the transaction will send a notification email.

WITHDRAWALS and internal transfers:

Operations that modify the database are all guarded with table locks, so consistency is guaranteed even if several instances are hitting the DB at once. For example, a typical run of the function cron_execute_pending_withdrawals() would do the following:

1. lock the transactions table
2. read in a batch of pending withdrawals
3. try to execute them, and send email notifications as needed
4. unlock the table

Any other instances running cron would have to wait for the DB to unlock, so there is no danger of double-spends. The same is true for internal transfers (moves).

You might still prefer to have one instance be the only one that runs cron tasks. In that case, you cannot use the plugin’s settings to disable cron jobs from the other instances, as all instances share the same DB and therefore the same wp_options table (settings). You will have to use the DISABLE_WP_CRON constant in all the instances except the one that you use for running the transactions.

I hope I have answered your question adequately.

I have moved this to a new thread as it is unrelated to the previous thread.

Please let me know if you have any more questions.

Also, if you ever attempt to run the plugin in multiple containers, I would love to hear about your experience, and if you encountered any difficulties.

with regards

[alexg]

Hello,

Thanks for the logfile. Here’s my findings:

1. The plugin does not receive any deposit addresses at all from the wallet.

2. You have also installed the CoinPayments adapter, but you have not given all the permissions to your API key. Please check step #23 of the instructions and add the missing permissions.

To answer your questions:

The IP needs to be reachable from the machine where WordPress runs. You cannot easily use a home computer or other computer that is only reachable via NAT. Additionally, this is highly not recommended. You should use a server whose IP is reachable from the internet. If you need to check, use a tool such as http://www.canyouseeme.org/ to see if your wallet’s port is visible from the internet.

The plugin pulls the deposit addresses from the wallet as needed. To do it any other way would simply confuse things. Also, it is likely that withdrawals will also not work until you resolve this issue.

At this point I would recommend that you do the following:

1. Make sure the wallet is running on a server with a public IP. You need to allow connections to the wallet. Check with a port checker tool as discussed above.

2. Disable all unrelated plugins, including the CoinPayments adapter, and leave only wallets and the multi coin adapter. Then, try again.

3. If the above fails, show me the code you used to add the coin to the multiadapter, AND the .conf file. Remove any passwords from the file before you send it to me but otherwise leave it intact. There might be a problem with your rpcallowip setting, or some other issue.

Hope I have answered your questions.

Let me know how it goes.

with regards

[alexg]

Thank you.

To be clear, the information I am looking for would be in your WordPress debug log. The screenshots you sent me are the JSON API response, and the coin adapters screen. The adapter is indeed in a responding state, which is a good sign.

So, if you have not already done so, please do the following:

1. Enable debugging by adding to your wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Then, visit the get_coins_info JSON API call again.

Afterwards view the file wp-content/debug.log. The debug information will be in there. Look for the lines with the date/time that you performed the API call at.

2. About the firewalls: There might be more than one types of firewalls/security programs on the WordPress server and the wallet server. You can disable them for testing, but do not keep them disabled. You should understand how they work and allow TCP connections outgoing from your WordPress server to your wallet server on port 44062. Are these on separate machines or on the same machine? If they are on the same machine, then it is not likely that a firewall is the problem.

3. Finally, if you like, show me how you added your coin to the multi-coin adapter, as there might be some issue there.

[alexg]

Hello again,

In addition to my previous post:

I have located the github repo from your website, and have tested your wallet with the plugin. The plugin correctly shows deposit addresses beginning with the letter “D”.

Since everything seems to work fine here, this means that you are probably facing some type of connectivity issue. Please respond to the points 1 to 3 above, and disregard #4.

with regards

P.S. In several places throughout your website, you ask for people to “undermine” your currency. I believe you want to ask them to mine it instead.

[alexg]

Hello,

Unfortunately I have not found the time to work on the Faucet yet. You are correct, this does not work and I will try to provide a solution as soon as possible.

Will let you know, hopefully soon.

with regards

[alexg]

Hello,

Are you using the latest version, 1.1.0 ?

In version 1.0.2 I had added some code that deletes airdrop deposits with zero amount. The code runs the following SQL, after each new airdrop:

DELETE FROM
	wp_wallets_txs
WHERE
	category = 'deposit'
	AND amount = 0
	AND tags LIKE '%airdrop%';

What happens if you run this code in your MySQL console? (back up your database first for safety, and replace wp_ with your actual DB prefix if it is different)

I ask because this problem should have already been solved. If not, I need to know why not.

If possible, could you please also tell me the version of MySQL that you are running? You can find this in your admin dashboard under “Bitcoin and Altcoin Wallets”.

thank you

with regards

[alexg]

Hello,

Thank you for all the feedback.

Both of the errors you report are a consequence of there not being a deposit address. The first indicates that the frontend cannot operate without a deposit address, the second error comes from the database and is about the same thing.

1. The code I sent you should print out something else as well. Are there any lines starting with “ADDRESS1” or “ADDRESS2” in your logs? These should be written out when you load the page (i.e. when the get_coins_info JSON API is called. Are these found in your logs?

2. It seems that for some reason the connection to the wallet does not return an address, even though you say that getnewaddress works from the command line. Check the adapters screen. Is the status of your full node wallet “Responding”?

3. Is the wallet running on the same server as WordPress? If not, have you managed to connect successfully? If there are firewalls in the middle you would get slow connection and/or timeouts.

4. If you can point me to the git repo for this wallet I might be able to test it myself, although the problem is probably with your network setup.

with regards

[alexg]

Hi Alex,
do you have found a solution?

[alexg]

Hello,

It seems you added the PHP code in the style.css file. It should be in your functions.php file. The CSS file is for styles only.

Don’t forget to add the php start tag. There should be a <?php on the first line of the file.

Once you run this code, there will be some debug info in your log file. These will help us determine where the problem is.

with regards

[alexg]

Hello,

I’m glad you resolved the issue. Some comments:

You only need to trigger cron yourself if the WordPress cron job does not execute automatically via WordPress, or alternatively you can do this to improve performance, but it is not strictly necessary otherwise.

You should not rely on the plugins to load in any particular ordering. In fact, this is why we use hooks in the first place, to avoid race conditions on the interfaces between different plugins/themes and WordPress itself. I see from your commented out code that you already know about priorities. As long as you bind your hooks correctly they should execute in the correct precedence.

If you are running two WordPress instances connecting to the same wallet instance, you need to be careful to maintain enough hot wallet balance for both instances. Personally I don’t think it’s a good idea in terms of security. But if you want to do this, you would need to modify the walletnotify command to do a curl on both your WordPress instances. This will allow both sites to be notified of any new deposit transactions. The plugin will know to record each transaction on the correct site only.

with regards

[alexg]

My apologies, the correct code is:

function test_diners_new_address() {
	$adapters = apply_filters( 'wallets_api_adapters', array() );
	if ( ! isset( $adapters['DNS'] ) ) {
		error_log( 'DNS adapter not found' );
	}
	$address1 = $adapters['DNS']->get_new_address();
	error_log( 'ADDRESS1: ' . print_r( $address1, true ) );

	$address2 = apply_filters( 'wallets_api_deposit_address', null, array( 'symbol' => 'DNS' ) );
	error_log( 'ADDRESS2: ' . print_r( $address2, true ) );
}

add_action( 'init', 'test_diners_new_address' );

[alexg]

Thank you.

You are correct that now() is a better alternative.

current_time() returns the time only (not date) and it seems that in some versions of MySQL, the date is assumed to be today but in others it might not, hence the issue you experienced.

In any case, I have modified the code to use the WordPress locale-aware date/time as is done with other transactions. This will be out in the next release of the Airdrop extension.

Thank you for your feedback.

with regards

[alexg]

The VATIN in your profile is exactly the same as it was before.

If you cannot change it via your profile screen for some reason, then email me the number and I will enter it myself to your account.

with regards

[alexg]

In the latest version 3.9.3 of the plugin, the actions are now reporting the correct latest status and retry count for both move and withdraw transactions.

[Author]

Posts