sadhaka

But in W3TC’s “install” page, the server path that is specified in bold under “Rewrite rules” points to the root directory, not to the subdirectory.

I thought this was a reflection of the fact that in the WordPress “General Settings” my “WordPress Address (URL)” is set to the subdirectory (the “Site Address (URL)” being set to the domain root).

Minify works (I can see that in the source) and browser caching works – it’s only the expires headers thing that doesn’t. How come they work if the .htaccess file is in the wrong place?

Confused.

@mbrsolution Thank you – I must confess I don’t understand the rationale for having two .htaccess files which both do the same job, but I don’t know enough about it to judge, and perhaps indeed you are right.

But does this mean that both .htaccess files (the one in the site root and the other in the WordPress subdirectory) should contain the rewrite rules specified at the bottom of the “Install” section, as mentioned above (at least, the first block of code shown there that refers to the placing at site root)? That is, should they be identical?

Many thanks.

@mbrsolution – I took a look at that post, and from what I can understand, the gist of it was to check that the rewrite rules specified at the bottom of the “Install” section are indeed written to my .htaccess file, and they are.

My WP installation is (like many others), installed into a sub-folder from the site root. But the .htaccess at the site root contains all the code specified in the “Install” section.

I don’t have another .htaccess file in the WP sub-folder. Should I have?

So anyway, if I understand the main message of that post correctly, its recommendations don’t apply to my installation, and YSlow still gives me an ‘F’ for “Add expires headers”, complaining that “There are 36 static components without a far-future expiration date”, as before.

@mbrsolution – Hi – most are related to my site – theme images, uploaded images for posts (many of these), but also some plugin css files; social widget files; even some minified w3tc files. It looks to me like everything really.

Well, it is a little disconcerting that Fredrick is the only person in the WordPress universe that seems able to offer any advice about this.

Does no-one apart from this author guru have *any* clue about this?

By the look of the support page, emails with questions are charged for. (Last resort, I’m afraid.)

Does anyone know whether W3TC is supposed to have this “expires headers” covered? I get the impression it should, but Page Speed and YSlow consistently complain about many “static components without a far-future expiration date”.

If I have this wrong and W3TC isn’t even supposed to enable this, or if it is and I therefore have a problem I’d love someone to explain it to me.

The page coconuts still aren’t showing.

LOL oh dear !

OK, thanks. Panic over. (PS “to grab page whats” ?)

I find this plugin conflicts with my footer as well.

The sidebar is NOT longer than the main content.

I tried adding position:relative to all the footer wrappers or containers I could, one by one, but that made no difference.

The plugin works, but it reliably wrecks footers.

Perhaps the extra injected css doesn’t work when the button is created by the shortcodes? Where my button is created by the shortcodes, I see the div element as:

pin-it-btn-wrapper-shortcode

I know you can add css to the shortcodes, like:

float="right"

… but how to center doesn’t seem as intuitive.

That had no effect at all.

Could you clarify this please Phil? Does the “non-iframe” version (in the free version) somehow overcome this problem with W3TC? Is that just the way it works now, or do I have to configure the Pinterest plugin and/or W3TC somehow ?

Doesn’t work with featured images with me either, and these are the images that one would most want visitors to pin.

+1. How do people know to hover? And as AMGill says, iPad viewers can’t.