gonssal

There is absolutely no mention about all the new now-“premium” features, that previously worked perfectly fine in the free version, in the plugin’s changelog. You are deceiving your users and you know it.

To prospective users, please don’t use any of this developer’s plugins, they will break your site without warning in the name of getting your money. They for example renamed and removed shortcodes and changed the name of options in the database, deleting the old ones, so you can’t go back to previous versions easily.

Sadly it’s not properly fixed. If the sale price is 0 it will set it to the regular price.

So not even an acknowledgement of the issue or a simple thank you for pointing out the exact problem, wow.

One of my clients has this same problem and it’s not because of their theme.

The problem is that your plugin has a bug in the WAD_Discount::get_sale_price() function when called from the woocommerce_product_get_sale_price filter, which always returns 0 for simple products that don’t have a specified sale price. This of course causes any theme trying to calculate the discounted percentage to show 100% because it gets 0 as the product’s discounted price.

Resolved reinstalling it.

if ( class_exists( 'JCSubmenu' ) ) :

• This reply was modified 8 years, 2 months ago by gonssal.
• This reply was modified 8 years, 2 months ago by gonssal.

The problem is that YITH Essential Kit for WooCommerce #1 got automatically installed without me asking for it in the first place. So no, I’m not changing the bad review.

It’s done. I only translated the stable release strings, not the Readme.

Any updates on this? It’s just a matter of adding a link to wp-admin/update-core.php that will make people’s life a bit easier.

s

Just posting in case it helps someone.

I’ve been “attacked” by the 92.63.88.86 IP (seems to be from a Latvian Wi-Fi company, so untraceable). Apparently the attacker somehow managed to get one of the site’s admin credentials (I guess he brute-forced the existing admin username, but not sure), then used a script to automatically login and upload the WSO PHP Shell in my current theme folder through the Theme Editor in WordPress.

If the above paragraph is hard to understand to you, to check if the same thing happened to you, you want to:

• If it’s the same attacker, he used the gfeed.php filename for the WSO shell. Search for it in your installation
• If that doesn’t work, search text inside files for the string “wsoHeader”. It’s the first function in the WSO shell source code.

If you get results for the above searches, you might be in trouble. The WSO shell gives the attacker absolute control on everything the web server can get to. That means that apart from creating/editting files freely, he will also have access to at least the WP database.

Luckily for me, it seems in my case the attacker only managed to create a new Administrator user before I cleaned up. Still checking though.

To know if the attacker used the shell in your system, search for the filename you found on the above searches in the apache access log. If there’s more than 1 entry, the attacker has been using the shell in your system.

It’s not possible to know what he has done, so my advice is that you load a backup without the wso shell file.

By default the message shows only once per user, so you won’t see it again unless you change the defaults.

Go to the plugin settings, Advanced tab and set:

• Skip first visit: Unchecked
• Display pace: Everytime

Max display count: 0

Then you should see the popup everytime. When you are sure it works, set the options to some sane values so your users don’t get annoyed everytime.

Also please note that it only works with iOS or with Android + Chrome.

Ok thank you, I was missing the “Display pace: everytime” option. Now it shows everytime.

Just forget what I worte in the following paragraph, I just noticed that these changes are in the GitHub repository.

Now to the languages part. My native language is Catalan, which for example in Firefox corresponds to the ca locale (some other software make it ca_es). The problem is that in the plugin’s javascript, there’s this line:
if(ath.language.length==2){ath.language+="_"+ath.language}
That makes it impossible for me to set the strings in catalan. Also, for example in Spanish, there’s a lot of possible locales (es_es, es_mx, es_ve, es_ar, es_ch, etc…) so, if someone from Mexico has the es_mx locale instead of es_es (they won’t see the message in spanish, but in english.

In my opinion the javascript should be modified to not only allow 2 char locales, but also to check if the first 2 chars of a 4 chars locale (en_gb) match a defined one (en or en_us). Also I think the locales that don’t have variants should be defined as 2 chars, so the es_es should be defined as just es, the it_it as it (and the en_us as en, though this one won’t make any difference being the default), etc…

If you are ok with this changes and don’t have time to implement them yourself, I can make a pull request to the github repo.

Also I’d like to share one more language strings so you can add them.

Catalan:
ca:{message:"Per afegir aquesta aplicació a la pantalla d'inici: prem %icon i selecciona <strong>%action</strong>.",action:{ios:"Afegir a la pantalla d'inici",android:"Afegir a la pantalla d'inici",windows:"Afegir a l'inici"}}
Note that this will never work with the current code because the locale is not ca_ca, but ca_es (we don’t have a country yet).

Thanks for your quick answer.

It seems it’s working now, but I have to say the debug mode only works randomly (when changing application ID and/or clearing locale storage). I’m using Firefox for development. Also, even with me having the “Skip first visit” option unchecked (which I would make the default tbh), sometimes it doesn’t pop up in the first load, but then pops up after reloading.

Another problem I’m having is that, even with the website being in Spanish, the message pops up in English. I can see the spanish string in addtohomescreen.min.js so there must be some problem with the language detection. I’m translating the theme with a .mo file, so I’m pretty sure the locale is properly set because it gets the strings from it, using load_theme_textdomain(). I’m setting the locale with define (‘WPLANG’, ‘es_ES’);