How do I prevent the server caching css using .htaccess? I have tried the following
# enable expirations
ExpiresActive On
# expire GIF images after a month in the client's cache
ExpiresByType style/css 1
Recommended by freenode users (#httpd).
However this made my server 500.
What did they do wrong?
I don't know why that made your server 500, but this is what my .htaccess files have looked like, and it's been working fine for me. Based off of this .htaccess file (section starting at line 668).
<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 1 month"
ExpiresByType text/css "access plus 0 seconds"
...
</IfModule>
You maybe will want to change this if/when the site goes into production.
Alternatively, I've gotten into the habit of versioning my css files, as such:
<link rel="stylesheet" type="text/css" href="http://path/style.css?v=0.03" />
Changing the 'version number' will force a reload. If you care to, you can automate this versioning process with PHP.
Related
On Wordpress, I would like to set the browser cache expiration on the “index.html” homepage to “0“.
And the rest of the html files in 1 week.
I tried to do it via htaccess using the code below
<IfModule mod_expires.c>
# Enable expirations
ExpiresActive On
# Default directive
ExpiresDefault "access plus 1 month"
ExpiresByType text/html "access plus 1 week"
<FilesMatch "^(index\.html)$">
ExpiresActive On
ExpiresByType text/html "access plus 0 seconds"
Header append Cache-Control "public"
</FilesMatch>
</IfModule>
But only a week’s setup works:
ExpiresByType text/html "access plus 1 week"
This setting inside “FilesMatch” is completely ignored.
ExpiresByType text/html "access plus 0 seconds"
However, when I try to disable the caching of the styles.css file instead of index.html, the code works.
It seems to be something related to the html type when it is inside “FilesMatch”
Can anyone help me with this, please?
WordPress doesn't use index.html. It uses index.php You can change your match like this:
<FilesMatch "^(index\.[a-z0-9]+)?$">
[a-z0-9]+)? matches any extension on the index file
Adding the ? makes the index file optional so that the rule might match the home page when the index file is implied rather than present in the URL.
if you are using WPRocket plugin for cache handling then it provide option to set value in particular page also
I am trying to manually migrate a Wordpress site via FTP to an AWS EC2 instance that runs an Ubuntu 20.04. Due to certain circumstances I cannot use plugins to do the migration. I basically copied the files of the site to the /var/www/my_site folder, and dumped its old database into a new one that I have access to, while setting up Apache2 as a web server.
And even though I tried almost every angle I could think of, the site does not run. Apache2 is able to run some of the initial files, including wp-config.php, but it fails somewhere along the line, and in the wp-blog-header.php file the wp() function fails when it gets called, or it doesn't even gets called.
When running in a browser, the HTTP request 301 redirects to a HTTPS request and it fails premanently. However, there is no indication in the code that a 301 redirect is set anywhere.
The odd things are that with basically the same configuration I am able to run a simple Wordpress installation on the EC2 instance, and the site I am migrating runs on my local Windows 10 environment with XAMPP. On the EC2 instance the site also fails with NginX.
The things I thought that might be variables in configuration are the following:
File and directory ownership
The owner of everything in the web root directory is www-data, and changing permissions of files and directories doesn't change the result, I have tried every variation.
Modules
Modules that are not enabled by default in Apache2 and needed by Wordpress are enabled, like php7.4, rewrite, expire and header.
Apache2 Virtualhost configuration
I took out ServerName and ServerAlias, because right now I am only trying to access the site throught the EC2 instance's IP address. Remember, that the same configuration (apart from the root directory) works for a simple Wordpress installation.
<VirtualHost *:80>
ServerAdmin webmaster#localhost
DocumentRoot /var/www/my_site
LogLevel debug
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<Directory /var/www/my_site/>
AllowOverride All
Require all granted
</Directory>
.htaccess files
The main .htaccess file in the project root again is the same as the simple Wordpress installation's.
<IfModule mod_deflate.c>
<FilesMatch "\.(html|php|txt|xml|js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>
# BEGIN Expire headers
ExpiresActive On
# Images
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType image/x-icon "access plus 1 year"
# Video
ExpiresByType video/mp4 "access plus 1 year"
ExpiresByType video/mpeg "access plus 1 year"
# CSS, JavaScript
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
# Others
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
# END Expire headers
Header unset ETag
FileETag None
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
However, there were some other .htaccess files elsewhere in other directories. In the wp-includes directory the .htaccess file looked like below, so I removed it.
<Files *.php>
deny from all
</Files>
<Files wp-tinymce.php>
allow from all
</Files>
<Files ms-files.php>
allow from all
</Files>
The other .htaccess files are in different plugin folders, and they don't seem to have any harmful directives.
Database configuration
There are some fields in the database jsdl_options table (in other installation the table name might be wp_options) that need to be set in order for the site to properly function. I also tried many variations, but this is the one that should be good according to other sources, and again, it works for the simple Wordpress installation.
site_url - http://<EC2 instance IP>
home - http://<EC2 instance IP>
upload_path - wp-content/uploads, but full path doesn't work either
wp-config.php
The wp-config.php file is seemingly properly configured. The site manages to connect to the database, it finds the cache location, and finishes reading the file without any issues.
define('WP_CACHE', true);
define( 'WPCACHEHOME', '/var/www/my_site/wp-content/plugins/wp-super-cache/' );
define( 'DB_NAME', 'db' );
define( 'DB_USER', 'dbu' );
define( 'DB_PASSWORD', 'dbp' );
define( 'DB_HOST', 'dbh' );
define( 'DB_CHARSET', 'utf8' );
define( 'DB_COLLATE', '' );
(...)
define('FS_METHOD','direct');
define('FS_CHMOD_DIR',0755);
define('FS_CHMOD_FILE',0644);
define('WP_TEMP_DIR',dirname(__FILE__).'/wp-content/uploads');
(...)
define( 'WP_DEBUG', true );
define ('WP_DEBUG_LOG', '/var/www/my_site/wp-errors.log' );
(...)
Logging
At this level, logging does not help anything. Apache2's debug-level logging does not provide additional information neither in the error.log nor in the access.log files. And the Wordpress logging only catches some unrelated PHP warnings.
Theories
My first theory is that something is blocking access to some internal (e.g. in wp-includes) files.
The other theory is that somewhere along the line there is an SSL configuration, that makes the site not run with simple HTTP requests, and requires HTTPS. But being able to run the site locally proves this otherwise.
So my questions are: Why does the site not run? Why does it fail midway during initialization? Why did it not fail in my local environment?
I have this issue with my wordpress site, sometimes posting a new post will overwrite a previous post. Specially one of my writers is suffering from this problem very much.
I am using litespeed cache. I've also enabled Redis object caching on my website recently but I had the problem before enabling it too.
I resolved this by adding a htaccess file with below content in wp-admin folder.
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html "access plus 0 seconds"
</IfModule>
RewriteRule ^(.*)$ $1 [NS,E=no-gzip:1,E=dont-vary:1]
I am working on a Symfony2 application that uses a lot of images, JS and CSS files.
I would like the browser to cache these aggressively, so that the majority of pageloads will not re-requests these assets.
The default appears to be for the browser to keep re-checking them and for the server to respond with a 304 Not Modified. How do I change this so that it doesn’t even run this request? (I don’t mind if it uses ETag or Expires or whatever mechanism, just as long as the majority of page requests don’t run separate requests for all the images.)
I’ve googled around a lot and found a lot of information on how to do this for pages where you have a $request object in your controller that you can set various properties on. However, I’m asking how to do this for assets (such as images) which are not returned by any of my PHP code.
You must add this in your httpd.conf file :
ExpiresActive On
ExpiresByType image/gif "access 1 month"
ExpiresByType image/jpg "access 1 month"
ExpiresByType image/jpeg "access 1 month"
ExpiresByType image/png "access 1 month"
ExpiresByType text/css "access 1 month"
ExpiresByType text/js "access 1 week"
ExpiresByType application/javascript "access 1 week"
The module 'mod_expires' must be activated
Also, don't forget to add an asset_version in your config file (see http://symfony.com/doc/current/reference/configuration/framework.html#ref-framework-assets-version), in order to invalidate cache when you change some asset
It is not for your web server, but for someone who use nginx+symfony the solution is:
Edit config.yml to enamle asset version control it describer here
#app/config/config.yml
framework:
# ...
assets:
version: 'v2'
Where 'v2' - is your custom asset verion name.
Edit your nginx config as it described here
server {
...
location ~* ^.+\.(rss|atom|jpg|jpeg|gif|png|ico|rtf|js|css)$ {
expires max;
}
...
}
Now all your assets will have the longest expiration period.
If your make new release and change some .css and .js files, just edit version name eg. from 'v2' to 'v3'.
When I refresh the page, it reloads the images which is something I don't want
I am working on two WordPress blogs, on two different servers. http://www.i-phony.com/ & http://www.dz-ahbeb.com.
They have the same exact template. But the is a problem is only with the first website. even though the settings are the same.
I tried disabling plugins and the problem was still there.
What do you suggest?
Thanks everyone
Update:
I added this to the .htacess file, and it made the blog load much faster, which means it saves cache, but I still can see the images "flash" they disappear before they appear again.
<IfModule mod_expires.c>
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
Looks to me like this is performance related. It's not that the logo isn't loading quick enough, it's that it's being requested too late.
If you look at a waterfall report for the i-phony site you'll see that the logo and the rest of the images are loading quite late. It's loading the logo file (request 33) way after it's loading a bunch of blocking javascript.
The other site is loading the logo and images much earlier (see waterfall here request 10) and loading the javascript much later to prevent it blocking the page render.
There are a few things you can do to speed up the loading of the images. Firstly I suggest you load as much of the javascript in the footer as you can and combine & minify as many css and javascript files as you can to lower the transfer amount and total requests.
You can use a plugin like W3 Total Cache to combine+minify+defer the js to footer without needing to make any changes to the underlying code.
Are they on the same server? It is possible that browser.cache header is different in different environments.
There are browser cache directives that can be sent to tell the client's browser how long to keep page objects like images, media content, page html, stylesheets, javascripts, etc in the local client browser cache before trying to refresh. These directives are enabled through DSO modules (apache web server), server configuration and .htaccess file entries.
Example apache directive
#Set caching on image files for 11 months
<filesMatch "\.(ico|gif|jpg|png)$">
ExpiresActive On
ExpiresDefault "access plus 11 month"
Header append Cache-Control "public"
</filesMatch>