hollywoodgrind

I have Nginx running the front end, and Apache running on the back end. I suspect Smush.it is only detecting the 127.0.0.1 address, rather than the routable IP address for the server itself. It seems there should be an additional check in the script.

Not sure why a caching plugin needs to have something like bad behavior added especially when it can block normal traffic.

I deleted all the plugins since I don’t use any of them.

Here’s the correct code which you can put in your functions.php file:

<?php
remove_action( 'wp_head', 'feed_links_extra', 3 ); // Display the links to the extra feeds such as category feeds
remove_action( 'wp_head', 'feed_links', 2 ); // Display the links to the general feeds: Post and Comment Feed
remove_action( 'wp_head', 'rsd_link' ); // Display the link to the Really Simple Discovery service endpoint, EditURI link
remove_action( 'wp_head', 'wlwmanifest_link' ); // Display the link to the Windows Live Writer manifest file.
remove_action( 'wp_head', 'index_rel_link' ); // index link
remove_action( 'wp_head', 'parent_post_rel_link', 10, 0 ); // prev link
remove_action( 'wp_head', 'start_post_rel_link', 10, 0 ); // start link
remove_action( 'wp_head', 'adjacent_posts_rel_link', 10, 0 ); // Display relational links for the posts adjacent to the current post.
remove_action( 'wp_head', 'wp_generator' ); // Display the XHTML generator that is generated on the wp_head hook, WP version
?>

https://www.nerdgrind.com

https://arie.putranto.com/blog/2009/03/avoiding-duplicate-title-tag-on-wordpress-post/

Instead of:

$wpmeurl = get_shortlink($post_id);

try:

$wpmeurl = get_shortlink(get_the_ID());

NerdGrind.com

There is a fix coming soon:

https://code.google.com/p/yourls/issues/detail?id=200

Some of us run our own short URL service using YOURLS. How about giving us the option to use our YOURLS short URL service rather than wp.me?

I forgot to mention, in a setup like mine where Apache is on the backend to run the WordPress PHP scripts, I believe the Nginx compatibility issue addressed by the plugin I linked to is not an issue unless php-fcgi is used to serve PHP scripts.

WP SC complies pages into html and html.gz files, so the web server can serve those pages faster with less load on the server. The fact that the web server is compressing the served html files with gzip means you have reduced the size of the pages being served to visitors. Using gzip means the page will be served faster, and this will save you some bandwidth, the file will still be uncompressed on the visitor’s computer.

The only way to really reduced the size of the homepage is to remove code that isn’t absolutely necessary, and to analyze the page with Yslow (which is a plugin for Firefox). Follow the recommendations in Yslow to help improve the speed of your web pages. I would not recommend using minify however, since it increases the CPU load, which WP SC reduces. In my experience, the additional resources used by minify doesn’t justify the additional cost of those resources. Some files, like the css, can be minified manually and then uploaded.

I use Apache as a backend to handle PHP, and Nginx as the frontend. In this configuration the Apache .htaccess files can be fully utilized. Would it help if I sent you my configuration?

On high traffic sites especially, Nginx will make life much easier. There’s just a slight learning curve in the beginning. I hope you will reconsider exploring Nginx further.

Yes there are times when the homepage does not display the fresh content. I set W3TC to cache pages for logged in users, which includes the Admin, so I can see what everyone else sees.

I didn’t see this mentioned, but in the w3-total-cache/ini directory you have a .htaccess file that could be appended to an existing file to help with non-w3tc caching. I found this very helpful. Perhaps this should be mentioned somewhere prominent so it isn’t missed. Very thoughtful work you have done with the .htaccess file.

I had the warning after upgrading to 2.8.5 below:

httpd: PHP Warning: gzinflate() [<a href='function.gzinflate'>function.gzinflate</a>]: data error in /var/www/blog/wp-includes/http.php on line 1787

The gzinflate indicates a compression problem with a core WordPress file, or at least line 1787 of that file, which I had to comment out so it would stop filling my log file with errors.

So I started to suspect that perhaps Minify in W3TC was not the problem. I went back and enable Minify for HTML, JavaScript, and CSS. I then disabled:

HTTP compression (gzip / deflate)
and
HTTP compression for MSIE6

With those two compression settings enabled I kept getting this message in my error log:
PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/blog/wp-content/plugins/w3-total-cache/lib/Minify/Minify/HTML.php on line 119

With the compression settings disabled on the Minify tab the errors disappeared.

I’ve isolated the problem to the minify scripts you included in W3TC, as you can see in the error. Here’s what I did to fix the problem.

1. Disabled Minify in W3TC
2. Installed the WP Minify plugin
3. All the errors stopped, and I have my site minified

WP Minify uses the Minify engine as I believe W3TC does as well. I compared line 119 from the HTML.php file from W3TC to the Minify engine file, and found they are identical, however the HTML.php from both the Minify engine and W3TC differed from the code in WP Minify.

The Minify Engine and W3TC HMTL.php file contains (lines 115-119):

// replace TEXTAREAs with placeholders
        $this->_html = preg_replace_callback(
            '/\\s*(<textarea\\b[^>]*?>[\\s\\S]*?<\\/textarea>)\\s*/i'
            ,array($this, '_removeTextareaCB')
            ,$this->_html);

The WP Minify HTML.php contains (lines 89-93):

// replace TEXTAREAs with placeholders
        $html = preg_replace_callback(
            '/\\s*(<textarea\\b[^>]*?>[\\s\\S]*?<\\/textarea>)\\s*/i'
            ,array(self::$className, '_removeTaCB')
            , $html);

The only disadvantage to using WP Minify is that it serves the compressed .css and .js files from the hard disk, rather than memcached, but Apache compresses them with gzip as well, so there’s no resource use impact that is noticeable.

I may have asked this question prematurely.

I was logged in as the admin when viewing the page. When I logged out I saw some of the queries cached. Are the database queries only cached for non-logged in users?

For anyone who gets the FTP settings page, but cannot goes past it to do a plugin or WordPress upgrade, the link below may provide a solution. It solved my issue. The article will also help to set proper permissions on the files and directories.

https://www.nerdgrind.com/wordpress-automatic-upgrade-plugin-failed-or-not-working/