[alexg]

I will change the code so that every user can claim once per IP per coin, and add the translation.

thank you again for your feedback!

[alexg]

Yes, apologies, there was a comma missing in there. Please try:

CREATE TABLE wp_wallets_adds (
	id int(10) UNSIGNED NOT NULL,
	blog_id bigint(20) NOT NULL DEFAULT '1' COMMENT 'blog_id for multisite installs',
	account bigint(20) UNSIGNED NOT NULL COMMENT 'wp_users.ID',
	symbol varchar(5) COLLATE latin1_bin NOT NULL COMMENT 'coin symbol (e.g. BTC for Bitcoin)',
	address varchar(255) COLLATE latin1_bin NOT NULL,
	extra varchar(255) COLLATE latin1_bin NOT NULL DEFAULT '' COMMENT 'extra info required by some coins such as XMR',
	created_time datetime NOT NULL COMMENT 'when address was requested in GMT',
	status enum('current','old') NOT NULL DEFAULT 'old' COMMENT 'all addresses are used to perform deposits, but only the current one is displayed'
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin;

Index creation was correct:

ALTER TABLE wp_wallets_adds
	ADD PRIMARY KEY (id),
	ADD UNIQUE KEY uq_ad_idx (address,symbol,extra),
	ADD KEY retrieve_idx (account,symbol),
	ADD KEY lookup_idx (address);

Do let me know.

regards

[alexg]

Hello,

I’m fine thanks (just one guy, not guys!), how are you?

Your error is somewhat rare. When the plugin is first activated it creates two tables, wp_wallets_txs and wp_wallets_adds. It then does a check to see that these tables have been successfully created. This would show up if the tables did not exist. Can you please verify via phpmyadmin or via the SQL CLI whether these tables exist?

Please send me the output of the following queries:

SHOW TABLES LIKE '%wallets%';

and

SELECT VERSION();

You could also try to create the table yourself with the following two DDL commands:

CREATE TABLE wp_wallets_adds (
	id int(10) UNSIGNED NOT NULL,
	blog_id bigint(20) NOT NULL DEFAULT '1' COMMENT 'blog_id for multisite installs',
	account bigint(20) UNSIGNED NOT NULL COMMENT 'wp_users.ID',
	symbol varchar(5) COLLATE latin1_bin NOT NULL COMMENT 'coin symbol (e.g. BTC for Bitcoin)',
	address varchar(255) COLLATE latin1_bin NOT NULL,
	extra varchar(255) COLLATE latin1_bin NOT NULL DEFAULT '' COMMENT 'extra info required by some coins such as XMR'
	created_time datetime NOT NULL COMMENT 'when address was requested in GMT',
	status enum('current','old') NOT NULL DEFAULT 'old' COMMENT 'all addresses are used to perform deposits, but only the current one is displayed',
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin;

ALTER TABLE wp_wallets_adds
	ADD PRIMARY KEY (id),
	ADD UNIQUE KEY uq_ad_idx (address,symbol,extra),
	ADD KEY retrieve_idx (account,symbol),
	ADD KEY lookup_idx (address);

If you get any errors while creating the table, please post it here.

Thanks

kind regard,
Alex

[alexg]

Thank you.

This is a common issue with the TGMPA library. This is a common library for tracking dependencies between WordPress components (themes and plugins).

Some themes do not load TGMPA correctly because they assume that no other plugin is using that same library.

Simply delete the file wp-content/plugins/wallets-multiadapter/includes/third-party/TGM-Plugin-Activation/class-tgm-plugin-activation.php for a quick workaround. Do the same for all other dashed-slug extensions that you may have installed.

Ideally you should tell the theme developers to load TGMPA only if not previously defined.

kind regards

[alexg]

Yes, the backend will already reject a withdrawal that is too small. A frontend check will be added for the convenience of the users.

[alexg]

Hello,

Thanks for reporting. You’ve already done the first step which is to identify the component that causes the problem.

The best way to debug this is to disable your theme, then observe the logs while enabling the theme. If you cannot access the admin screens to deactivate the theme, simply delete its directory from wp-content/themes

There will be some PHP error written out at the moment when the theme is being enabled. If you have ssh access to your server, use tail -f on your PHP error log. This should be somewhere under /var/log on most Unix systems.

You should also enable WordPress logging: https://codex.wordpress.org/Debugging_in_WordPress

This will let you observe a log at wp-content/debug.log. At the very minimum I would recommend that you insert the following to your wp-config.php:

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

Please post here any errors that are generated at the moment the white screen is shown. We will then need to decide if this is something that I need to fix or if it needs to be fixed by the theme developers.

kind regards
Alex

[alexg]

About the issue with the missing deposit: It seems the IPN message was delivered to the plugin. Therefore there should be a deposit transaction in your Admin → Transactions screen. Can you open up the details of the IPN message and verify that there is no error message? Also, can you confirm that the deposit address associated with the IPN message is bound to a user? You can do a SELECT * FROM wp_wallets_adds WHERE address=’ADDRESS’;to make sure, substitutingADDRESSwith the actual address andwp_` with your actual SQL table prefix.

About your other question, this is not how this plugin works. If you insist on doing this, you could look at WordPress actions in PHP in the documentation section Notifications. You can essentially be notified of incoming deposits by binding to the wallets_deposit action, with something like:

	public function my_action_deposit( $data ) {
		error_log( 'Received deposit with details: ', print_r( $data, true ) );
		// TODO insert your logic here
	}

	add_action( 'wallets_deposit', 'my_action_deposit' );

In the hook’s callback you can do all sorts of checks if you wish. Then you can initiate an internal transfer to another user, such as an admin, using the PHP API move action:

	$args = array( ... ); // TODO insert details of transaction here
	do_action( 'wallets_api_move', $args );

Hope this helps.

kind regards
Alex

[alexg]

Thank you for reporting. I will look at this and hopefully solve it soon.

[alexg]

Hello,

You should not try to set a minimum withdrawal. This is enforced by CoinPayments. I will try to add a minimum withdrawal restriction to the frontend but this requires some reworking at the coin adapter level. Will report back here when this is done.

Thanks

[alexg]

Hello. This is now resolved in version 1.0.1 of the airdrop extension. Thank you.

[alexg]

Hello,

To answer your second question first, check your CoinPayments account’s IPN history. Your LTCT deposit should generate an IPN message with status 0 when it is first seen on the network and another IPN message with status 100 when the transaction is confirmed. It is this second IPN that causes the deposit to be recorded in the plugin. Please see the troubleshooting section of the CoinPayments adapter page for more details. If you continue to experience problems with this, please contact me with the details of your IPN message with status = 100. Any errors will be there.

I am not sure what you mean by “take an amount of user deposit”. Can you please describe more fully what you want to do? Do you want to keep a part of the deposit as fee charged by your site? Under what circumstances do you want this amount to be kept?

Looking forward to your reply

Thank you

[alexg]

This has now been addressed in version 1.3.2 of the Faucet extension.

[alexg]

Oops yes this is a rather important feature for faucets!

I will try to fix this as soon as possible. Thank you for reporting.

[alexg]

There was a bug in the redirect code that affected only Apache but not Nginx. This is now fixed in version 1.3.1 of the Faucet extension. Thank you.

[alexg]

OK thank you for the additional info.

It doesn’t make sense for you to expect a deposit to go through if the transaction was initiated via the CoinPayments interface. What needs to happen is this:

1. The user visits a page with the [wallets_deposit]. The plugin then requests a new address from the wallet (in this case CoinPayments) and assigns it to the user. The mapping is stored into the addresses table.

2. The user then sends funds to that address. The wallet receives the funds, then informs the plugin. In the case of the CoinPayments adapter, this is done via the IPN message. The plugin then creates a deposit transaction for that user.

3. Next time the user views their balance, the plugin sums all the transactions including the new deposit and this new amount is reflected in the total balance for that coin.

Unless the address was stored in the addresses table and mapped to the user’s WordPress user id, the deposit will not go through.

Here’s what you can do to rectify this:

1. Figure out the user’s WordPress ID. This is an integer number that you can find via Admin -> Users.
2. Insert the mapping manually (you would not have to do this under normal circumstances). Here’s how you could do this:
INSERT INTO wpk4_wallets_adds(account,symbol,address,created_time) VALUES(5,'LTCT','A_DEPOSIT_ADDRESS',NOW());
This would associate user with user_id=5 with the LTCT address A_DEPOSIT_ADDRESS.
3. Go to your CoinPayments IPN history, and click the button to resend the IPN message.

This should resolve your current issue. In the future, never allow your users to use the CoinPayments platform directly. They should not even have access to that, since it is your site’s wallet.

Hope this helps.

[Author]

Posts