n8dnx

Mr. Tung Du:

The suite of some 18 plugins and add-ons we developed for membership association management are not available to you. It was while debugging the appearance of a dialog-box for one of these that I found your plugin was not being selective when setting classes for jQuery UI Dialog boxes. For example from your admin.js file…

$( ‘.ui-dialog-titlebar-close’ ).addClass( ‘ui-button’ );

This may be one of the issues causing the problem with the close button on the dialog box title bar. It doesn’t have a selector to limit it to only your code, so it would affect all dialog boxes in the admin of the site. I didn’t look further so there may be others.

I’ve proceeded with your plugin deactivated on my development system and thought I would let you know about this problem. Fortunately we mostly use the Restricted Site Access plugin on development versions of our customer’s sites, so we can work around it, but I suspect that others may have this problem and not know why.

That’s about all the direction I can give you at this point. You might try adding another dialog box in unrelated code to see the effect.

Chuck Scott
Gaslight Media

Jalal:

I don’t know if your issue is related, but we recently started having some severe problems with the Media Library that had similar symptoms.

In our case this started with a customer who has downloadable products (PDF map files) that are sold in a WooCommerce shop. When we first moved them to this site we imported some 200 PDF files into the wp-content/uploads/woocommerce_uploads directories. After that, the customer had added another 100+ PDFs to the Media Library. This was OK till the end of last year.

At that time the Media Library starting taking a long time to come up and at times would fail to do so. We found that the Media Library was trying to generate thumbnails for a number of PDF files even though there were already thumbnail images there, and that those processes were timing out and showing a “Client Disconnect” error. It would continue to try to processes these PDF files every time we went to the Media Library, either directly or via WooCommerce.

One way we sorted this out was to watch the files currently in the /tmp directory on the system. Using a “watch ls -l /tmp” command we could see these PDFs being processed and could tell which ones they were.

We moved all of the PDF files to the WooCommerce directories and applied the code to stop processing of PDF thumbnails (which seems to only work with new files. That didn’t solve the problem and we found no way to tell WordPress to stop processing those PDF files, including the ones in the woocommerce_uploads directories.

We suspect the problem came up due to some very large PDF files and the update to process them into thumbnails. We also have noticed this problem starting to come up in some other sites, some with 1000 or more PDF files and that don’t have WooCommerce installed.

So, we were about one more PDF away from having some major Web sites become unmanageable and ended up having to add a feature to one of our plugins to provide a “File Library” separate from the Media Library and move all of the PDFs to that. That of course solved the problem, but didn’t fix the core issue. We now have to do the same with a number of other sites to keep them from failing and of course re-train the customers.

I checked in the bug reports but can’t find any that relate to this specifically. I’m interested in any other people having this specific problem before I file a new bug report.

Yes, a technical point that you are not turning off error reporting entirely. ??

The problem is that what you are turning off is interfering with us being able to see syntax and some other errors in our code. We should be able to turn on certain levels of error reporting in PHP and expect that it will be set that way when our code is executed.

To accommodate other developers, you need to make sure that wherever you change the error reporting that you restore it to how it was before any return or exit from your code. It looks to me like there have been attempts in NextGen to do that, but there seems to be places where error reporting is still not properly restored.

Is this something you can add to your bug list and resolve at some point?

Thanks,
Chuck

Just looking for an update on this issue. We’re running the current version (1.2.0) with current WooCommerce (3.1.2).

Just as described, if the checkout fails and the user tries to resubmit with updated payment data, “Error: the Captcha didn’t verify.” is displayed. If you wait long enough, the Captcha box will expire and ask to check it again. Doing that the user can try again to checkout.

In our case we have a Merchant e-Solutions payment gateway plugin for card processing that we wrote, but I don’t think that has anything to do with this.

Is there perhaps a way to force the Captcha to reset when checkout fails.

Chuck

Cais:

Thanks for the response. My question then is what might we be disabling in NGG that we might need if we set NGG_DISABLE_FILTER_THE_CONTENT? Since I’m not the person here working with NGG, I don’t know what effect that might have.

My other “real” question, is why NGG is looking at these img tags anyway. It’s doing this not as a result of my code, but simply because the img tags exist in my prototype for adding additional images (is included with the HTML sent to the browser). I have that prototype in my template because it can be different between image areas and pages.