Roll back to prior version temporarily?

Also note Visual Composer (VC) and TD Composer (TDC) are two different things, if using TDC, not all the VC blocks are there and you’ll need to redo any layouts done with VC.

( I don’t work here; just some feedback. )

We’re also using the TD Composer in place of Visual Composer; limit loading external elements; moved to web-safe fonts vs Google Fonts, disabled comments, etc., minified the main style css file and main js file.

I am using the ‘scripts to footer’ plugin in place of Speedbooster; and then put critical above the fold CSS inline in the head.

I cover some of this in my long winded thread (second link above).

Totally doable; there is just a “tweaking” needed with any complex theme.

You need to optimize your site, theme can’t do that for you.

Did you read the documentation and re-render your images to fit the new layouts/modules? Are you using an optimization plugin for images, or re-rendering after setting lower compression in your wp-config file?

I don’t work here. But I have 90+ on my sites with no caching plugin.
https://forum.tagdiv.com/how-to-make-the-site-faster/

https://forum.tagdiv.com/topic/tutorial-chriss-custom-optimizations-for-functions-php-etc/

https://forum.tagdiv.com/topic/score-100100-pagespeed-with-newspaper-wordpress-theme/

JetPack is hosted by WordPress; it’s not part of the theme; so issues with JetPack are not related to the theme, or any theme. It’s slow and a resource hog, and generally best to be avoided unless you have no choice.

Good luck!

Good ideas for basic security:
a) do not use admin as the superuser login name; always make second name; don’t use the superuser admin name to build pages as it reveals that ‘user’ to hackers;
>> ‘superuser’ for site admin
>> ‘othername’ for content building as admin; not superuser level
b) use plugins like ‘limit login attempts’
c) disable xmlrpc – known attack vector; disable editing of WP files from the WP admin
d) force https
e) force strong passwords (not ‘bunny72’ but ‘8g932vygSD97j$’); disable password reset functions
f) remove all old-unused plugins, themes no longer used – nulled code can still be used by hackers
g) scan site regularly with securi free scanner
h) make sure using good host running modern versions of bind, mysql, php, etc. — make sure running php 5.6 and up as older versions are ‘end of life’
i) make sure running WP 4.8 and up
j) make sure web host running IPtables and automatic Ip blocking for hack attempts
k) fully implement suggestions from the WordPress documentation (always good to learn to use WP by reading the manual …. I know! Crazy, right?): https://codex.wordpress.org/Hardening_WordPress
l) make regular backups (ironically, I am doing that ‘right now’ on my machine while having first cup of coffee …)

After hack; change all passwords (hosting, FTP, and WP); delete WP, all plugins, themes, check for malicious code in htaccess, random weird php files; reinstall everything for clean copies.

You can certainly export the dbase via your hosting panel.

(I don’t work here.)

I use WP-optimize every day.

Simply add your custom CSS to bottom of the style.css ….

note custom styles must be loaded ‘after’ the main CSS, so that’s why they are added to the head after main CSS loads. That is “best” way to do it.

We had major CPU issues on our old system with Visual Composer, and found the TD Composer solution the best fit for us (we were using old ‘shim’ solution originally). We’d get spikes going from .9 to 72 !~ …

Several things
a) make sure you have PHP 5.6 or higher. 5.4 and below are *dogs* and should no longer be used for WordPress. PERIOD.
b) doubly make sure you have at least 64M allocated to WP in both your host settings and in your wp-config.php file (we do 128M and above, but another story)
c) make sure you periodically optimize your DB with WP-Optimize of similar
d) limit queries “per page” — for example, no more than 5 “block items” per page

Might help.

Chris

Best to install via FTP, as always as some server systems time out when trying to install stuff via the WordPress installer.

Probably issue with your CDN and WP Super Cache setup.

Might not help but resave permalinks to reset htaccess, delete transients wth wp-optimize… i use this combo to clear stuck stuff and changes to custom rss etc.

Theme comes with bundled version of Visual Composer as advertised. Why you so whiny on mars with warbling cats? You dont have to buy it to use it. See the documentation from the forum links before dirty dicks scream in pothandle barbeques!

…I DONT WORK HERE OR DRINK BEER ON DEERS ON PIERS!

Probably need to look up how to hack WordPress for that or Cloudflare support.

Proper URl would be img src="https://example.com/image.jpg"

You’d need to search/replace your content in PHPmyAdmin to replace old instances of http to https for your images placed inside of post meta (lots of tutorials online for moving to https from http in WordPress).

Once you change your base site URL to https in WP, the theme picks up from that for any new posts (you would need to manually change any logo head/footer/favicon stuff in theme panel, obviously).

I don’t work here; but we moved to https everywhere in 2014, 2015 and 2016 for all our sites, so went through the same thing.

Um, yeah. Test one of your pages with the image sizes not at ‘actual size’ with Google’s testing tools? Have you tested your site with PageSpeed or their mobile testing tool? Sites which don’t do well in mobile testing won’t be shown to mobile users!

e.g.,
https://search.google.com/test/mobile-friendly

Meaning there is more overhead for browser to resize images multiple times to multiple sizes vs caching the actual images at actual sizes.

However if it works for you, and you’re passing Google’s PageSpeed test and mobile test doing it your way, go for it — just not “normal” practice in modern webdev (I’ve been doing it since 1995 professionally, as a point of reference).

Well, if you don’t want to use the Custom Code option in the theme admin panel, the only way to do that is either with a plugin (from wordpress.org repo, or one you make your self, since these survive theme updates), or manually editing the theme files, such as header.php or adding a function hook into the enqueue at bottom of your functions.php file.

I don’t work here, just a suggestion.

• This reply was modified 9 years by simchris.

Well, it’s really bad to use one thumb for all size images from pagespeed/seo point.

Meaning, if you only have 500px image, and then try to have theme resize to fit 200×300 thumb, it will either be distorted or oddly cropped.

You cannot load a 200×300 thumb without there actually being a 200×300 thumb image.

Google will penalize you for only having one image resized to different sizes (try it).

Heh. I said the same thing as a ‘dinosaur’ around here. I guess they didn’t think it added anything and also used up a lot of queries for kind of a vanity element. ?

Not a bug. Idea is that if somebody using different counter plugin, not counting twice, or adding additional view data field.

Often you can leave the option ‘on’ but then edit the theme template being used to remove the element you don’t want to see ‘on page.’

Remember most options in theme are for folks not used to doing custom programming, and so with many, they don’t have any prior view counter.

For folks more experienced, with existing counter, they would continue to use that plugin, or hack the theme setting to change to the existing data field, then disable the plugin previously used, as another option.

No ‘one size fits all’ options — so TD chose to do simplest most likely thing of people who want to track/show ‘hits.’ And of course, many opt to use something like Google Analytics instead, or server-side reporting platforms.

I don’t work here. Just food for thought. 🙂

Couple of ways.
Some hooks in the theme panel; or typically make a plugin which added the function via enqueue to the WP header.

Generally in the footer.php file. Just make sure you clear cache so it’s actually there. Do a view source on your post page to see if the javascript is actually there.

Also note PHP 5.3 is very very old also, and new version of WP is not optimized to work with it.
https://wordpress.org/about/requirements/

From WP 4.8 onward, it’s optimized for PHP 7, but 5.6.30 would be *highly* recommended if you are running latest WP and cannot start migration to PHP7.

We use PHP 5.6.30 with opcache which is the closest you can get to PHP 7 without actually using it, but retain some backward compatibility while migrating, and planning to move fully to PHP 7 for 2018.

Seriously — 5.3 is ancient, 5.4 is a dog. 5.6 and above is the only thing you *should* be using with WP 4.8 and higher.

You can get up to 30% improvement in PHP speed, and stop those bizarro old CPU spikes from 5.2./5.3 era.

Here are some interesting benchmarks from way back in 2014; and 5.6 has improved since then since some of the work on v7 is backported to 5.6 for security/compatibility:
https://lornajane.net/posts/2014/php-5-6-benchmarks

(( I don’t work here; but we did big PHP upgrade last Sept., and *wow* what a difference. ))

• This reply was modified 9 years by simchris.

Generally the reason most savvy WP developers recommend WP Super Cache is that’s it’s made by the same folks who make WordPress and used on some of the largest websites like TIME.com, etc.

So, while there are other choices (we don’t use a caching plugin, since we have dedicated server, and prefer using optimized pages, with PHP 5.6 with MariaDB and opcache. And now moving to PHP7 + http/2.

So, it makes sense for TagDiv to recommend the same caching solution actually used by WordPress for their own sites, million dollar clients, etc. as it will *always* work with any proper WP setup, while other plugins don’t stay up to date, may not work, get abandoned, etc.

It’s your site, so you can do whatever you wish — however, it’s impossible for a theme dev to provide support for 10 different cache plugins, where caching has nothing directly to do with the theme itself. So, TagDiv use it for their own sites/demos, as does WordPress.

Just a comment as to the why (( I don’t work here …. ))

REF
https://wordpress.org/plugins/wp-super-cache/

🙂
yeah, I have to remember where stuff is sometimes. Luckily most of it you can “set once” then never again!

What we ended up doing was taking one of the other templates and modifying it to not have featured image, then made that the default, as I prefer the headline version crossing both columns.

If you use a template where featured image is inserted, then don’t insert image a second time.

If your existing posts have image inserted, make ‘default’ template for posts the one without image; then for future posts use template each time which has the featured image. That’s what I did.

Most modern WP themes use the ‘featured’ image to create the custom usage such as full width, background, top of post, or parallax, etc.

We had 10 year old sites with all images inserted manually at top of post, so had same issue.

TRY
a) set default post template to ‘template with no image’ (I forget which one that is … I think it’s ‘style 7’ from theme panel
b) then for new posts, you can manually choose which template you want, per post