huusoku

You’ve got mail! Thank you very much

Huusoku

I agree. This new site visibility badge is stupid and just adds more useless clutter to my admin bar. I used this solution to remove just the badge: https://gist.github.com/RiaanKnoetze/5193516e172554b8871236351e666cf1?permalink_comment_id=5192314#gistcomment-5192314

Plugin was updated two months ago ??

Thank you for the reply. Yes, we see those options, however, we are looking to not have the product thumbnail image itself link to the Quick View.

For example, on one of your demo pages, https://demo.wpclever.net/woosq/, the Quick View feature is only activated if the user clicks on the Quick View eyeball image. Clicking on the product thumbnail image DOES NOT load Quick View, it loads the actual product page. This is the functionality we are looking to have.

We are new to WPClever and to your plugins (and we are quite impressed thus far!), and when we installed the free version of the Smart Quick View plugin, we have two options: (1) Have a button or (2) Have a link. Upon clicking on either the button of the link will load the Quick View. This is great, very nice and intuitive for the user.

BUT, our product image itself will ALSO load the Quick View as dictated by the loop_product_link() function I mentioned above. This function adds “#woosq-<prod_id>” to the URL of each Product Image. This causes the Quick View to load instead of the product page being loaded.

On all major online retailers that I have shopped at, including Amazon, Walmart, and Target, product thumbnail images link to the Product page. They do not have product thumbnail images linking to any sort of pop-up.

So for our site, we are using the Link function with the eyeball icon placed below each product thumbnail image on our category pages.
— If a visitor wants to see a quick view, they will click “Quick view <eyeball>”.
— If a visitor wants to view the actual product, they will click on either (1) the product thumbnail image itself or (2) the product title.

We believe that based on the majority of e-commerce sites out there that this should be the expected functionality and so we are requesting to have an option that disables the loop_product_link() function.

Respectfully submitted,
Huusoku

Actually, I just noticed from line 134 that there is a filter for this. Looking into getting this safely into our functions.php now…

X2. Is this only a premium feature or something? Thanks

Thought that came to mind: What if we change the ‘Search in’ setting for SKU to ‘No’, then Reindex table, then change it back to ‘Yes’, and then Reindex table again? Would that cause any affect to the way SKUs are retrieved duding your search?

Regarding Hidden visibility, we have no content types (product, page, post, or otherwise) marked as Hidden.

I believe you may test this for yourself by visiting the links provided above which are publically accessible.

Thank you for the prompt response.

“Search in” setting is configured for SKU (green YES)

As stated above, indeed “Search in” setting is configured for SKU (green YES) as shown in your provided screen shot. ????

Regarding Hidden visibility, we have no content types (product, page, post, or otherwise) marked as Hidden.

Regards,
Huusoku

Hello and thank you! Both search fields finally work! Cheers ??

Hello “WebToffee Support” and thank you for the help!

We changed the one line to our code, however, the result is the same: “No orders found”.

Here are some screen shots. The first shows an example order of ours that exists in our system, WordPress post ID 14894 (circled), with Sequential Order Numbers for WooCommerce order ID 200286:

View post on imgur.com

And here is an admin order search for this order using the Sequential Order Numbers for WooCommerce order ID 200286. Entering “200286” in the default admin “Search orders” field (circled yellow) results in “No orders found”. Entering “200286” in the top menu-bar, after updating our code with the code you presented above, also results in this same exact view with the result of: “No orders found”:

View post on imgur.com

But if we enter “14894” into either field, which is this order’s WP post ID, then it will redirect straight to the WC “order number” of 200286.

So entering the post ID works, but entering the new Sequential order number does not work.

Finally, here is our setting at Admin > WooCommerce > Settings > Sequential Order Number, indicating how we have the option for, “Enable to search the sequential order numbers from WooCommerce orders page.”, enabled:

View post on imgur.com

We are very happy with the plugin, just need to get it so that we may search orders using the new Sequential order numbers.

Note: Tested on both PHP 8.2.16 & 8.3.3 and it’s the same results for both.

Thank you for the assistance!

Regards,
Huusoku

• This reply was modified 12 months ago by huusoku.
• This reply was modified 12 months ago by huusoku. Reason: Fixing imgur embed links
• This reply was modified 12 months ago by huusoku.
• This reply was modified 12 months ago by huusoku. Reason: Fixing imgur display style

!Solved

Holy cow thank you! We didn’t even realize that is an option yet it’s right below “Update interval”. We display a row of 6 so we set ours to 24 to give the user four rows of loading from our site. And yes we have 12+ years of thousands of posts to our IG

Also, those annoying cron entries are immediately gone! Thank you very much

Regards,
Huusoku

This just happened to us yesterday at work. Quick background: I’m a long-time Drupal site builder and this is my first WordPress site. WP 6.4.3, WooCommerce 8.6.0, WP Rocket 3.15.9, plus 30ish other plugins, PHP 7.4.33. Launched our new flashy site one week ago. Server load has been high, in the low to mid 1-1.5 range and yesterday around noon it was running even higher, in the 3.x range, so I looked around and decided to give this plugin a go.

I started the process and after a looooong time the page reloaded with only timing statistics/information shown in red for the very first plugin. Statistics for all other plugins in the table were blank. I thought…. “Hmmmm…. did I accidentally only run the process for just that first plugin?”, so I clicked to run the process again and my browser instantly refreshed to a blank white page. Refreshing, same blank page. Viewed page source and it is completely blank. Not even an opening <html> tag. Then loaded our front page in a new tab, instantly shows blank white page. Loaded dashboard from a bookmark, instantly shows blank white page.

Never saw any error or critical error messages. Only ever just saw blank white pages with zero content in the document/page source code.

Panic began creeping in big time. We keep nightly backups, but we already had an entire morning worth of accepting and processing web orders. In Drupal, white screen of death is usually a memory issue but during development we had our PHP running on 768 MB memory and hadn’t changed that yet, so it shouldn’t be a memory issue.

Began researching how to troubleshoot WordPress since this is my first crash in WP. Renamed plugin folder, reloaded front page, still same blank white screen. Deleted the contents of/wp-content/cache, reloaded page, and WHEW, site is up with a ton of issues.

Renamed the plugins folder back and went to Dashboard > Plugins, all plugins are disabled. We’re using about 30 plugins but have probably 40 to 50 deactivated that we haven’t cleared out yet since we’re still implementing and rolling out new features day by day on the new site launch. Having no way to know exactly which ones need to be active, I looked through our previous night’s database backup file, found “active_plugins” listed in the “wp_options” table, and built a list extracted from that showing what plugins were in use.

Slowly began enabling them one at a time until they were all enabled, except for ‘Profiler – What Slowing Down Your WP’. No issues anywhere. Site is all back to normal 100%. So strange. Also, very, very scary. Learned a huge lesson about taking a DB backup immediately before trying a sort of maintenance plugin out. Been building and operating Drupal sites for almost two decades and never had this happen. Man. That was scary. Needless to say we deleted ‘Profiler – What Slowing Down Your WP’ along with nearly all other inactive plugins. Be careful out there folks and keep backups.

“we haven’t done any configuration to WP Rocket”

To expound on this, when we moved our site from the /xn/ sub-folder to the root directory, WP Rocket had a heart attack and had to be completely reinstalled. Everything was switched off and returned to defaults, and the JS and cookie configuration we had done for the Wish List plugin was all gone.

Despite this, and having WP Rocket running and operating just fine without any added or special exclusions for your JS or cookie files, the Wish List still works flawlessly. Thank you again and have a nice rest of your week

Yes! You guys are awesome!! It works great and after moving our site to Live, we haven’t done any configuration to WP Rocket and Wish List works great. Also, we jumped up to PHP 8.1.27 and it works great.