Vladimir Vassilev

Thank you for following up on this matter!

Thanks for your answer, @geraltrivia,

Sadly LocoTranslate doesn’t help much here, as even scanning the plugin’s files with it the strings do not appear. I find it safe to assume that neither LocoTranslate, nor WPML are scanning non-php files for strings.

Another problem that your dev team should have in mind is the error that LocoTranslate spits when scanning for strings:

Warning: 9 files over 100 KB have been skipped. (Largest is 451.9 KB). Check all strings are present before saving.

Thanks for the advice, Jarno!

Ah, I just realised the comment I made about the two fonts not supporting Cyrillic is not regarding Lemmony, but another recent struggle of mine with another theme.

Thank you for being so patient and helpful, “Fonts Plugin” as pointed in one of the links from your answer did the job <3

Thanks for your reply, Darian. Yet, the code my question is about is located in the free plugin. I will forward it to the premium support forum too, but I believe more people would benefit from it here.

Awesome, thank you!

Hello, @varunmatomo and @mattmary ,

Yes, I finally got it working. Here’s what I did:

1. Added a wildcard for subdomains of the main domain to be tracked by the same script in the plugin settings: *.example.com
2. I added a wildcard for the domains in the tracking script:
   _paq.push(["setDomains", ["*.example.com"]]);
3. I added a prefix to the page title of all pages from subdomains, so that I could easily distinguish them in the stats from pages that come from the main domain by adding this to the tracking script:
   _paq.push(['setDocumentTitle', document.domain + "/" + document.title]);

With this solution I can track all the subdomains in the main Matomo installation that is on the main domain and have a distinction between pages from the different subdomains.

@belgins , we’ve listed this plugin in the translation editor’s queue and the suggested translations will be addressed in near future. If you need to use your translations now, I’d suggest you export them together with the rest of the translations and upload them manually to your site.

Here’s how to do this:
1. Go here: https://translate.www.ads-software.com/projects/wp-plugins/customer-reviews-woocommerce/stable/bg/default/?filters%5Btranslated%5D=yes&filters%5Bstatus%5D=waiting
2. Set the export settings to “only matching this filter” and “.mo” file (as in the screenshot: https://prnt.sc/HkNX-Y0_jC4y)
3. Click export.
4. Create a languages directory in your content directory, and a plugins directory in the new one. On a normal WordPress installation this should look like /wp-content/languages/plugins/.
5. Upload the .mo file you just downloaded to the newly created directory.
6. Purging the cache (if any) of your site should lead to the new strings being displayed for the bg_BG locale.

Done.

All shortcodes are documented here:

https://complianz.io/used-shortcodes-by-complianz/

I’m facing a similar problem with the emails with code not being sent. An easy test to make sure that WordPress is generally sending emails and that they don’t end up in spam is by attempting to reset one’s password through the “Lost password” form. This test works for me. Yet, once I set the right username and password in login page, I am left on the verification code page without actually receiving anything neither in inbox, nor in spam.

I’ve checked the logs after setting WP_DEBUG and WP_DEBUG_LOG to true => no result whatsoever.

My environment is WP 5.5.3, the plugin is v.0.7.0, PHP is at v.7.2.34.

I’m not sure that marking the issue as resolved was the right thing to do if even it’s author had to stop using the email method and went for an alternative.

Thank you for the fast and on-point response, @kaggdesign, this worked perfectly! Not sure how I missed it in the FAQ section, but I guess I wasn’t paying attention.

Thanks for the suggestion, @tyrannous !

I don’t even remember how I solved the issue for myself, but still believe the plugin author should reconsider the usage of closures in parts of the code that should be flexible for the developers, so I’m leaving the issue as unresolved.

Hey, developit, it’s not up to the developer to publish translations of a plugin in the Directory, as there’s a centralized translations system (translate.www.ads-software.com) where Translations Editors are the folks who decide whether to approve or remove given translations. If you upload yours there, you should look for the Greek translation editors and see if they approve yours. The author simply doesn’t have the permissions for that.

It’s obvious that you need to contact your webhost in order to enable proc_open function. Seems like some hosting companies block it.