Markup Prices randomly disappears

This is puzzling. I’ve never encountered anything like it before, and I’ve been reviewing the code to see how it is possible.

But first, be assured that changes to the attributes after you have run the Set regular prices function do not affect the products. So, if you have priced the products, the markup will remain on that product regardless of what happens to the attribute’s markup.

Nonetheless, this is still a problem. I cannot find any direct cause, so I will outline how the plugin works regarding the storing of markups and the language translation. Perhaps this will help.

• Markups seen on the Attributes’ page are stored in the wp_termmeta table, with the term_id and a meta_key of ‘mt2mba_markup’. I can think of only two ways that they would disappear. (1) If the term_id changes (for instance, an attribute term is deleted and recreated). Or, (2) if the wp_termmeta table was damaged.
• The “(Markup: xxx)” that appears in the attribute term description is a constant which is defined using the standard WordPress internationalization notation, “__( string $text, string $domain = ‘default’ )”. The only way I can think of that would cause it to be written to the description in English, would be if the WordPress Settings >> General >> Site Language was set to English at the time.

I have absolutely no explanation for why these two things would happen together. And yet, the examples you’ve provided indicate that if the description is in English, the markup is missing. Can you tell me if the terms on this page, https://ibb.co/8YD74hV, were all created at the same time?

• This reply was modified 3 years, 5 months ago by Mark Tomlinson.

Hi @marktomlinson,

thanks for your reply. Yes, that is a very strange behaviour indeed.

Basically the way how to fix the issue for the moment is:
1) set the markup price again for the attribute where it is missing, the markup price will then show up in the description as (Aufschlag: +xx). All other attributes we setup once and they never disappear shows as (Markup: +xx)
2) go to the belonging products and set the regular price again, save the product
3) after that the prices are recalculating and the markup price will work again in the front end for the attribute

What we don’t understand, and you neither it seems :), how the markup price can just disappear from the attribute and why only for 2-3 attributes. We are using more than 200 attributes with different markup prices and they are all fine except these 2-3. And it happens again and again. So as you can understand it is very annoying to set it for a few products with more than 40 variations each.

Up to my understanding, the term_id would only change if we delete or recreate an attribute. But that is never the case. We already setup the attributes a long time ago and never changed them. If the wp_termmeta table is damaged i can’t tell you. Is there a way to test that? And if it’s damaged, it would be damaged only for 2-3 attributes. Is that even possible?

Would a new creation of the same “buggy” attributes help? Like:
1) delete the 2-3 buggy attributes at all (the ones where the markup price always disappears)
2) create them new
3) create a new product (basically a duplicate of the already existing one) and assign all attributes and variations again. Set the regular prices again.
4) this would create new IDs and belongings in the database
5) of course that’s a real pain in the ass and a lot of work to recreate all variations but maybe the only choice if you can confirm it would help

The site language is german from the beginning and was never changed.

“And yet, the examples you’ve provided indicate that if the description is in English, the markup is missing”: no not really… all attributes with the markup price we never had any problem are still showing “Markup: xx”. Only if the markup price is gone and we set it new, it will show the german “Aufschlag: xx” afterwards.

The terms in the attributes were all created at the same time when we created them first. Sometimes we just add new attributes if it’s necessary and give them a markup price if needed. But also they are fine and no problem at all.

The only reason for adjusting already existing attributes is when the markup price disappears.

And as you can see here https://schultz.de/product/4-fuss-klapptisch-gestell-lichtgrau the markup price is working in the same product for the color attribute and attribute showing “Tellerfü?e”. But the markup is not working in the attribute showing the dimensions like “180 x 80cm Gewicht xx” and that is exactly the attribute where the markup price just disappeared.

Sorry for the long text. But i have no idea how to explain that strange bug other than that. Maybe it would help if you get access to the backend?

Cheers Alex

Hi Alex,

Yes, this is really insane behavior. It is good to hear that the English text and the missing markup are not tied together.

Let me address the English text first.

First, the examples you showed me are only the descriptions in the attribute terms. Those are not seen by the customer, so they may not be a concern for you. If your site administrators understand that “Markup” and “Aufschlag” are the same, you probably don’t have to worry about fixing this.

The only thing that could cause it to randomly occur is a misfire in the WordPress internationalization (i18n) functions. The entire line in the plugin is
define( 'ATTRB_MARKUP_DESC_BEG', '(' . __( 'Markup:', 'markup-by-attribute' ) . ' ' );
We know the plugin is executing the line because we see the word “Markup:” in the description. So, the only thing that leaves is WordPress deciding not to honor the __( xxx, xxx ) part of the code, which tells it to look up the translation. I’m going to explore further, but it sounds like it might be a problem in your WordPress installation.

Regarding the missing markups. I’d say the steps you outline at the beginning of your post are about the only way to address it. But, I would add a step 1.5; after adding the markup, edit the term again to ensure the markup is there. Let me explain.

From your description and the sample, it appears that you add the markup to the term, but it does not get written to the database. There is an important distinction here; it does not sound like the markup disappears. Instead, it never gets saved in the first place. I arrived at this because the markup is not applied to the products, meaning that it was not available when you ran the Set regular prices function.

I know of no way for this to happen unless there is a problem within your WordPress installation. But, you can disprove this theory if you know of a variable product that showed the markup in the price, and then the markup disappeared.

Do you have access to your debug.log? I’d like to suggest that you set debugging on before correcting the attributes. If the problem reoccurs, check the debug log to see if anything suspicious happened.

My code can be found on GitHub. https://github.com/Mark-Tomlinson/markup-by-attribute-for-woocommerce. It’s not the prettiest, but I try to keep it well commented.

Hi @marktomlinson,

thanks again!

Like you said, the translation of the markup description is not necessary and not a big deal. It was just an information because it was possible that there is any connection between the language and the missing markup prices.

That the markup price is not stored successfully in the database makes sense at first but why it is working if we set the markup price again and save the product with its regular price for each variation again? If the markup price is not stored in the database where the calculations are coming from at this time all is working fine? So basically the markups must be stored in the DB but just disappear after a random time.

This example IS a variable product! https://schultz.de/product/4-fuss-klapptisch-gestell-lichtgrau Actually we are talking only about variable products.

The idea with the debug.log is a good one, we will keep that in mind. Unfortunately it seems to be the only way to recreate the attributes and products belonging to that issue. The admin will be “happy” ??

Thanks. Alex

That the markup price is not stored successfully in the database makes sense at first but why it is working if we set the markup price again and save the product with its regular price for each variation again?

This would happen if WooCommerce or WordPress has some type of intermittent issue writing to the database. My thought is that there is an error caused by a memory overrun or server lag or some such, which does not happen consistently. This would show up in the debug.log. I could use that information to determine if the plugin is contributing to the error.

Obviously, if you capture an error, you’re going to want to set debugging off, since that’s seen as a security risk. But I like to leave debugging on when a site starts up, so I can catch any errors that themes and plugins might be causing.

• This reply was modified 3 years, 5 months ago by Mark Tomlinson.

Hi @marktomlinson,

Thanks for your reply. I have the debug.log active since yesterday and was asking the site admin to set up the markup prices and regular prices for each variation again. Let’s see what the debug will tell us if the markup price disappears again.

I will let you know as soon as it happens.

Thanks for your kind support so far!