If you get this error, your PHP web server is lacking support for the function: mb_detect_encoding.

Ask them to enable it.

Upload via FTP. Unzip on your PC, then upload folder – (when you unzip on your PC you can *see* what’s there BEFORE uploading!).

Remember to delete old folder; upload new one (don’t mix old/new theme folder).

Do fresh install; delete old folders, re-upload theme and plugin; resave permalinks, etc.

Double check your htaccess file is updated and removed any old caching or path setups. (Try resaving permalinks first.)

403 is a forbidden error. Means either the item isn’t there, or can only be served from same origin, or other issue.

You should first ensure you properly migrated to https before doing anything. Many tutorials online including how you would need to setup a default redirect for all queries from http to https version, redo any of your image and favicon settings in theme panel, search/replace your post meta dbase via phpMyAdmin/MySQL (or plugin that can search/replace dbase), for all instances of http => https for your domain name, and also perhaps explicitly put the https url for your site in wp-config.php.

Theme has no control over any of that.

You can check your error log also to see what errors you’re getting to help track down what you’ve not setup properly in your paths.

Basically a 403 error means something isn’t found, or trying to be loaded from someplace it shouldn’t (google ‘403 server error’).

Default ads are placeholders; once you remove and put in your own ads they cannot “come back automagically” — if still showing in a browser, then it’s a site cache or browser cache issue. If using caching plugin try clearing it then *disabling* it to test.

This almost always means you’re uploading the ‘all files’ zip vs the theme zip which *does* have the style sheet in there (unzip it to see!). 🙂

Answer is actually very simple.

Images which don’t live ‘inside’ the post box (post meta) won’t show up in the RSS feed unless you make a custom feed template.

So, if your only image is outside the actual post, such as a giant size full width image or slider, that is not actually *in* the post itself.

You can test this by looking at your actual RSS feed, and see which have images and which don’t. This is why on some sites we use the theme template with *no* featured image and place our images in the story manually after first paragraph.

We ran into this on a couple of sites and solution was to make a custom RSS template, with a function to strip out all images in the feed, but then insert the featured image at top of the content. This way we always had ONE image in feed, featured image, and it was above the content in the feeds for posts.

There are many feed plugins available in the WordPress.org plugin repository (or ‘repo’) which allow you to customize or control your feeds if you don’t want to learn how to ‘hack’ a custom feed for your site.

If you ONLY use featured image templates (where the featured image is outside the post meta box) — you can likely add a function to functions.php to “insert” the featured image at start of the RSS feed ‘item’ but you’d likely need to find a tutorial online, or use a RSS feed plugin manager for that.

Hope that helped! And, welcome to WordPress! 🙂

Did you sync all your images to the Cdn per their instructions? Theme does not control your cdn.

Depending on your hosting platform, you may need to change this from your hosting control panel to make the change work.

Many things in WordPress, which requires PHP, need to have the PHP mbstring extension activated; ask your web hosting provider to activate this for php on your account if you continue to get that error.

Also worth noting, when ‘cleaning’ your site, you need to *check* all editable fields in your theme setup; this means logo, favicon, widgets, footer, custom code blocks for javascript, ad boxes, etc. — anything managed by java, or related to java, should be checked!

updated article from SECURI:
https://blog.sucuri.net/2017/09/old-themes-abandoned-scripts-pitfalls-cleaning-serialized-data.html

e.g.,

AddType image/webp .webp
AddType application/woff2 .woff2

<IfModule mod_expires.c>
ExpiresActive On
# ExpiresDefault "access plus 1 month"

</IfModule>

You may want to ensure you’ve add the mime type to your system, added an expiration header for caching, etc.

Do you have expiration headers added to your htaccess for .woff — did you add filetype handlers for .woff and .woff2 if your server not already setup for those?

If using a caching plugin make sure it understands a .woff font for caching.

It’s basically a ‘slimmed’ version of FontAwesome, so really works same way.

Basically, the answer was that most sites are using Google fonts, and it’s advertised as such to create a custom site with unique design. To *not* use Google fonts at all, unfortunately, at this time, you would need to modify the code yourself (as I did), or hire somebody to do that.

Bogdan is not rude, he is just short and to the point. “we cannot include everything” is the answer — wasn’t rude at all. Not everybody needs the same things — “most” people want the flexibility of custom fonts or system fonts (e.g., using the built in font stacks like Georgia, blah blah….

The system font stack used by WordPress currently is a good option, but even that is getting updated once Safari 11 supports the ‘system ui’ font properly everywhere.

Anyway — I wrote a how-to on moving to a system font stack, as I said — but you would need to do this yourself, or hire somebody to do it. Theme doesn’t support a ‘system ui’ font stack out of the box, at this time.

Not enough people have requested that to put it on the dev map.

( I don’t work here; just using the theme for 3+ years )

Note the business hours top right.

I think it’s on the ‘meta’ setting for modules

usually i do that from the modules thumbs setting where it shows all the sizes to turn them on/off.

I doubt much support will be added to *any* theme until next year while the specs continue to roll out, people continue to move to https (required on many servers browsers for http/2), and for hosts to fully embrace.

Future is https + php7 + http/2

You don’t need to add preload to the pieces of any theme for http/2 to work, it merely identifees the most critical thing to load sequentially for certain things.

Some more on this topic for those not living the webdev bleeding edge ….
https://medium.com/reloading/a-link-rel-preload-analysis-from-the-chrome-data-saver-team-5edf54b08715

Likely, anybody wanting to implement this would need to add a function to modify the initial/primary script and then test the crap out of it like many are now doing …

I can’t speak for TagDiv — but going to comment this type of support is a little ways off. For example, why wouldn’t it be part of WP core in how scripts are actually “enqueued” via the normal WP hook? Why hack core to modify how scripts get loaded, if loaded via normal enqueue.

Ideally it should be part of core as toggle in wp-config, but not sure what happened with that topic elsewhere.

Anyway — just putting my ‘dinosaur comments’ on this since we’re now playing with this on our dedicated Plesk/ONYX server.

Usually you can add that to your footer.php file, or through a custom function hook, or plugin to add content to footer.

You don’t need a plugin for SSL.

You need
a) SSL/TLS certificate on your web host
b) you need to have your host panel setting for domain setup to 301 redirect all https queries to https
c) you need to search/replace your post meta in phpmyadmin for instances of http/yoursite and replace with https/yoursite
d) you need to make sure any items in theme panel like logo are https links
e) you need to add explicit https URL to your wp-config.php file (see wordpress codex on how to edit wp-config); and add the https admin required line.
f) ideally you should have an htaccess entry to redirect all http queries to https, if your hosting panel doesn’t yet have that option

That is *correct* way to move your site to https — plenty of tutorials online.

Likely a flaw in the membership plugin you’re using that is setting IP based cookies, vs session cookies. So, anybody coming in on a shared IP gets access. That is only a guess, of course.

Theme has nothing to do with the membership plugin, obviously.

Likely want to check the support forum and page for the plugin you’re using, to see what others have reported as issues/flaws, etc.

( I don’t work here. )

Disable minification of javascript as start.

Log out of your site, dont just close browser.

Try making new page vs editing old one.

See last sections here on how to ‘clean up’ your site if it’s already compromised with old version of theme/WordPress:
https://forum.tagdiv.com/topic/tutorial-good-basic-security-practices/