guev4ra

Hi @shameemreza again,

I would like to get your opinion on this.

From what I could log using standard save() WC method, here are the breakpoints as regards to database changes:

wp_posts

UPDATE wp_posts SET post_modified = '2024-09-20 11:15:56', post_modified_gmt = '2024-09-20 11:15:56' WHERE ID = 34405
UPDATE wp_posts SET menu_order = 1 WHERE ID = 34429
UPDATE wp_posts SET menu_order = 2 WHERE ID = 34430
UPDATE wp_posts SET menu_order = 3 WHERE ID = 34431
UPDATE wp_posts SET post_modified = '2024-09-20 11:15:56', post_modified_gmt = '2024-09-20 11:15:56' WHERE ID = 34429

Generally, it just sets the timestamps, as well as menu_order when variations are present. In this case, this is irrelevant, should be as it is.

wp_options

UPDATE wp_options SET option_value = '1726830956' WHERE option_name = '_transient_product_query-transient-version'
DELETE FROM wp_options WHERE option_name = '_transient_wc_product_children_34405'
DELETE FROM wp_options WHERE option_name = '_transient_timeout_wc_product_children_34405'
UPDATE wp_options SET option_value = '1726830956' WHERE option_name = '_transient_product-transient-version'
INSERT INTO wp_options (option_name, option_value, autoload) VALUES ('_transient_timeout_wc_product_children_34405', '1729422956', 'off') ON DUPLICATE KEY UPDATE option_name = VALUES(option_name), option_value = VALUES(option_value), autoload = VALUES(autoload)
INSERT INTO wp_options (option_name, option_value, autoload) VALUES ('_transient_wc_product_children_34405', 'a:2:{s:3:\"all\";a:3:{i:0;i:34429;i:1;i:34430;i:2;i:34431;}s:7:\"visible\";a:2:{i:0;i:34430;i:1;i:34431;}}', 'off') ON DUPLICATE KEY UPDATE option_name = VALUES(option_name), option_value = VALUES(option_value), autoload = VALUES(autoload)

All of the changes related to wp_options table are in regards to transients. Anyway, these are all cleared on each mass update.

wp_postmeta

UPDATE wp_postmeta SET meta_value = '0' WHERE post_id = 34429 AND meta_key = '_stock'
UPDATE wp_postmeta SET meta_value = 'outofstock' WHERE post_id = 34429 AND meta_key = '_stock_status'
UPDATE wp_postmeta SET meta_value = '0' WHERE post_id = 34429 AND meta_key = '_percentage_discount'
INSERT INTO wp_postmeta (post_id, meta_key, meta_value) VALUES (34405, '_price', '24.9')

This is in fact the table that holds the actual stock and stock status. What is important here is to note that each product and parent product of variations must have “instock”/”outofstock”. As for the managing quantity, I noticed that managing parent quantity is irrelevant (correct me if I’m wrong). The _price is also irrelevant in this case.

wp_term_relationships

INSERT INTO wp_term_relationships (object_id, term_taxonomy_id) VALUES (34429, 9)

This table holds the term_taxonomy_id – which references outofstock products in combination with “product_visibility” on term_taxonomy table. If the stock is greater than 0, then this row should be deleted.

wp_termmeta

UPDATE wp_termmeta SET meta_value = '17' WHERE term_id = 300 AND meta_key = 'product_count_product_cat'
UPDATE wp_termmeta SET meta_value = '33' WHERE term_id = 301 AND meta_key = 'product_count_product_cat'
UPDATE wp_termmeta SET meta_value = '25' WHERE term_id = 71 AND meta_key = 'product_count_product_cat'
UPDATE wp_termmeta SET meta_value = '17' WHERE term_id = 300 AND meta_key = 'product_count_product_cat'
UPDATE wp_termmeta SET meta_value = '33' WHERE term_id = 301 AND meta_key = 'product_count_product_cat'
UPDATE wp_termmeta SET meta_value = '25' WHERE term_id = 71 AND meta_key = 'product_count_product_cat'

wp_term_taxonomy

UPDATE wp_term_taxonomy SET count = 1922 WHERE term_taxonomy_id = 9

For some reason, it updates wp_termmeta twice. Anyway, this will be done later on calling wc_recount_all_terms() function.

wp_stock_log

INSERT INTO wp_stock_log ( date_created, product_id, qty ) VALUES ( '2024-09-20 11:15:56', 34429, 0 )

Optional, but still notable

wp_wc_product_meta_lookup

REPLACE INTO wp_wc_product_meta_lookup (product_id, sku, virtual, downloadable, min_price, max_price, onsale, stock_quantity, stock_status, rating_count, average_rating, total_sales, tax_status, tax_class, global_unique_id) VALUES ('34429', '', '0', '0', '24.9', '24.9', '0', '0', 'outofstock', '0', '0', '0', 'taxable', 'parent', '')

REPLACE INTO wp_wc_product_meta_lookup (product_id, sku, virtual, downloadable, min_price, max_price, onsale, stock_quantity, stock_status, rating_count, average_rating, total_sales, tax_status, tax_class, global_unique_id) VALUES ('34405', '105064', '0', '0', '24.9', '24.9', '0', NULL, 'instock', '0', '0', '0', 'taxable', '', '')

In order to recalculate lookup tables, we’d have to fill this data. REPLACE INTO, ofc, uses primary key in order to match the data and update/create it accordingly. 2 queries are for variation and it’s parent post.

Hope this can be of help to someone else.

Hey @shameemreza ,

Thank you very much for your answer. Of course, I understand that none of the standard WC functionality while updating db directly won’t work. Hence, this question to find a workaround.

Just to clarify, right now, I’ve concluded that I need to update following things:

1. Update “_stock” on postmeta table
2. Update “_stock_status” on postmenta
3. Update “in_stock” on wc_product_attributes_lookup
4. Update “stock_quantity” on wc_product_meta_lookup
5. Update “stock_status” on wc_product_meta_lookup
6. INSERT/DELETE “object_id – term_taxonomy_id” on term_relationships table. term_taxonomy_id would be join terms and term_taxonomy tables where term.name is outofstock and taxonomy “product_visibility”. This is used in order to include/exclude products while calculating terms count in _wc_term_recount() (count for categories, tags, attributes etc).

And after queries are executed, I clear transients also by direct DB update, and hit couple of accessible wc functions:

wc_delete_product_transients() 
wc_recount_all_terms();
if ( ! wc_update_product_lookup_tables_is_running() ) {
wc_update_product_lookup_tables();
}

So, in total, 6 queries to handle stock quantity synchronization, which takes me total around 2-3 seconds (incl formatting, initial API call for stock quantity, and execution of things above) for 4-5k products with variations which is solid.

As far as I could tell, this does the job, but, since WC is quite big of a project, I’m not sure it handles everything correctly.

On the other glance, do you notice that I miss something else?

Really appreciate the answer.

Can confirm this also.

@faithcoder of course.

Anyway, ill provide further screnshots of what I meant.

As i do some dev myself, this change wont affect it probably in any way, and probably ever ??

Its just a quick patch on the users client side end to enable the delay of mega menu loading.

Comparing it to astras pro mega menu feature, they dont use js to determine the difference between first item and left-most point of the screen and shift the layout, but rather they just position it relative to the complete header itself. So in the end, they avoid using Js for positioning which is far more effective.

Thank you for the support and suggestions

Hey @faithcoder, we kind of misunderstood eachother.

In the end it works as it is supposed to. Only issue is that it uses JS to resize the width of background container of the submenu or .elementskit-megamenu-panel.

Now, when the user clicks it and does not remove it’s cursor from the element, next page load screen is ugly, as it is shifting the layout.

One quick patch that I added is to hide the subpanel untill the js is fully loaded. To be sure further that the elementskit js files are further loaded, I’ve added extra 400ms of waiting time. In the end, patch should be something like:

// css
body:not(.loaded) .elementskit-megamenu-panel
{
display:none !important;
}

//js 
window.addEventListener("load", function () {
    setTimeout(() =>{
        document.body.classList.add("loaded");
    }, 400);
});

Would be good if there is some kind of JS hook that comes from the plugin, so we can apply this behaviour once it’s triggered to make it running even more smoothly.

Hope you understood my issue ??

• This reply was modified 1 year, 3 months ago by guev4ra.

@faithcoder, thanks for reaching out.

Currently, Im in dev mode, but as soon as it is gonna be deployed, servers response will be optimized, but still the issue will persist (its pretty much irrelevant if it is .5s or 2s, it still catches my eye) ??

So, in the end, right now there is no convenient solution for this problem? Can we expect maybe update anytime soon, as I suppose this feature is widely used?

Thanks a lot

• This reply was modified 1 year, 4 months ago by guev4ra.

Hi, @rainfallnixfig

Just a little bump, since I couldn’t find solution for this problem.

I would highly appreciate any help.

Thanks

Hello. Thank you for your quick answer. Here are the following screenshots:
These two are my tax setup (there are over 30k rows with every zip code included)
https://i.snipboard.io/hsA8qL.jpg
https://i.snipboard.io/gmDCWL.jpg

This is a working example where both ZIP CODE and State are entered properly (10001 ZIP is in NY)
https://i.snipboard.io/NV4Akn.jpg

Now comes the ZIP Code that is invalid for this state
https://i.snipboard.io/nG1AR7.jpg
99605 is ZIP from AL, but the picked state is NY in this case, so placing the order would not be possible (where would user get the similar logic as with Automated taxes feature, throwing error, disabling placing order and throwing up notice with message on the top). If either one of the following conditions is fulfilled, customer could place the order and proceed with his payment:
1. ZIP is either changed back to valid ZIP from NY
2. Country should be picked to be AL

PS: Would be also good if ZIP code that the user entered does not exists in taxes standard rates table (meaning it is invalid), to also disable placing the order.

Thank you

I guess someone might find this useful, as this solves a problem for me, since I guess there is no built in functionality for this part.

$(document).ready(function() 
{
	$('li.button-variable-item-let-us-design-for-you').click(function(e) { 
		$(".codedropz-upload-wrapper").hide();
	});

	$('li.button-variable-item-upload-your-own-design').click(function(e) { 
		$(".codedropz-upload-wrapper").show();
	});
});

• This reply was modified 3 years, 4 months ago by guev4ra.

Fixed it. The solution above will make your simple portfolio gallery to break into two columns if width of screen is less than 1300px, and force 3 columns if it is greater than 1300px, with nice padding around:

@media screen and (max-width: 1300px) {

	#foogallery-gallery-614.foogallery.fg-simple_portfolio .fg-item {

		margin: 20px !important;
		max-width: calc(50% - 40px) !important;

		min-width: calc(50% - 40px) !important;
	}
}

@media screen and (min-width: 1200px) {

	#foogallery-gallery-614.foogallery.fg-simple_portfolio .fg-item {
               margin: 5% !important;

		max-width: calc(30% - 180px) !important;
		min-width: calc(30% - 180px) !important;

	}

}

• This reply was modified 3 years, 9 months ago by guev4ra.
• This reply was modified 3 years, 9 months ago by guev4ra.
• This reply was modified 3 years, 9 months ago by Yui. Reason: please use CODE button for proper formatting

First part of question was solved easily. Search form was disabled accidentally, therefore I just turned it on.

Second part of the question was also almost solved. The thing was that the magnifying glass icon was already there, but without any padding and was filled with color of white, where having my ul/li block also with the background of white, it was invisible. Changed it simply by adding following code in custom css of ivory search to change the color of the icon and added some padding in my li box:

@media (max-width: 763px){
.is-menu.sliding .search-icon-path{
fill: #202020;
}
.is-menu.sliding{
padding:13px 4px;
}
}

• This reply was modified 4 years, 1 month ago by guev4ra.
• This reply was modified 4 years, 1 month ago by guev4ra.