ProjectArmy

Can you try disaling lazy loading in Jetpack settings? That might be the issue.

1. Navigate to Jetpack → Settings → Performance
2. Scroll to the Performance and Speed section
3. Click the toggle to deactivate Lazy loading for images

Once you deactivate lazy loading, make sure you clear any caching plugins you may have. If the issue still persists, don’t re-activate lazy loading. Come back and post here again, so we can see what’s happening when lazy loading is off.

The first warning “Don’t use adjoining classes” refers to .fusion-header-backface.fusion-sticky-shadow. This is valid CSS, but older browsers like Internet Explorer 6 can have problems with 2 adjoining classes. But, that’s a very old browser and I wouldn’t worry about. Warning can be ignored.

The second warning about fallback color, you simply need a HEX color:

.fusion-header-wrapper.fusion-is-sticky .fusion-header-backface.fusion-sticky-shadow {
background: rgba(255,255,255,0.8) !important;
background: #FFFFFF;
}

Also, I believe “transform” isn’t what you need. What you’re looking for is “transition” and using background-color property. The updated code below should do the trick:

/* Suggestion: Sticky bar background when scroll: */
.fusion-header-wrapper .fusion-header-backface.fusion-sticky-shadow {
transition: background-color 0.3s ease;
}
.fusion-header-wrapper.fusion-is-sticky .fusion-header-backface.fusion-sticky-shadow {
background-color: rgba(255,255,255,0.8) !important;
background-color: #FFFFFF;
}
/* Code ends */

You can put your CSS code into CSS Validator, which is more accurate than built-in WordPress warnings.

Again, you can ignore adjoining classes warning.

You can’t find it because there’s really no such thing available. There are too many ways to generate PDF from a page. I can simply hit CTRL+P on my Chrome and instead of a printer select Save as PDF.

Or, I can simply use Adobe PDF extention for Chrome to save the page as PDF.

You could try blocking PrintFriendly’s IP with .htaccess, but I don’t know what IPs they use. Maybe blocking their primary IP would work.

There are multiple services that do that, you would have to find them and see if you can block them from

Frankly, it would be a waste of time. Just like blocking right-clicking on images to prevent them from being saved. People who do these things know how to bypass whatever you throw their way.

We don’t have experience working with Office 365, we use GSuite internally. However, you might find this article useful to find SMTP details:
https://ca.godaddy.com/help/find-my-office-365-imap-or-pop-settings-9012

And a longer version from Microsoft:
https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-office-3

I assume you would be using SMTP relay, this is what Microsoft notes about that in the article above:

Reasonable limits are imposed. The service can’t be used to send spam or bulk mail.

When you use your personal email as SMTP for sending transactional emails any spam issues your WordPress emails might have can disrupt your personal emails. Also, many providers put hourly/daily/monthly limits on how many emails you can send through SMTP. I would check with Godaddy to find out what those are. Otherwise you might end up with emails not sent again, including your personal emails.

This is why we don’t recommend this route. Just FYI.

Have you tried simply disabling this plugin?

We noticed that Gravity Forms either re-used the code from this plugin or simply used the same naming conventions in version 2.4 and up. After disabling this addon plugin, the repeater functionality in the frontend continues to work.

However, backend form editor does not have blocks yet for repeater. So forms that were created this this addon plugin will continue to work in Gravity Forms 2.4+ but you won’t be able to edit them. And you can’t create new forms with repeater blocks.

This repeater feature is in beta now.
https://docs.gravityforms.com/repeater-fields/

With everything that you’ve done, the next step would be to re-install WordPress core files via FTP.

Make sure to backup everything.

First, you would delete everything but:
– wp-content folder
– wp-config.php
– htaccess file

Those 3 things should not be deleted.

Second, download fresh copy of WordPress and unzip the file. Once unzipped, you would need to upload everything back to your account. But, I would not upload wp-content again. You can delete that before uploading everything.

It’s highly likely that WordPress core files became corrupted during upgrade. Replacing them should fix the issue.

This plugin doesn’t have an undo button. Your only course of action is to recover database backup. Hopefully you’ve taken it before sweeping database.

^V