Andrius Vlasovas

@dpdbaltics while yes, you DECLARED compatibility, but checking your code for most common function calls it seems that you did NOT in fact make your plugin actually compatible with HPOS and when you say that you did, people that would blindly trust it, would actually lose data.

I would urge you to remove the compatibility with HPOS and declare it once the plugin as is actually compatible with it.

I may have been wrong, seems that WPCF7 does not enqueue styles/scripts reliably or where the form is (especially if it’s loaded via ajax). This plugin may not be at faul,- had issues with it disabled too.

If you are using Conditional Fields for Contact Form 7 version (2.4.5) it’s what was the culprit ofthis JS error. Roll it back to 2.4.4 or remove and it should be fine.

Bumping this up, should be highest priority.

Actually, it seems that it was heavily reliant on a wrapper div with class wpcf7-form-control-wrap existing. I was removing that div for other purposes, but it was causing some other issues, so I got rid of that filter, ReCaptcha seems to work fine now!

Thanks for the quick response.

Having same issue, thanks for the temporary solution

This actually is happening to me too. After initiate wpcf and conditional fields (pro version) after ajax, there’s an error when submitting the form. Still not sulved on 2.0.3

@egmdev your solution is ok if you wanted to actually perform a search on orders that are in the trash, but in the majority of cases you wouldn’t,- after all these orders are in the trash.

Main issue is that search actions are being performed while you are sorting orders by status ‘trash’, even if you did not perform the search by product, so your solution is more of “going around it” instead of optimizing the whole function to run only when it needs to run and on orders that matter.

Same case here.

There’s some questionable practices code wise in certain function where order IDs are retrieved even if specific URL parameters (used for filtering) are not present this performing unneeded DB query(-ies), on top of that it modifies query arg posts__in/posts__not_in which screws up displaying orders that are trashed. So here’s my solution which should fix both things and plugin still works properly:

Located in:
wc-search-orders-by-product\includes\admin\class-wc-search-orders-by-product-admin.php

OLD function:

	public function sobp_filter_orders( $query_vars ) {
		global $typenow;
		if ( in_array( $typenow, wc_get_order_types( 'order-meta-boxes' ), true ) ) {

			$order_ids = self::get_order_ids();

			// filter order IDs based on additional filtering criteria (products, product categories and product type).
			if ( ! empty( $_GET['search_product_type'] ) ) {
				$order_ids = self::order_ids_by_product_type( $_GET['search_product_type'] );
			}

			if ( ! empty( $order_ids ) && ! empty( $_GET['product_id'] ) ) {

				$order_ids = self::filter_orders_containing_products( $order_ids, $_GET['product_id'] );
			}

			if ( ! empty( $order_ids ) && ! empty( $_GET['search_product_cat'] ) ) {

				$order_ids = self::filter_orders_containing_product_categories( $order_ids, $_GET['search_product_cat'] );
			}

			if ( empty( $order_ids ) ) {
				$query_vars['post__in'] = array( 0 );
			} else {
				$final_order_ids = array_unique( $order_ids );
				$query_vars['post__in'] = $final_order_ids;
			}
		}

		return $query_vars;
	}

How it should look like:

	public function sobp_filter_orders( $query_vars ) {

		if ( $this->is_active_on_post_type() ) {

            if ( ! empty( $_GET['search_product_type'] ) || ! empty( $_GET['product_id'] ) || ! empty( $_GET['search_product_cat'] ) ) {

                $order_ids = self::get_order_ids();

                // filter order IDs based on additional filtering criteria (products, product categories and product type).
                if ( ! empty( $_GET['search_product_type'] ) ) {
                    $order_ids = self::order_ids_by_product_type( $_GET['search_product_type'] );
                }

                if ( ! empty( $order_ids ) && ! empty( $_GET['product_id'] ) ) {
                    $order_ids = self::filter_orders_containing_products( $order_ids, $_GET['product_id'] );
                }

                if ( ! empty( $order_ids ) && ! empty( $_GET['search_product_cat'] ) ) {
                    $order_ids = self::filter_orders_containing_product_categories( $order_ids, $_GET['search_product_cat'] );
                }

                if ( empty( $order_ids ) ) {
                    $query_vars['post__in'] = array( 0 );
                } else {
                    $final_order_ids = array_unique( $order_ids );
                    $query_vars['post__in'] = $final_order_ids;
                }
                
            }
		}

		return $query_vars;
	}

Seems to be working great John. Cheers.

Hello,

Seems to be working, thanks!

Hello Sascha,

I doubt this is the right place to ask for this kind of support, but I’ll give my opinion on this.

If you are using WooCommerce, and you have plenty of products with somewhat a lot of attributes/variations, then 250-400 queries are somewhat alright, but 400 is on the higher side.

You can show less information on product archives, if by “per page” you have in mind product archive pages or a single product page.

Another way to reduce queries is to show fewer products per page.

If you know the code, and you use custom fields for certain parts of your website that repeat on every page (say social links on the footer or header), you could use transients.

Using some sort of caching helps a lot for dynamic stores, so even if you would have a higher number of queries when logged in as admin, visitors on the frontend would be using static pages, which would be fast, and would take the load of the server.

A few suggestions, but it always comes down to what theme you use and how well it’s coded, as well as amount of plugins (number might not matter, but if there are a few plugins that do things on each page, that they shouldn’t do, it adds up, and the more plugins you have, the bigger the chance is of that being a case here).

Sounds great,

thanks for sorting this out.

I can confirm.

After first change of quantity, it does not matter how many times you will change the quantity (with buttons or manual input), after browser refresh it’s back to value that input got after first refresh.

But after refreshing and inspecting qty input field element, it seems that it shows old value in dom, but visually it doesn’t change.
(for example, I increment qty from 10 to 11, then to 14 -> refresh browser tab, qty input value is 14, but shows 11).

Might be something to do with cart fragments saving, but that’s just my guess.

Sure:

* Ability to hide image title/filename in Lightbox without needing to use CSS to hide it.
*Some way to change up layout a tad – mainly having navigation arrows/chevrons on sides and bigger rather than up top (you could introduce some basic themeing in the future, I guess this would be something ‘different’ that not many if any Lightboxes offer).

These 2 things that come on top of my mind right now. Rest seemed to satisfy my particular needs.

Thanks again!

• This reply was modified 7 years, 5 months ago by Andrius Vlasovas.