Note that the Google verification thing sometimes works, sometimes doesn’t. Much like trying to sign up for their site search – went to a not found page for a month (!). It’s not always YOU, but THEM.

Wow. 7 seconds is a lifetime ! It might be due to running a proxy? A lot of folks running nginx (we’re running Apache, and then nginx for SOME things not all) seem to run through a proxy, and that might cause the issue. Perhaps check amount of memory allocated to PHP ? I think mine is set to 512MB, with 256M being typically the best lower limit for WP these days. I think you already checked that.

If you can see a noticeable slowdown running that just from the server, two things you might try is a traceroute between the API IP and your DNS, and/or check with your hosting provider to explain the issue. It might be something they have run across before.

Or it could be some weirdo voodoo thing like why my stupid Font Awesome 4 CSS don’t load consistently off Amazon’s CDN, or from the free CDN that also hosts bootstrap. Gave up on that one 🙂

see issues so far
https://forum.tagdiv.com/topic/wordpress-3-9-released/

I’m going to guess that there will be minor update to the theme next week, mainly to update the Visual Composer compatibility with WP 3.9

HOWEVER: you should always update WP and BuddyPress together, as BP updates may be built upon fixes for latest edition of WP. See the BuddyPress “changelog” to see what they added to update — if it says “updated for WP 3.9 changes,” pretty obvious you should upgrade to WP 3.9 for BuddyPress.

(AND BACKUP YOUR SITE BEFORE DOING MAJOR UPDATES!)

• This reply was modified 12 years by simchris.
• This reply was modified 12 years by simchris.
• This reply was modified 12 years by simchris.

Likely issue with the cloud.
I’ve had a ton of issues with selected things on my Amazon CDN, where 20% of the time the custom font (FontAwesome) won’t load properly. Finally gave up and we load FA4 off our own server. Doubtful it’s the theme. More likely in IE11/Win7, than anything else.

Might be the “lazy load” images code. I know we had issue with lazy loading images for “as page loads” and had to change to “after page loads.” But that’s outside my ability to help you on, as I think there is some optimization code in the TagDiv Booster which does some image lazy loading. But just some feedback, might not be helpful.

You might try accessing the admin panel in http://yoursite and https://yoursite – as those are different ports. If your site runs in https, then accessing the admin in http might not work correctly.

Still, I’ve not seen this issue before. It may be firewall setting on your PC.

Obviously 8880 and 8443 should be open, and port 80 might be needed, possibly 443. However these should already be functional.

FYI, standard ports are often these:
#20 ftp-data
#21 ftp
#22 ssh
#25 smtp
#53 dns (TCP and UDP)
#80 http (web server and Plesk updater)
#106 poppassd (for localhost only)
#110 pop3
#113 auth
#143 imap
#443 https
#465 smtps
#587 mail message submission
#990 ftps
#993 imaps
#995 pop3s
#3306 mysql
#5224 (outgoing connections only) plesk-license-update
#5432 postgres
#8443 plesk-https
#8880 plesk-http
#9080 tomcat

Sorry I don’t have a better answer. You may wish to utilize a process viewer or port monitor to determine WHICH ports are supposedly trying to be accessed on your PC and what are not able to connect on your network. If you’re hosting your own domains at the University, checking the error logs for your site are also a good starting point.

You should be able to modify the blockquote to look however you wish, using CSS, as we did.

E.g.,

blockquote p {
   font-size:20px !important;  line-height:26px !important;
  text-align: left !important; padding-left:20px;
}

Chrome and Firefox use different rendering engines, I believe. Further, Chrome (Google) is now pre-caching images on their network, for mobile in particular, so that next visitor gets image more quickly. This may or may not be what you’re seeing. But, web browsers from different companies may show images in different ways, just as they do with fonts, etc.

As we say in Calif. … OMG!!!!! 🙂

My personal thinking is that if sharedcount is going out and grabbing the data for you, and then you’re grabbing data from them, it seems to be an obvious slowdown.

Since you’re using the (apparently) ‘free/unauthenticated API’ you not only have to contend with the 10,000 queries limit, but are also in the pool with all other free users, and obviously this is a slowdown someplace, perhaps it’s fetching the graphic before service code which would introduce delay for it to fetch that and serve back to you; dunno.

You might pay for one month trial on their upgraded “PLUS” plan to get the better connection?

I’d likely do a split test among services
1) theme built-in features
2) what you’re using now
3) AddThis Sharing (or ShareThis if you prefer)

Run speed tests with GTMetrix or something and measure the speed FROM THAT API compared to speed of other methods, and go with what is faster.

Marius/Radu may have better answer. 🙂

• This reply was modified 12 years by simchris.

You should be able to modify the blockquote to look however you wish, using CSS, as we did.

E.g.,

blockquote p {
   font-size:20px !important;  line-height:26px !important;
  text-align: left !important; padding-left:20px;
}

• This reply was modified 12 years by simchris.

Hi, it’s likely nothing to do with the port as we run in “ultra secure” mode here while watching external IPs try to ping our PCs from Eastern Europe — basically, if you can edit something in the WordPress panel itself like adding a user then you are not on the wrong port like 80 vs 443 or whatever —

. . . but it *might* be from using Internet Explorer (IE10,IE11), which has some issues with Ajax and some other oddities (like pasting in from MS Word never works in IE, works great in Chrome). If you can, try using Chrome (or Firefox, or Safari on Mac) and see if that works.

If this just started with WP 3.9 the other day, in all your web browsers, there may be forthcoming “fix.”

• This reply was modified 12 years by simchris.

+1 I was going to ask about this, a “style 7” for header, such as

[ top menu + socials ]
[ full width ad ]
[ full width logo ]
[ main menu ]

and a “style 8”
[ top menu + socials ]
[ full width logo ]
[ main menu ]
[ full width ad ]

An example of that could be found on one of our older sites, not YET moved over to Newspapers (hold up is me messing with solution for enlarging images for the featured images layout):
http://californianewswire.com/2014/04/18/CNW19293_062237.php/los-angeles-music-networks-2014-rock-and-urban-lamn-jam-music-contests-welcome-sponsor-send2press-news-service/

Also good idea if having any issues with widgets to simply go to each and press “save” again. I tend to do this out of paranoia with each new full dot WP update:

1) resave permalinks (habit as it resets/touches the htaccess file which as the rewrite rules)

2) disable and re-enable plugins one by one; check for any error message on re-enable.

3) run wp-optimize plugin which cleans house on orphan meta, etc.

4) do tools > save all site data (if not already done); good to do before AND after any update especially if “database has been updated” happens with the upgrade.

5) once a month I do full FTP download of site in case server catches fire and datacenter hit by lightning and backups melt.

6) Check site in IE11/Win7-64 and Chrome/Win7-64. (Generally if it works in Chrome on Windows then Chrome, Safari and Firefox on Mac will work – and who cares about anybody still running IE on Mac!)

7) If needed for anything like missing widgets, go to appearance and just hit “save” and it resets it. For missing ads, simply hit “save” in the theme panel for each ad spot.

8) Finally, out of general paranoia I also look at the source of a sample post, to make sure the meta tags are not messed up due to the occasional whack-a-doodle bug in Yoast, and because we’re running mod_pagespeed and like to check things are not being re-written in some bad way.

Veteran WP users have their own checklist, but this may be useful to the newbies. 🙂

Hi, nusagrunge
Non tagDIV team member and Junior Buckaroo Banzai regional team leader checking in!

This is a famous WordPress issue. We solved this a long time ago by simply putting something like this at bottom of each POST:

Article is © 2014 by Jane Smith and originally published on MyCoolSiteName.

This ensures the author’s NAME is actually in the post, but also helps with legal issues from content scraper bots who might capture post. Also helps with “print page” stuff as well as folks using the “read” function on iPad or iPhone to see only post text and nothing else.

This is nothing to do with the theme. If you ‘google’ this problem, there were some plugins prior to 3.2 that seemed to work, but no more that I know of.

Some people take the approach of using Google’s search engine for the site search in place of the WP search function. This would find all mentions of each author (in theory). There is a process to swap out local search for Google Search, and might be worth a try if you are playing with a brand new site.

Anything that connects to multiple external systems and has to get a response will slow down the site; everything like recaptcha, jetpack, adsense, social plugins which “go out an get data and then bring it back to cache” and similar — all slow things down since it’s not happening “locally.” (As I’m sure you already know.) You would likely disable the theme’s function to “count” reads/shares from other sites, and try using something like AddThis which can also do this for you. Ironically, the reason the calls to the APIs in the functions.php is done to avoid having to use external plugins and for most of us makes site run faster than using external plugs. But every site is different, and part of the development process is picking/choosing how to add/adjust things on page for best user experience and performance.

Note also that WP-Postview was updated this week to address issues folks were having with Ajax and Cache, so might be worth revisiting that setup with new version.

Not sure if that helped at all, but my two cents.

Hm. Weird. On my two sites the “responsive” AdSense units are auto-centered in the sidebar on every page. See test site: http://ga-ga.com/ … and I didn’t put in any special code to center it. Note things will NOT auto-center when resizing the page, in some cases.

For best results may sure you choose the responsive / experimental ad units from your AdSense accounts and not the static pre-sized units.

Without seeing the page and the possible code conflict from another plugin you might be using, it’s hard to tell. Marius will ask for a link to your site to look at it.

It *should* center automatically.

On my sites, the ad in top bar, below article, and sidebar already “auto center” using the “responsive” AdSense code from Google.

I think Marius needs to know an example (a case) where you are having the ads NOT centered, such as a custom block of text, or what exactly. A link to page, post, or where you’re using the AdSense code on your site and if you’re manually putting into your template or using the Newspaper theme admin panel “AD” boxes to insert the code.

NOTE:
update to WP-Postview for those using with cache:

Version 1.67
•NEW: Allow user to not use AJAX to update the views even though WP_CACHE is true

Yoast doesn’t “auto post” to G+.

Yeah. Went through this last month, and in December. Doing them by hand right now. Testing SNAP “PRO” with API pack. First test worked, so good start. Your mileage may vary. I know! Another plugin, dammit!!! 🙂

• This reply was modified 12 years by simchris.

Not easily. Used to be a hack using SMS. But Google has been slavishly trying to block most methods to auto-post to G+. The “SNAP” plugin can do it, for a price, which is what we’re moving toward using.

Going to test thumbnail upscale this week, was waiting on WP 3.9 to come out to see what they are doing with new image management features 🙂

I think you can try

<div class="text-center">

on the div(s) where the code is being inserted in the template(s) …
which is the bootstrap 3 style class (may already be in the style.css, not sure).

You can’t “style” the elements inside the AdSense iframe/text/graphic on the site. You *can* center the location it is placed inside of a div.

If you’re not using an image optimizer for all the thumbs, like smushit or whatever; consider adding the “quality factor” setting to your functions.php (see my notes in the pagespeed sticky thread) – otherwise you’ll see the smaller sizes being crazy big like 60kb for featured category image, etc.

So far it seems the 745×483 is best size.

Create new blank image in Photoshop that size. Put couple of grid lines about 50px from tope and bottom just for quick reference.

Resize image to the 700 width of posts and featured.

Crop from middle to the height. See where grids end up.

Anyway that’s what I did.