Support » Plugin: Easy Digital Downloads » Works well, but…

  • Other than the few minor issues noted below, this plugin is incredibly well put together, and I highly recommend that others use it when a larger e-commerce solution is unwarranted.

    The problem I have with this plugin is that by default it injects a bunch of JavaScript into the head element of *every* page on your WordPress site, regardless of if it’s in use on that page or not. The more plugins that allow themselves to just spit out inline code all over the page (especially on pages where it’s not needed at all) the messier (and slower) our sites will become.

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author mordauk

    (@mordauk)

    Can you show me examples?

    We inject very, very little javascript into pages, so I suspect it’s not actually coming from EDD.

    Plugin Author mordauk

    (@mordauk)

    EDD loads two javascript files only. Are you considering two files to be a lot?

    Plugin Author mordauk

    (@mordauk)

    The only inline JS that we inject is a set of localized variables using wp_localize_script(), which has zero impact on performance.

    First, there’s no such thing as code that has “zero” impact on performance.

    By default your plugin loads the following on all pages of my site (again, regardless of whether or not the plugin is being used on a given page:

    edd-ajax.min.js
    jquery-migrate.min.js (as a dependency)
    jquery.js (as a dependency)
    edd.min.css
    inline javascript variable (for Ajax functionality)

    Second, it’s not a question of whether or not your plugin includes “a lot” of code. It’s simply a question of whether or not the code being included is necessary on every page. If I have 20 plugins installed that all include 2 javascript files and inject an additional bit of inline code, I’m now loading 40 JavaScript files with 20 separate chunks of inline code.

    Best coding practices should dictate that you’re never loading code that isn’t being used on a given page, and that’s the only argument I’ve made here.

    Plugin Author mordauk

    (@mordauk)

    edd-ajax.min.js has to be loaded because of cart widgets and / or purchase buttons being present throughout the site, though you can disable it completely if you wish by disabling Ajax in Downloads > Settings > Misc.

    jQuery-migrate.min.js is a dependency of WordPress’s jQuery, not EDD’s, so we have no control over that.

    jQuery is needed by edd-ajax.min.js, as well as by nearly every single plugin out there that does anything with jQuery. It’s almost almost definitely used by your theme.

    edd.min.css is needed for our CSS, though again you can disable it completely if you wish to use your own CSS by going to Downloads > Settings > Styles.

    The inline javascript is just a set of variables that are needed for error messages, localized text strings (so they can be translated), etc.

    If you have proposals for how to improve these assets, believe me, I’d love to hear them, but they are most definitely needed. We have worked very hard to ensure the impact is extremely minimal.

    I absolutely agree with you that CSS / JS should only be loaded when needed, but note that sometimes it is actually causes a larger impact on performance to detect whether a script is needed that it does to simply load the script.

    For example, if we were only load the edd-ajax-min.js when a purchase button was put on the page, we would have to detect if the current post or page has a specific short code on it. This is fine and easy to do, but we would also have to determine if any widget areas were loaded that contain the cart widget or purchase short codes. Detecting these in widgets is much more destructive to performance and reliability that it is to load a very, very small file. We would also have to take into account any time someone manually displays a purchase button in a template file, such as many custom store themes do.

    Note that we do conditionally load as many assets as possible, but there are some (ajax / css) that cannot be conditionally loaded for the reasons mentioned above. If you disagree, I would love to see the proposal for how to do it.

    It does make me a little sad that you would choose to leave a poor rating without at least bringing this up as a support ticket first. We work everyday to improve the plugin and one of the ways we do that is by listening to suggestions for improvement from users.

    Totally agree with the bulk of your response. I’ve updated my review above. Thanks for reaching out.

    Plugin Author mordauk

    (@mordauk)

    Thanks for listening to us as well!

    Note, we weren’t attempting to get you to change your review, we just wanted to make it clear that these kind of issues have been taken into serious consideration 🙂

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Works well, but…’ is closed to new replies.