April 26, 2018 at 12:49 am #2942
‘restrict the number of claims per IP’ applies not only to IP, but also between coins.
My site has multiple faucets running.
For example, if a user claims a bitcoin and then claims litecoin, it is restricted with an ip limit message.
The user tried only one ID.
And can you add the following sentence to the translation?
“You can not claim again from this IP adress until the …”April 26, 2018 at 7:25 am #2944
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!April 26, 2018 at 2:04 pm #2946
In version 1.3.3 users can now claim multiple coins for the same IP. There is a different countdown timer associated with each coin.
The string you mentioned was already translatable in version 1.3.2. Can you check again? The string definitely exists in the pot file and is translatable in the code.
In version 1.3.3 the string has been changed to “You cannot claim %s again from this IP address until the %d minute waiting period has elapsed.” This is also found in the
AlexApril 26, 2018 at 11:57 pm #2948
Thank you alex, Dashed-slug~July 25, 2018 at 2:09 am #3878
The wallet plugin is multisite enabled and the faucet is single active.
**My problem 1**
If I save the faucet settings in this state,
404 Not Found error seems to be coming up.
(Multi-activation works well.)
**My problem 2**
And the user’s IP time limit is not over.
I tried clearing the cache and disabled plugins – active, server reboot, multisite activation of the faucet..
but could not solve it.
Users can not request faucets for all kinds of coins.
Is there any way I can try?
– Moved domain management to cloud flare.
(I’ve tried clearing the cache and changing the settings in the cloud flare / now I’ve turned off all caches and turned off add-ons)
– I have migrated the server under the same conditions.
(Wallet function is working normally)July 25, 2018 at 8:46 am #3882
To be clear, can you please confirm this?
1. The parent plugin, Bitcoin and Altcoin Wallets, is network-activated on your multisite install?
2. You have installed and activated the Faucet extension on a single site? This should normally not be possible.
Perhaps you have also single-activated the parent plugin. You should not be able to see the Faucets menu item. Your wallets menu item should be under network settings.
Try deactivating the parent plugin from the network menu, and then see if the plugin is also activated on your single site admin screens. This is not a valid configuration.
The time limits are based on WordPress transients. In some server configurations it seems like WordPress transients do not expire, and I am currently trying to determine why. This does not appear to be a problem with the plugin, but might be a misconfiguration of the server’s object cache. Unfortunately I do not currently know more about this. But your problem could also be caused by having the faucet extension activated on a single site while the parent plugin is network-active. We must first resolve problem 1 before addressing problem
In general, you can install the parent plugin network-wide and then do the same with the faucet extension. You can install the faucet extension at the network level and then only use the faucet shortcodes on the sites where you need it.
kind regardsJuly 25, 2018 at 9:25 am #3883
Yes, the parent plugin is active and working on a multi-network.
I have used the faucet extension only on a single site(main) so far and it looked normal.
It is still active on a single site. But now I had a problem saving the settings.
In the meantime, I’ve used it without changing the settings.
I am now trying to switch to multi-active for functional normalization
If multi-activating faucet or exchange extensions does not degrade performance? I wanted to reduce the burden on single (sub) sites that did not use shortcode.
I will try other methods for ip issues.July 26, 2018 at 12:57 am #3903
I will only use faucet extension based on multi activation in the future.
So this is no longer a problem.
The faucet ‘ip problem’ seems to be resolved.
First, I am sorry that I did not try enough and asked a question.
Perhaps the problem seems to be the problem between WordPress&Server and CloudFlare configuration.
(I had w3tc disabled to use the cache in the cloudflare.)
*My case solution*
I reinstalled w3tc and reconfigured all settings(w3tc, wordpress) the same as before.
I also applied the cloudflare extension of w3tc.
The faucet was normalized with the same environment as the existing one.July 26, 2018 at 7:56 am #3907
Thank you for sharing your findings. You are welcome to ask questions, this is what this forum is for.
1. There should not be too much of an overhead coming from the faucet for sites that do not use it.
2. To be clear, was the problem resolved when you installed the cloudflare extension to w3tc? If so I can instruct others who had the same problem.
Again, thank you very much.July 27, 2018 at 9:22 am #3921
The problem followed, but it was finally resolved.
Cloudflare send their IP to my site rather than the visitor’s real IP.
There are several IPs. You can find it in the link below.
I was able to verify IP with live traffic in wordfence.
I had to get the visitor’s real IP.
Fortunately, cloudflare send visitors’ real IPs along with their IPs.
There are two ways to solve this problem.
>1. Add simple code to WordPress
>2. Install plugin to return real IP
I tried some plugins but did not return real IP.
Eventually I received the visitor’s real IP as this plugin.
And now the faucet has been normalized.July 30, 2018 at 7:09 am #3945
Wow, thank you again, and congrats for solving this!
Using a code snippet from the plugin you found, I can modify the faucet to detect the correct IP if it is behind a reverse proxy.
Will release a patch soon.
- You must be logged in to reply to this topic.