garrettm30

Sorry for the delay in getting this tested. I have done a simple test to confirm that the issue is resolved as I was seeing it.

1. Before the updated, I loaded an admin page where the problem could be seen to confirm I identified the problem.
2. I updated the plugin.
3. I refreshed the admin page where the problem was.
4. Problem gone.

Thanks.

After using WooCommerce for years, I was willing to give WooPayments first shot now that we are moving to a different processor, but I’m sorry to say that the inability to test locally is an automatic disqualifier. I will look elsewhere.

I was already hesitant based on the rather low rating and my error log being filled up with PHP Deprecated: Hook woocommerce_rest_api_option_permissions is deprecated since version 6.3.0 with no alternative available. You might want to get that worked out too.

Thank you for your response. I will be glad to provide more information if I can help. Here is a screenshot of the results for querying the postmeta table for an older product (I have changed the table prefix):

SELECT * FROM wp_postmeta WHERE post_id = 341;

postmeta for old WooCommerce product

I confirmed that the post type for post 341 is product. I have 1202 products that have _visibility and _featured meta keys, but all of them are old: the last product with these meta keys was created on April 28, 2016.

I think when the conversion was made at WooCommerce 3.0.0 to move this meta info to the terms tables, the original records were not removed. That is my understanding from the function wc_update_300_product_visibility() (from includes/wc-update-functions.php starting at 1308). If I’m not mistaken, that is the only place where the current WooCommerce code refers to these meta keys.

Is there any other information I can provide?

That’s a relief to finally get to the bottom of the issue. Thank you for working through it with me.

I’m afraid I am at a loss at why you aren’t seeing the problem. I think I and those before me have failed to adequately explain where to see the issue. But I believe I have found the problem. I hope I can explain this adequately.

Summary: Your tinymce.js plugin gets loaded more broadly than your scripts get enqueued, and so on third-party pages where tinymce is used, only part of your code is loaded, and that is why there is the missing variable.

Details:

In your file inc/functions-shortcode.php, the function simple_download_counter_add_mce() includes the following at line 423:

add_filter('mce_external_plugins', 'simple_download_counter_add_mce_plugin', 10);

It is there that your file js/tinymce.js gets registered for use by tinymce. Note that this filter gets added in an action called at init and is not behind any conditions, so it gets added everywhere, frontend and backend.

Now in your file inc/resources-enqueue.php, your scripts get enqueued inside of this condition at line?10:

if ($hook === 'edit.php' || $hook === 'post.php' || $hook === 'post-new.php' || $hook === 'sdc_download_page_download-counter-settings')

On the Formidable page I tried to send you to, tinymce gets loaded, and your plugin to tinymce gets loaded, but because the hook on that particular page is toplevel_page_formidable, your other scripts do not get loaded, especially js/settings.js where the needed variable download_counter is found.

I believe therefore this problem should happen anywhere tinymce is used on pages other than edit, post, post-new, and sdc_download_page_download-counter-settings.

I sure hope that’s the problem and I haven’t wasted your time after all. Thanks at least for looking into it.

What about the locale for your test WP install? Mine is “en_US”. The JS error is “Can’t find variable: download_counter.” That variable appears only three times in your code that I can find. The only time it is server side is in a wp_localize_script() call, so maybe a different locale could be hiding the issue?

I think we can rule out theme in this case, because I never changed theme on this fresh install. I just double checked, and the active theme is Twenty Twenty Four.

That’s a real puzzler. Since the error occurs client-side (like onload or something, since the message pops up a little after the page loads), do you suppose it could be depending on something browser-related? I have tried it on Safari, Firefox, and Brave, all on macOS 14, and site that I set up following the steps above have manifested the error.

Sorry for the delay. I wanted to run through it again to make sure I am giving all of the steps.

I am starting from an entirely fresh install with no other action but to log in as admin and go to the add plugin page. The environment is Apache with PHP 8.2.0, WordPress 6.4.3.

1. Install and activate Simple Download Counter.
2. Install and activate Formidable Forms (by Strategy11 Form Builder Team)
3. Refresh (so as to update the sidebar menu).
4. Go to the submenu item “Forms (Lite)” from the Formidable menu.
5. Click on the “Contact Us” form. This goes to the edit form screen.

At this point the error should manifest. About an inch or so from the left, there is a tall, very narrow error div with a light pink background. As it shows in this plugin, the space does not allow the message to appear except as one character per line. More importantly, there is an error in the JavaScript console that begins: “Failed to initialize plugin: sdc_download.”

Note that I have no experience with Formidable Forms. I only chose this because it seems to be the easiest option for getting you something that is reproducible, much easier than trying to reproduce my situation. On my site, I get the same error in JS console with basically the same error div, except that for me the error div is given proper space and it appears 4 times, for there are four instances of tinymce on that page.

I think I have something reproducible. I have created an entirely fresh site on local, installed your plugin and then installed Formidable Forms as another user mentioned elsewhere. Unlike that user, I have tested with the free version. Then with both plugins activated, I get the error when I go to edit a form, in this case, the included “Contact us” form.

I saw you mention in still another thread that you thought it was Nginx, but note that I am running Apache on local (I use MAMP Pro) and still get the error.

So what can I do to get this to you? For example, I could record a screen cast, or I can package up the site files and database and send that to you.

I would like to join the discussion, as I am experiencing this issue, and I have seen a few others are as well. In my case, it is on the product translation screen that depends on both WooCommerce and WPML, the latter of which is paid. Another person posted it in a thread I was a part of, who was experiencing the issue with the plugin “Folders” by Premio. I have done some web searches and discovered a few other plugins not at all related to Simple Download Counter that are also getting similar reports. So far, the common denominator in all of these cases is that a third-party plugin uses tinymce in admin, and the file tinymce.min.js throws a client-side error regarding an undefined variable (“download_counter” in this case) for another plugin.

In my case, the annoying part is that I am experiencing it on my production site but not the dev copy of the same site, so of course I can’t effectively hunt it down, and I appreciate that you can’t either without being able to reproduce it. Now I am trying to figure out what the difference is so maybe I can make a discovery that might lead to the solution

In the meantime, I can appreciate that you can’t fix anything without repeatable steps. I will keep my eyes open, and if I see anything, I will come back here and let you know what I find. Meanwhile, at least in my case, it is just a minor annoyance only seen by me on backend that does not actually cause any issue.

Hi. As I mentioned in the other thread, I am only now just returning to this. I have tested version 1.8 with the large download that failed earlier, and I have found that the issue I reported is resolved. Thank you.

The other issue that @germarrudolf mentioned regarding the message “Failed to initialize plugin: sdc_download” is not resolved 1.8. That is an unrelated issue, and since I have seen it reported a few other times, I will comment further in one of the other threads specifically about that issue.

I’m sorry for the delay, as I am only now coming back to this. I had customized my copy of your plugin in advance of your update while I turned my attention to other things, and I have only now tested and updated my live site with your 1.8. Now I simply wish to return to express my gratitude.

@germarrudolf Thanks for joining in on this discussion.

268435456 bytes means 256 MB, but I get the error already with a file of 156 MB as mentioned. So it allocates more than the file size itself. (at least 100 MB, it seems).

The 256?MB refers to the total memory allocated to WordPress. The memory is exhausted when a large file is read into memory in addition to all the other memory already in use by WordPress and all of its plugins. In other words, a lot of that memory was already allocated by your WordPress install before the file began to be read into memory. The 156?MB file was enough to put it over the limit.

Moreover, I have the free version of the plugin “Folders” by Premio installed (https://premio.io/downloads/folders/). It gives me an error message “failed to initialize plugin: sdc_download.” So there seems to be some conflict, although I have not noticed any issues so far. I will report that to them as well.

I can confirm that I encounter that error as well. I hadn’t yet decided to report it because in my case it happens on the product translation screen, and that depends on the two rather complex plugins WooCommerce and WPML (the latter of which is not free), and I judged it would be somewhat cumbersome to troubleshoot for a problem that so far (in my case) is just an oddity on the backend with no actual issue.

However, I do not believe that it is related to the issue of memory exhaustion for large files. I say that because earlier in this thread we tracked down the root of the memory issue and found a solution, which I have implemented on my end as an interim solution while waiting on the update for an official solution. Since I can now download large files with no memory impact but I still see the error of “failed to initialize plugin,” I conclude it is unrelated.

@specialk Since this unrelated problem is happening to others, maybe it is worth looking into. If I can help you to look into this or to provide you some more info, I will be glad to do so.

I am really encouraged about using your plugin based on the way you have been responding, and it makes me want to do what I can to help (including a 5 star review once I get it in use on a live site).

To contributed a little more information: I have now tested the suggested quick fix on remote downloads, and it worked there as well. Then I decided to test my theory about memory optimization even for smaller files by measuring memory on either side of the readfile() call, like this:

$before_readfile = memory_get_usage();
readfile($file_path);
error_log(
  ( memory_get_usage() - $before_readfile ) . ' bytes additional memory'
);

I tested on a few files, and found that the memory usage is very close to the file size. For example, with that code applied to remote downloads, I downloaded a 4.5 MB file and got the result “4505624 bytes additional memory.” Then I tested adding the previously suggested line to empty output buffering just before the code above and got ‘0 bytes additional memory.’ I conclude that readfile() does read the whole file into memory in the current code, but this can be entirely solved by emptying output buffering just before reading the file. I don’t know if this is the best solution, but maybe there is no harm since you call exit; immediately afterward both times you read the file.

So this could help on files that are not themselves too large but on environments where WordPress is already low on memory. Then certain files might put it over the threshold while others seem to work.