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 a WordPress website hosted on a LiteSpeed server via the Hostinger platform.
I have a file called stellar.toml at www.example.net/.well-known/stellar.toml. The WordPress file manager plugin tells me the file's kind is Plain text.
But if I type its URL I get a download started, I need instead to have the file's text prompted on the screen.
Does anyone know how I can fix this issue?
Thanks in advance!
Create a .htaccess on your .well-known folder:
<IfModule mod_rewrite.c>
<FilesMatch "^stellar\.toml$">
AddType text/plain .toml
</FilesMatch>
</IfModule>
Been working on speed optimization for a WordPress site hosted in AWS.
Created .htaccess in the root folder of the site added this
<IfModule mod_expires.c>
<FilesMatch "\.(css|js|png|jpg|jpeg)$">
Header set Cache-Control "max-age=788400, proxy-revalidate"
</FilesMatch>
</IfModule>
Tested the site using GTMetrix, but it still throws 'Leverage Browser Caching'. Seems the htaccess is not taking effect. Is this the right place to put the .htaccess file?
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.
I am setting expires header in .htaccess file as below
ExpiresActive On
ExpiresDefault A1209600
It works for all the files that are in document root, but I have a separate mounted drive which is used as drupal file system ( private ), where I store my jcarousel images and for these images the expires header are not working.
You private file system will have its own .htaccess file created by Drupal. Try adding the same line there.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Deny from all
Options None
Options +FollowSymLinks
ExpiresActive On
ExpiresDefault A1209600