imtanuki3

@northernbeacheswebsites

I just received a copy of the flagged text and decoded it myself and it was apparent that it was xml for svg path settings.

My apologies for the false alarm. You can contact me privately or feel free to escalate this matter directly with Green Geeks. I think they’re trying to lock down exposure to malware, and I’m online with them to see if they can be a little less reactive when they see base64 code.

Shutting down an entire domain seems a bit extreme, esp since I was using your plugin in a dev subdomain.

WORKAROUND
The only workaround is to create 2 separate footers – one for pages with a sidebar and one for pages without.

A lot of work for an off-the-shelf function.

UPDATE
If I change the sidebar’s responsive visibility in Elementor to display on mobile, then social share button spacer issue goes away.

Again, this problem doesn’t exist for Elementor’s social share (or other vendor’s social share shortcode).

@jeromeramone – your comments are way incorrect. This is actually a very stable plugin…

Dragos,

Thx for the quick reply.

RECOMMENDED SETTINGS (from your note above)
Sorry, I should have noted that I had already:
– Set Fix Missing Dynamic Content = TRUE

This was to address a separate issue with Layer Slider.

I tried items 2-4 and that didn’t help.

POSSSIBLE BUG
Clearly, TranslatePress is attempting to auto format dates for Chinese, since post dates are reformatted from “September 18, 2019” –> “九 月 18， 2019″， where:
九 = the value 9 (for September)
月 = the word for month

So, it looks like someone took a shot at formatting dates according to Chinese standards, but may not have known the correct format.

The fact that dates are getting reformatted (just not correctly) tells me this is probably not a theme or plugin conflict.

EXCLUDE GETTEXT STRINGS
I’m wondering, how does TranslatePress obtain metadata (i.e. dates) from posts? Is it thru a GETTEXT string? If so, could you tell me what that string is and would adding that value to the Exclude Gettext Strings list disable auto-translate for dates?

If I could simply disable the auto-formatting of dates, I could live with manually translating each date as a string – in fact, TranslatePress’ translation admin screen serves up each of my post dates as strings, which I have translated. But when the relevant page is rendered, it appears that TranslatePress bypasses the string translations and attempts to auto-format dates.

It’s worth noting that Chinese is one of the few languages that not only changes the date component sequence (from MM-DD-YYY or DD-MM-YYY to YYYY-MM-DD), but it also mandates:
– year must be expressed as a 4 digit value.
– the actual words for year, month and day have to be appended as suffix’s to the component values.

So, I’m thinking the fastest and easiest resolution would be disabling auto-format and forcing users to manually translate each string…

Thanks again!

• This reply was modified 5 years, 4 months ago by imtanuki3.
• This reply was modified 5 years, 4 months ago by imtanuki3.

Dragos

I did in fact figure out what was causing the issue – for anyone else using Layer Slider and TranslatePress:

–> you have to disable Layer Slider’s caching, otherwise it maintains the source language in cache and will always return that string value to Translate Press.

Thanks!

And now it’s not! This is really baffling…
– I set fix missing dynamic content = TRUE
– it worked
– I added new translations
– and now it’s not working again

“not working” = just displays in original English

UPDATE
– The fix missing dynamic content flag eventually kicked in – now it’s working! IDK, maybe a cache issue?

Anyway, if anyone else is having a problem translating sliders (e.g. Layer Slider), go to advanced tab in Translate Press and set fix missing dynamic content = TRUE.

TROUBLESHOOTING – UPDATE
– Fix missing dynamic content = TRUE (no change)
– Tested mobile browsers Firefox, Chrome, Brave (no change)

In all cases on mobile, still rendering English even though Chinese is the selected language…

• This reply was modified 5 years, 4 months ago by imtanuki3.

@ogalinski – totally agree. I don’t think the issue is whether Admin Columns is a good(great) plugin. For me, the 2 questions I always ask are:
– is the freemium version at least usable？
– is the pro plan reasonably priced？

In the case of Admin Columns:
– the freemium version is essentially NOT usable, although it gives you a sense of what the pro plan might do.
– $49 per year (for just the personal plan) is way overpriced for a back-end function.

Consider that really powerful pagebuilders like Elementor are $50 a year and provide substantially more value than Admin Columns. And products like Duplicator provide fully usable freemium options.

Someone will see the gaping hole in this marketing plan and write a reasonable alternative.

Original site (prod) was approx 475MB
Site with issue (dev) is now 515MB.

But…
– at one point, I was able to back up dev (515MB)
– now I can’t even backup just the db (24MB).

Will open a ticket.

Cory,

Thx for the quick reply. Will submit ticket.

Thanks. Understood re free plugin. However, this is a fairly standard tweak. Is there any reference on your site that describes the css code?

Thanks for the super-quick reply!

Unfortunately, DupArchive format tops out at 500MB (I’m at 680), so that option is out.

Softaculous backup is size-independent, but it’s a really weird UI and this hosting service has limits on the number of backups.

So, I’m spending New Years’s day cutting over from self-hosted videos (highly flexible) to youtube videos – that will eliminate my zip file size and other limits and I can go back to using duplicator…