George Nagy

Hi Shahriar – Yes, WPDM does enqueue jQuery in the header of the page which results in this:

It’s fine if you’re not worried about page rendering performance. But we work to eliminate render blocking resources to improve user experience. Therefore, we defer loading of jQuery and other scripts to the footer, per Google’s recommendation:

https://developers.google.com/web/tools/lighthouse/audits/blocking-resources

So your nivoLightbox code will work fine if jQuery is loaded in the header, but it will not work on any site that is optimized for performance where scripts are loaded in the footer. Also, why is that nivoLightbox script even being added to pages that don’t utilize nivoLightbox?

The jQuery related error with how nivoLightbox is being loaded still exists in the latest version (5.0.3) of WP Download Manager Pro. Is this on the roadmap to be resolved? The fix is adjusting your wpFooter function, and adding the nivoLightbox initialization as follows:

wp_add_inline_script( 'jquery', 'jQuery(function($){ try{ $(\'a.wpdm-lightbox\').nivoLightbox(); } catch(e) {} });' );

This does exactly the same thing as your wpFooter function (minus the Ajax call), but does it in a way that makes sure that jQuery is loaded before using it.

Looks like the issue is resolved in v5.0.3. Thanks!

The “jQuery is not defined” error occurs if jQuery is loaded in the footer. To replicate the issue, add this to functions.php (and verify that jQuery is loading in the footer versus in the header):


function load_scripts() {
wp_dequeue_script('jquery');
wp_enqueue_script('jquery', false, array(), false, true);
}
add_action( 'wp_enqueue_scripts', 'load_scripts', 10 );


The ‘true’ parameter in the wp_enqueue_script tells jQuery to load in the footer. Loading scripts in the footer is a best practice to maximize page load performance.

The main issue is that loading of nivoLightbox and any other jQuery functions should be made dependent on jQuery being loaded first, using wp_add_inline_script as shown above. Alternatively, the jQuery functions found in the wpFooter function in download.manager.php could be added to an external .js file and loaded with wp_enqueue_scripts, adding the ‘jquery’ to the dependencies parameter. As there is some PHP mixed into the wpFooter function, wp_add_inline_script would probably be the easier way to go.

Thanks for the reply. Using FTP to manually remove files seems to defeat the purpose of having a management tool for downloads. Using a separate File Manager plugin is not very intuitive for non-technical users being tasked with managing downloads and could lead to the same issue of files being removed that are referenced by other packages.

In our case, the issue is that we have PDFs attached to packages. When the PDF is removed from the package, or the package is deleted, the PDF remains on the server. As a result, it also remains in the index of our on-site search engine. Based on your reply, it seems that without doing a bunch of manual work, once a file is attached to a package, there is no way to remove it from the server.

The correct solution would seem to be:

• Upon clicking the ‘X’ to remove the attachment, do a query to see if the filename being removed is associated to any other Packages
• If the attachment is not associated with any other packages, prompt the user to determine if they want the actual file removed from the server
• If the attachment is associated with other packages, prompt the user to determine if they want the actual file removed from the server and from all of the other packages that reference it

Where this gets tricky is with the deletion of single or multiple Packages. In that case, a similar prompt could come up asking the user if they also want to delete all attachments associated with the packages being removed.

This would eliminate the need to utilize an outside tool for manually managing files.

FYI – this issue has NOT been fixed in v4.6.8. The wp_reset_query(); needs to be added back to class.Package.php after line 1193 for the plugin to function.

Perfect – thank you for the fix. Much appreciated.

No need to reply to this issue. Adding the function above was enough to add support for revisions. Just needed to make a actual revision for the option to show up.