If you're a small business owner seeking to better understand the difference between inexpensive (cheap?) shared hosting and WordPress managed hosting, then watch this video as WordPress coach, trainer, and consultant, Tony Zeoli, walks you through the difference between various hosting services and their offerings.

I am pleased to post my WordCamp Asheville presentation: Standardizing Your WordPress Workflow. This presentation covers the strategy in developing a workflow that works for your small business or agency.

I'm excited to share this WordCamp Raleigh 2017 presentation on Social Meta Optimization. This presentation is for social media managers and digital marketers who want to learn how to optimize WordPress posts and pages as social objects to be shared in social media. You'll learn how to set a photo or video, title, description, and link for each post or page, so that your social shares communicate your message correctly.

This post feature the WordPress SEO for Beginners presentation slide deck for my talk at WordCamp Raleigh 2017. You'll also find a link to download the popular All in One SEO Pack Pro and a coupon code to get 50% off the subscription price.

Digital Strategy Works founder and WordPress Consultant and Trainer, Tony Zeoli, is coining the phrase, "WordPress Assembler" to describe the combined skillset of someone who builds websites with today's powerful theme frameworks and page building tools. While it's not yet a common term, it may become one as more people turn to theme frameworks to layout and style websites and blogs, while solving common design and development issues that are now baked into these powerful products.

This post will help you understand how to redirect WordPress pages and posts when you simply change the TLD of your site in the database without actually redirecting between two site instances with two different TLDs. There should be no reason to launch an entirely new site on a new instance at your host, when you can simply use the Page Rules setting in Cloudflare to manage one to one redirects from the old TLD extension to the new TLD extension for the same domain name.

Here are a few tips for you about using/uploading images to your WordPress site.

First, web browsers do not render 300 dpi, so for all you photo fanatics out there, stop uploading uncompressed 300 dpi images to your media library. A browser renders only 72 dpi regardless of the resolution of your images. Yep, I know it reduces image quality, but only to you! Remember, your perception is your reality. The person viewing your image online doesn’t care whether it’s 300 or 72. They just want to see the image. Sure, that doesn’t help photographers or art galleries much, so you’ll just need to go old school and FedEx your printed books instead, if you want your intended audience to see the full resolution image.

Second, reducing the dpi also reduces the file size. If you have 300 dots per in, then reducing it to 72 dpi is only going to help your website visitors download your images faster, especially over mobile phones. Remember that we all have finite mobile bandwidth, except those who pay for unlimited. That means you are burning up your website visitors mobile bandwidth allotment (if not on wifi) by not compressing your images. If I were looking at your photos, then waiting for them to download on my phone and it’s not fast, I would leave your site and go somewhere else. No one wants to wait for your huge images to download on their phone.

Third, you can certainly reduce the dpi and that will compress an image, but remember the physical landscape of the image itself should only be sized to what you need to display on the web. That’s probably around 1800 pixels. I’ve seen some clients upload photos that are over 3000 pixles wide! Resizing your images BEFORE you upload to your media library is important. Fortunately, WordPress now provides a resizing tool inside the Edit feature of your WordPress Media Library, so you can resize photos down. Note: Never resize photos up or you will literally be stretching the photo like a rubber band. That will stretch the pixels in the image and your image will look like crap. You always downsize. Never upsize!

Fourth, you can use a tool like WP Smush, which is a freemium plugin, to compress your images to the best possible size and resolution. When you install WP Smush, you can compresses up to 50 images at a time with the free version. You’ll have to keep clicking if you have more images to compress. It will also not compress images over 1MB, so to process all images and images over 1MB, you’ll have to upgrade to the paid version.

Fifth (and maybe it should have been first), under Settings > Media, you can set the sizes for Large, Small, and Thumbnail images when you upload them. WordPress will retain the original file, but also copy and store resized versions to select for posts/pages. While this does not “compress” the image, it does help with managing the sizes you want to set for your site.

Sixth, remember that PNG is for transparency. You might use PNG for a logo, a small icon, or some other small graphic that may have a special use case, like a drop shadow. Don’t use PNG for large photographic images. It adds data to the image and therefore increases the file size. If you have a photo, always used JPG. There’s no reason to use PNG for any photo.

Lastly, use a CDN (content delivery network) to speed up the delivery of images on your website. With plugins like W3 Total Cache or Super Cache, you can send your website’s image to servers around the globe for storage and retrieval at the “edge” of major cities, so that they are served quickly to your intended audience. If you’re using JetPack by Automattic, you can turn on Photon, which is powered by Automattic. Photo is the CDN employed by WordPress.com, so you can leverage Automattic resources to store your photos on servers around the world. The caveat here is that it most likely only store and serve images uploaded to your media library. If you have images in your theme’s folder, they may be ignored by whatever solution you use. You want to choose a theme that doesn’t store images in the theme folder, or they’ll just be forgotten. The’ll then show up on a Google Page Speed Insights report telling you they need to be compressed, but WP Smush only compresses images in your media library and not extraneous images in theme folders.

If you need additional custom image sizes, you can use a plugin like Simple Image Sizes to create additional settings for you to select when publishing posts/pages: https://wordpress.org/plugins/simple-image-sizes/

Note: The Featured Image above is set to 624 KB and 1800 × 916. That means, it will size for most large screens and will automatically resize in mobile responsive for smaller screens. Compression will help the image load quickly on mobile devices.

For the past three months, I’ve tried my best not to have a mini meltdown over the fact that a number of my domains in a WordPress multisite network using Cloudflare’s free Universal SSL would not serve up a green padlock over HTTPS. When I first heard Cloudflare was offering free Universal SSL, I was very excited to take advantage of it. For some reason, it just wouldn’t work and for months, I couldn’t figure out why.

Now that Google is using HTTPS as a (minor) ranking signal, I want to make sure all my domains are using SSL. But even after enabling Universal SSL on Cloudflare for each domain, the one’s using the new service were void of the green padlock that tells the world each domain in my little network could be trusted. After struggling with it a bit to no avail, I thought I’d better buy a three site SSL certificate from my preferred domain name seller, Namecheap.com, for three of my most important domains. A temporary fix for 3 domains in an 11 domain multisite network.

After WP Engine installed the Commodo certificate for me, all three sites were instantly padlocked after. Since the others were not as much of a priority, I continued to ignore no green padlocks on them, but it just kept on nagging at me they weren’t locked.

It’s in my nature to incessantly focus on problems until resolved. While others might not care as much as I do or they pass the buck to someone else, I always go to the end of the earth (despite my better judgment) to figure it out myself. I don’t know why I’m like this. It’s a blessing in some ways, because I actually get things done–no matter what. It’s a curse in others, because I do it all myself and am so focused that it can take hours and hours of painstaking work to figure out the solution. In that, I’ve let the world go by while I’m trying to solve a problem I should pay someone to solve for me. But, then I’d have to give them all the passwords and account access to both my network install, Cloudflare, and WP Engine. Without a clear path to resolution, who knows how many hours someone could take to figure it out. And, who knows if you’re even talking to the right person who can figure it out.

Night after night, I would go back through my Cloudflare install and make sure all domains were set to Flexible SSL. Then I’d dump my cache at Cloudflare and in my WordPress WP Engine network admin. I tried a various plugins to see if the URLs did would not redirect and cause a loop. Nothing worked.

I made sure to get the Cloudflare plugin to connect my multisite network to the service, but I was getting some errors and I needed to research how to make sure the Cloudflare plugin connected via their API to my account. I turned off my Cloudflare service for all the domains that had no green padlocks. Of course, the API wouldn’t connect if they were off. I turned them all back on and made sure they were all set to Flexible SSL again. Once I solved that, I thought: “Great! Problem solved. My padlocks should be green!”

Nope, that didn’t happen.

After some lengthy discussions with WP Engine support on this matter, I learned I was getting a lot of mixed content and insecure content warnings on some of my domains in the network. Why? Because somehow my URLs had gotten rewritten either in the original migration from Linode to WP Engine or by some process or plugin. I’ll never know how that happened. Two of my sites were missing all of their content and their URLs were rewritten incorrectly for posts and pages in the database as “netmix-co.netmix.co” instead of “primarydomain.com/sitename.

Tasked with figuring out the underlying problem, I went in and performed search and replace surgery on all my domains using phpMyAdmin. I was able to go into my posts and post meta tables for each site in the network and find the incorrect rewritten paths. I simply replaced the incorrect ones with the correct domain names of each site in the network. That solved a ton of insecure content warnings and brought back all my missing content while also fixing redirection issues.

Now that I’d solved a number of problems using search and replace, some were still lingering. My JavaScript console reported affiliate network URLs I was using from organizations like Shareasale were http, not https. Fortunately, Shareasale provides secure URLs, but other affiliate partners did not. I had to remove their banner codes until they update their URLs to https.

Having done all this, I was pretty confident I’d see the green padlocks, but when I checked whynopadlock.com, all the sites with Cloudflare Flexible SSL turned on were hard redirecting to http. I thought, “geez, now how do I solve this?”

Earlier that week, WP Engine had helped write some html post processing logic that is set in my multi-site’s WP Engine admin area. Could that be the culprit? I removed those rules to see if anything changed.

Nope, that didn’t work either.

In the middle of all of this, let’s throw in the fact that WP Engine had to move my web services to another IP address last week after their provider was hit with a DDOS attack. I was tasked with updating all 11 sites A Records in the network. I did and learned that one of my sites had no DNS records at all (Oy!), but was still resolving. Go figure.

I went back to WP Engine again to explain my dilemma again. Fortunately, I got in at 3 minutes to 9 pm Eastern time, just minutes before chat support closed up for the night. I gave one of WP Engine’s techs, Brian F., all the earlier detail. His head must have been spinning. But, he finally figured out that they had to manually force https on their end to enable the green padlock on all sites in my network.

Finally, it was over. After months of starts and stops and weeks of going back to it, getting distracted by family stuff and client work, I was able to sit down and go through everything once and for all. Problem solved.

While all the abovementioned things I did were important, Cloudflare did tell me in one response they were seeing WP Engine had the ability to do something on their end to fix this, but they didn’t say exactly what that was. With Universal SSL, WP Engine does not have to install a certificate. It’s a one-way call to WP Engine who do not have to confirm the request with an installed cert. What they didn’t say was that WP Engine has to manually force HTTPS. It wasn’t until Brian F. figured this out that the curse was finally over.

I did not use a Force HTTPS plugin, because I think WP Engine disallows a few of them. I don’t know that they would have worked anyway. I’m was happy to have WP Engine manually write that rule every for this instance and in the future. At any rate, the problem is resolved. On to the next issue.

I hope this helps someone not have to go through weeks of pain like I did to finally figure out that all WP Engine had to do was force HTTPS manually. That’s it. Problem solved.

For the past few weeks, I’ve been suffering from what is called “insecure” or “mixed content” issues on my WordPress multisite network, which I’m hosting over at WP Engine. The goal has been to use the new free Flexible SSL from CloudFlare on a number of sites in my multisite, but leaving three of those sites as Full a as designated in CloudFlare, because I purchased a 3-domain certificate from Commodo, through my domain name registrar, NameCheap.

Somehow, someway, something did a search and replace across my entire multisite and changed the domain from the origin domain to “netmix-co.netmix.co.” The network’s primary site is netmix.co, but I don’t use it for anything. After contacting WP Engine, they pointed out the issue with the URLs rewriting. I’m not sure if it was one of the insecure content plugins that are freely downloadable or JetPack’s Photon service, because not only was I in JavaScript console rewritten primary URLs for post content and images, I was also seeing URls from wp.com, which after turning off JetPack, those URLs disappeared – despite being served over https anyway.

It was a very strange situation, but after doing a search and replace on post and post meta in my databases, I was able to fix all my URLs and content. There was one more thing I didn’t know. An old plugin called Bad Behavior I used to use has an “http headers” table. There I found some of my domains in the multisite with a ton of incorrect URLs rewritten in the http headers table. I decided to fix those with a search and replace across all sites with the issue of rewritten URLs and that ended up clearing more JavaScript console errors.

While I’ve done all of this…I’m still not seeing my free, Flexible SSL locks on the site in the network that are SSL enabled at CloudFlare. I’m not sure if it’s going to take 24-hours to possibly resolve all those mixed content errors, which will finally unshackle me from a plain grey file looking icon up there in the URL bar of some sites in my network (not this one, as this one has a paid cert from Commodo).