jetxpert

Hi @wpzainab,

Unfortunately, the issue we reported above was not fixed with your recent plugin update, V2.0.2 (released today, November 1, 2021).

Please advise.

Thank you!

Hi @wfpeter,

Done. Thank you.

Cheers!

Hi @gvectorssupport,

Respectfully, we’re fully aware of the temporary solution you provided. We have used it but is forcing us to use a Child theme and modify your plugin’s core files.

All we’re asking is for your DevOps team to add a tooltip to your voting icons — no different than the other tooltips you’ve already added for other portions of your plugin.

Should be pretty easy to accomplish.

Thank you!

Update:

We fixed the issue (for now, at least). Your plugin update affected several CSS selectors for the bubble wrapper element. That is:

Bubble Wrapper Selectors for V7.3.4 (OLD):

#wpd-bubble-wrapper>div

#wpd-bubble-wrapper>#wpd-bubble #wpd-bubble-add-message

#wpd-bubble-wrapper>#wpd-bubble #wpd-bubble-add-message::before

#wpd-bubble-wrapper #wpd-bubble-all-comments-count

Bubble Wrapper Selectors for V7.3.5 and up (NEW):

#wpd-bubble

#wpd-bubble-count

#wpd-bubble-add-message

#wpd-bubble-add-message::before

#wpd-bubble-all-comments-count

Hi @gvectors-team,

We can confirm that upgrading from V7.3.4 to V7.3.5 (or V7.3.6 as of today) causes the CSS styling issue we initially reported.

Note: To be more specific, the plugin update affects the elements noted below. Others seem to be OK for now.

Affected Elements (all related to the following code):

#wpd-bubble-wrapper>div

Here’s what we did:

(1) We cleared cache (all levels) per your instructions and still have the problem.

(2) When we downgraded V7.3.5 (or V7.3.6) to V7.3.4 the problem was fixed.

To duplicate our issue:

(1) Our environment: Avada theme, WP 5.8.1, PHP 7.4.25.

(2) Update V7.3.4 to V7.3.5 (or V7.3.6 as of today): CSS custom styling entered in your plugin (i.e., settings) are not accepted.

(3) Temporary fix: Move CSS custom styling from your plugin to Avada’s CSS custom styling section.

In short, we can confirm your plugin has a bug. Kindly investigate further and provide a fix (i.e., plugin update).

Thank you!

Hi @hristo-sg,

As promised, we received feedback from Theme-Fusion (Avada) Support. Their reply:

If the compiler is disabled nothing is cached and so there is no specific function created to clear any cache (as we do not have any caching mechanism).

The performance options we do give can all be disabled which allows the user to make use of their own plugin/setup if needed.

So, in short, it appears Avada’s caching functions are built into its CSS and JS Compilers.

To disable Avada’s caching functions, the user needs to disable the following in Avada’s Settings:

Path:

WP Dashboard > Avada > Options > Performance

Settings (To Disable Avada Caching):

CSS Compiling Method: Disable
Load Media-Queries Files Asynchronously: Off
Enable CSS Variables: Off
Enable Critical CSS: Off
Enable JS Compiler: Off

We are now using the above Avada settings and are monitoring our original issue.

If we experience the same issue again (after disabling Avada’s caching functions), we’ll open a new topic.

Hopefully not ??

Cheers!

Hi @hristo-sg,

Yep, we know that ?? Perhaps we didn’t explain or state our question properly.

To be more specific (example):

Will this exclusion rule: www.site.com/blog* cover the following URLs:

www.site.com/blog (without a slash)
www.site.com/blog/ (with slash)
www.site.com/blog/how-to-use-wildcards (without a slash)
www.site.com/blog/how-to-use-wildcards/ (with slash)

We’re simply trying to confirm SG handles wildcards same as Cloudflare does.

Thank you!

Hi @wfpeter,

We appreciate your reply and shedding more info on our reported issue.

Below please find two classical examples confirming your Live Traffic engine may need to be updated to reflect more accurate information.

Confirmed “Bot” reported as “Human”: https://ibb.co/8d7LJzW
Confirmed “Human” reported as “Bot”: https://ibb.co/7GpSrLj

Also, we need to ask: How does Live Traffic handle bots and visitors when a VPN or a browser in Private Mode is used? Is Live Traffic still capable of detecting the right type of visitor?

Hope this helps.

Thank you!

———————

Confirmed “Bot” reported as “Human”:

Confirmed “Human” reported as “Bot”:

Hi @hristo-sg,

Following our previous update, please click below for a better look at our issue.

Details: https://ibb.co/LkvJ9dW

Again, we’re waiting for Theme-Fusion’s reply to our request. Stay tuned.

Thank you!

Hi @hristo-sg,

Unfortunately, there’s no way to disable Avada’s caching function(s) at this time.

We have, however, reached out to Theme-Fusion (Avada) asking for a filter that will allow us to do so.

Stay tuned. We will share Theme-Fusion’s feedback and/or filter as soon as received.

Thank you!

Hi @sterndata,

Thank you. Done!

WP Trac Ticket No. 5920

Have a great day!

Hi @tedandtom,

We use Mailpoet and issue newsletters with images. So far, our customers have not reported any issues related to viewing our newsletter images with their iPhones (updated to iOS 15.0.1, Apple’s latest iOS release as of today).

In any case, the following should solve the issue:

(1) First Option:

Ask your customers to turn off Privacy Protection (a new feature released with iOS 15).

If that fixes the issue, then either your email client, your host, or MailPoet are injecting invisible pixels (data trackers) into your newsletter content or images. MailPoet can confirm the latter.

For more information, read below:

https://support.apple.com/en-us/HT212797
https://www.iphonetricks.org/fix-unable-to-load-remote-content-privately/
https://www.macrumors.com/2021/06/10/ios-15-mail-privacy-protection-tracking-pixels/

(2) Second Option:

(may not solve your main issue, but will solve other issues related to images not loading in Safari)

Toggle the following Safari Experimental Features to ON (all others OFF):

* Aspect Ratio of < img >
* CSS Aspect Ratio
* CSS Color 4 Color Types
* GPU Process: Canvas Rendering
* GPU Process: Media
* GPU Process: Video Capture
* ImageBitmap
* Intersection Observer
* Media Session API
* NSURL Session WebSocket
* Private Click Measurement Fr
* VP9 decoder
* Web Share API Level 2
* WebGL 2.0
* WebGL via Metal
* WebM MSE parser
* WebM Web Audio
* WebRTC Platform Codecs
* WebRTC Platform TCP Sockets
* WebRTC Platform UDP Sockets
* WebRTC VP9 profile 0 codec

Hope this helps a bit.

Best wishes!

@daitarn3,

Our two cents worth:

We also use Rank Math. We refuse to update our robots.txt, htaccess, and plugin files via Rank Math’s file editor feature which — in your case — are probably blocked due to iThemes Security.

We use Wordfence and it’s also blocking the above files. We love it. It’s doing its job.

Instead, and for safety reasons, we recommend that you edit or update your files directly via cPanel or using your host’s editing tools like Site Tools (offered by SiteGround).

Hope this helps a bit.

Cheers!

@dvazquez260376,

We switched to Wordfence and love every bit of it. Support for both their Free and Pro versions is phenomenal.

Let’s hope iThemes will catch up soon. We purchased a lifetime license from them so our expectations are high.

Best wishes!

Hi Peter,

As always, excellent reply. Very helpful. Thank you.

Yes, we agree. We need to let Cloudflare and Wordfence do their job and not implement an all-out manual blocking plan. If we did, it would be a full-time job.

On the other hand, there are benefits to studying attack patterns (i.e., threats) that only affect a particular website and manually block those threats (and bad bots) not yet captured by Cloudflare nor Wordfence.

For example, SeznamBot refuses to respect our robots.txt directives so we have blocked them with Cloudflare (not Wordfence). Amazingly, SeznamBot is quite “smart” and has increased its crawling rate of our website due to our block. So, as a side note, we highly recommend Wordfence remove SeznamBot from its “Allowedlisted Services” list and use the bot as an example to improve Wordfence’s WAF.

In short, based on your answer and our research, we block bad IPs, user agents, bots, etc using Cloudflare — and only when our robots.txt directives are not respected or unique threats are identified.

Again, thank you!