• keniry

    (@keniry)


    pagespeed insights 87 before and 50 or worse after

    87 before activating this plugin
    50 or below even with all the styles turned off and polyfill disabled and no addons.

    That’s a pretty impressive 37 point drop ! …turning on DIVI only results in a 30 point drop and the best bit there is no donation form or widget on the homepage.

    5 STARS for giving the finger to Google page speed insights
    1 STAR for site performance

    …but seriously why the CSS and JS bloat and why load it on every page and not just where it’s needed.

    Also see Increased server response times, and weird errors in the debug log about

    PHP Fatal error: Uncaught ReflectionException: Class Faker\Generator does not exist

    then there is

    Donation SPAM

    – how is that a thing ?

    ..and Give support tells me to take it up with Stripe.. seriously ?

    Donations Pending but complete in Stripe

    , most I guess were caused by having no web hook installed but give support made no mention either way about checking the web hook either for this or DONOR SPAM…

    I found the reference to web hook in the documentation… was this a step missed when the plugin was setup IMO is should not be optional and/or there should be dashboard warnings… WEBHOOK NOT INSTALLED.

    I would have suggested it but the support is disinterested.

    email access (unless the donor logs in) I see session errors which even displayed the wrong donation to the wrong person, or simply spit out an error and show nothing. The doc suggests limiting the number of donation which display for security reasons …, a clear indication that this is a known problem. ..as for give support – you got it, a lack of curiosity or interest.

    I notice the reviews here are either 5 stars or 1 star… I almost gave 2 stars as I think all donations attempted have worked but the problem is the unnecessary load on the server has almost certainly affected both SEO and user experience which means less donations.

    Apart from the numerous shortcomings of this plugin my real disappointment is the support which is as bad as I have ever encountered and worse than many free plugins.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Contributor Ben Meredith

    (@benmeredithgmailcom)

    Hi @keniry

    I appreciate the time you took to type out this review. I’ll respond with equal attention to detail!

    Since you state that the root issue you have with GiveWP is our support team (and I’m the Head of Support) I’ll start with that, and return to your more specific concerns at the end.

    I’ve taken a detailed look at all of our interactions with you in priority support, and have made the following observations:

    1. We definitely could have done better on some of our replies, in terms of educating you on how the product works, and in terms of moving every conversation toward resolution more quickly.

    2. There was a lot of miscommunication in terms of our team not fully understanding what your problem was, and we could have done better at internally discussing them to get a more comprehensive reply back to you instead of spending time with back-and-forth that wasn’t moving things toward resolution.

    We take support very seriously, and I hate that you had that experience with our team. I firmly believe in growing and learning, and all of us are looking into how we can learn from this situation. Your success with online donations is our number one priority.

    Now, back to your specific issues, which I’ll reply to in order:

    1. PageSpeed insights: you’re right that GiveWP is fairly heavy in terms of scripts and styles loading on pages where they are not needed, and that’s something that Google increasingly frowns on. One of the near-term goals on the product roadmap is to optimize and only call those scripts when needed. We have some custom code snippets for only calling those scripts on certain pages that some developers have had success with. Additionally, there is known feedback on our feedback site that address performance. I’ve looped in our Lead developer to weigh in on a public reply there: https://feedback.givewp.com/feature-requests/p/givewp-should-enqueue-scripts-only-on-needed-pages-instead-of-adding-it-to-the-e

    The only defense I have of that is that some very large and very successful sites have atrocious pagespeed scores, so while it’s important, it’s not everything.

    2. We’re happy to look into the PHP errors in the logs, but this is not the best forum for that.

    3. Donation spam: absolutely every ecommerce platform (especially the open source ones that run on WordPress) deals with purchase spam. Donations are particularly ripe for that because there’s no cart: so a bot can load in 100s or 1000s of card numbers into the form and just slam it over and over. It’s something that we have taken great pains to address in the past, and will continue to. Your particular issue is that some of the fraudulent transactions were going through on Stripe, and some were not.

    The good news is that, in addition to all of the steps we provided you (though I’m not sure if you tried any of them, and eager to help if you’re still having problems) we are also working to add in more protections for site owners to combat spam. Here’s the feedback post for that: https://feedback.givewp.com/bug-reports/p/additional-spam-donation-protection

    As a side note, the webhook would have nothing to do with donor spam. It’s just the one-way communication from Stripe back to your site to alert your site of something that happened there. So if the spam is getting all the way through to Stripe and triggering an event that is sent over the webhook, then the fix is to stop it before a webhook is involved.

    4. That brings us to pending donations: It’s a great idea to make the webhook and the steps to correctly configure it more prominent, but there’s no way for the GiveWP side to “detect” if it’s set up, because Stripe doesn’t allow access over the API to see the configured webhooks. Presumably, that’s a bit too much of a security risk. So we only know that the site is connected to a webhook when we start getting transactions and events sent over the webhook. We made a special popup immediately after connecting to Stripe, and reference it multiple places in our docs, with the hopes that folks will get connected. If they don’t, we’re more than happy to help the get things set up in priority support or here on the forums.

    5. Email access: the reference in the docs to limiting the number of donations is related to how many donations display if you HAVEN’T been authenticated. If I try to donate with an email address that I know is already a donor, I shouldn’t be able to see the previous donations made by that donor until I am authenticated. Just the one that I just made.

    If you are seeing donations being displayed to the wrong person, that’s a telltale sign that caching is causing issues, and delivering a cached page to subsequent users. You should exclude any page on your site that displays donor information from the cache. That’s a thing that your caching provider can help with.

    Finally, very glad that donations are actually working for you. I’m happy to continue the discussion over in priority support, where you still have an account!

    Thread Starter keniry

    (@keniry)

    sounds about right, no further comment other than yes I did try all the suggestions, and I hope the encoded timestamp idea works.

    Did I say I how much I hate Help Scout..? but I do like

    https://feedback.givewp.com/bug-reports

    that’s very useful

    Plugin Contributor Ben Meredith

    (@benmeredithgmailcom)

    I did want to clarify one aspect of my novel reply above for the sake of anyone who reads in the future.

    I mentioned that optimizing for speed is a priority and that we are looking at only loading those scripts where needed. My development team let me know that one key reason we do not default to loading scripts only as-needed is that some caching solutions in the WordPress space essentially check the home page for any scripts, then bundle them into a cached script that they then load for every pageview. If GiveWP only loaded scripts on pages with forms, and there was not a form on the home page, that would cause problems.

    The solution we are looking into is to make conditionally loading scripts a more visible option in the advanced area of the settings, with some healthy “Danger Zone” type of warnings.

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this review.