Ben Meredith
Forum Replies Created
-
Hey @jakobuz
Thanks so much for sticking with this and giving me steps to replicate this problem. I’ve just been able to do that, and have escalated it to our team to have a look, for sure.
You’re exactly right that this is not the way it should work. I’ll mark this post so that in the event we fix this issue, we can reach back out here to let you know things are resolved. I’m marking this as “resolved” here, but that means “escalated to the team” for sure.
Thanks again for the help here making our product better.
Hey @j0321!
What changes did you make to those settings just before this issue started happening?
It is possible to “lock yourself out” of certain pages in the land of Solid Security (Basic or Pro) so I would bet that’s what’s happened here. One of the features of our product is fine-grained control over what folks have access to within the admin side.We’re not technically allowed to offer support for the Pro version here, but I’ll give you some ideas and if they don’t work you can reach out via our priority support channel from within your account at my.solidwp.com
(Note to forum moderators: this is a request regarding the Pro plugin, but it’s a feature and thing that can happen to Basic users in the same way, hence me addressing it here)
The fix, in the event you have locked yourself out, is to temporarily disable all of the Solid Security features using a line of code added to your wp-config.php file:You can add the code below into the
wp-config.phpfile anywhere between the first line (<?php) and the line that says/ That's all, stop editing. Happy Blogging /to temporarily disable all features.define('ITSEC_DISABLE_MODULES', true);Once you’ve done that, go and change back whatever settings you changed previously, and you should be all set.
If you continue to have problems, reach out via priority support, and we’re happy to help!
Hi @verkkovaraani and @brad1st!
We’re definitely keen to fix anything we can from our side.
@brad1st it sounds like your issue is deeper than just this issue, and I don’t want to annoy the thread-starter here (it’ll email them every time we reply) so please start a new thread with your issue. In that thread, I’d love the answer to these questions:
- Is that the only setting that doesn’t save correctly?
- Can you open the developer’s console and see if there are any errors there?
- I would turn on WP_DEBUG and WP_DEBUG_LOG (and turn off WP_DEBUG DISPLAY) and then try to save, and check that error log for clues. See the lines to add to your wp-config.php file at the end of this message.
Back to the original issue: In order to get any traction here, we’ll need to be able to replicate a problem.
First though, let me assure you that turning off Write To Files setting doesn’t make your site less secure, it just makes the process of changing that file more manual. Disabling (by unchecking) the Write To File functionality doesn’t change what’s already written to the file.
We’ve had three reports of this happening over the past few months (and a handful even before the rebrand to SolidWP, so I am not convinced this is a new issue yet) 3 reports for a plugin of 900,000+ installs is so insignifcant in terms of percentage that it’s got me thinking it’s going to be extremely difficult to isolate.
My hunch at this point is something (either something caused by Solid Security, or some other process on the site, some other site on the shared server, or something!) is causing the plugin to stop right in the middle of writing to that file, which is causing it to be malformed, which is in turn causing it to erase itself, or something.
Like I said initially: the first step is reproducing it. Today I spent time on 4 different test sites with various servers (NGINX, Apache, PHP versions 7.2 all the way to 8.2) and I can’t get it to fail in the ways that are being described in the thread.
Until I can see it happening, I’m stuck.
Here’s those DEBUG lines to add to wp-config.php:
// Turn debugging on define('WP_DEBUG', true); // Tell WordPress to log everything to /wp-content/debug.log define('WP_DEBUG_LOG', true); // Turn off the display of error messages on your site define('WP_DEBUG_DISPLAY', false); // Hide general PHP errors @ini_set('display_errors', 0);Forum: Plugins
In reply to: [GiveWP - Donation Plugin and Fundraising Platform] Negative donorsHey @chosendaone!
That’s an interesting model for sure, but not something that GiveWP supports. You’re essentially running donation-funded insurance (for lack of a better word), and need fairly fine-tuned reporting and accounting to be able to know current balances of each individual fundraiser.
That’s not something that GiveWP currently has any way to keep track of, on a conceptual level. You’re right to point to essentially “negative donations” as a way to do that, but that would be introducing a different concept.
I made a feature request on your behalf over on our feedback site: https://feedback.givewp.com/feature-requests/p/balances-or-donation-driven-wallets
Feel free to add any context or nuance that I missed.
Also, if I were tasked with this functionality *today* I’d probably try connecting up to a third party database solution like AirTable using the webhooks premium add-on. That’s essentially separating out the “withdrawal” and “individual funds” functionality out to a separate service. It’s likely not easy or simple to add that type of tracking into GiveWP itself.
Hey @ayntk
I don’t have an account to reference, no.
The support at Cloudflare ought to be able to help with this. I wish I could point you to the solution, but if their docs are not matching up with your account, that’s something they will need to assist with. This is unambiguously something wrong on your Cloudflare account, and therefore something that we can’t assist with.
Thanks!
@ibiza69 yeah that’s odd for sure. That’s Block editor markup that should not be showing in the review.
Go ahead and submit the review and then we can ask the meta team at ww.wp.xz.cn to have a look.
Thanks for the kind words!
Hey @davepj!
First, apologies for the slow turnaround here!
There’s functionality to require donors to be logged in, and therefore you can hide the donation form for logged out users. Here’s a quick video showing what that might look like:
Have a great day!
Hey @photomaldives!
First, apologies for the slow turnaround here! We took far too long to get back to you!
Next, regarding that specific error message: That usually shows up when a donation form doesn’t render on a page correctly. It’s most often caused by a conflict with some third party code that’s breaking JS in some way.
It can also happen due to server capacity issues.
If you’re not seeing problems otherwise, and not seeing that error in the logs repeatedly, I wouldn’t worry about it: chalk it up to some gremlins in the server. If it’s happening often, predictably, or in a blocking way, we’re happy to dig in and see what’s going on.
The first step to do that will be getting the problem replicable (both on your site as well as in a separate environment).
Because the forum notifications are so unreliable and this post is old at this point, I’m going to go ahead and close this. If you still need us, definitely open a new post here, and we will take a look.
Hey @wtnhistwebmaster!
First, apologies for the abysmal turnaround on this reply. That’s unacceptably long.
You can configure emails to be sent to you when a donation comes in. There’s not a setting for a notification within the dashboard, but by configuring the email to go to you, you can be notified that way.
You can read all about how to set up those email notifications here: https://givewp.com/documentation/core/settings/emails/
I’m going to mark this as resolved, but if you need anything else at all, don’t hestitate to reach back out!
Hey @djixas!
( I just typed up a long reply that apparently the forum goblins have eaten… but apologies if you are getting this twice)
I spoke with our lead developer and our strong hunch is that your problems are stemming from an incompatible Database Storage engine. We’d recommend converting over to InnoDB if you are not already.Here’s an article on how to convert over to InnoDB. It’s a bit technical, but not too cumbersome.
Let us know if you are already on InnoDB, and we can keep digging, here!
Very glad to hear it! Have a great day (and New Year!)
We’re working hard to earn 5-star reviews. If you think we deserve one, it would mean a whole lot for you to share!Hey @ayntk! I spoke with our lead developer and he says the fix here is to “allowlist” your server’s IP address in Cloudflare. Here’s the docs I found for that on CloudFlare’s side:
https://developers.cloudflare.com/ddos-protection/tcp-protection/how-to/add-prefix-allowlist/
Once you do that, you should be good to go.
Our team is working here to resolve any lingering deprecation notices, and you should see those in releases soon. I’m going to mark this post as “resolved” for now. Definitely follow up in a new post if you’re still seeing deprecation notices after the next release!
We heard back from the development team on this, and nothing is transmitted to Patchstack’s servers from your site. Requests are sent only to Liquid Web (the parent company of SolidWP)’s servers. The information that is transmitted is the Site URL, Plugins, Themes, and WordPress version. No user information is transmitted at all.
Hey @marcusdeman
Following up here. Since we haven’t heard back, we’re assuming this issue is resolved. If it’s not, no worries, just open a new forum post! Have a great day!
- This reply was modified 2 years, 5 months ago by Ben Meredith. Reason: accuracy. it's not a ticket