AWS / Wordpress – Differs from Apache

More from this category




OFFLOAD MEDIA – How files are updated –

The primary difference is that the old addon would actively scan for asset files in the filesystem of the WordPress install, and upload these files to Amazon S3. Asset URLs could then be rewritten to use S3 URLs or a custom domain of your choice to use with a CDN.

The Assets Pull addon, does not scan or upload your files at all, nor does it have any background processing. It simply rewrites asset URLs to use your custom CDN domain which “pulls” uncached assets from your site on-demand. This is more efficient with system resources and generally advocates better practices such as using a CDN rather than serving directly from the bucket.

Setting up CDN

Assets Pull: Settings

  • Need a second url for the assets ourside of the media files

Rewrite Asset URLs
This is the master switch which controls whether your enqueued assets will be rewritten or not.

Pull Domain
This is the domain which your asset URLs will be rewritten with and is the domain that you need to configure Amazon CloudFront (or your CDN of choice) to pull from your site. The domain should be entered by itself, without any scheme or URL path.

E.g. cdn.example.com

We highly recommend using a subdomain of your site’s domain for SEO. That is, if your site’s main domain is example.com, or www.example.com then we would recommend using a subdomain on the same domain, such as cdn.example.com or assets.example.com.

This domain should be different than the one used for your media files as they serve from different origins, and will likely have other important differences in configuration.

Force HTTPS
By default, asset URLs will use HTTPS when the request is HTTPS and regular HTTP when the request is HTTP, but you may want to force the use of HTTPS always, regardless of the request.

This may be desirable on a site using HTTP, but wishes to take full advantage of performance benefits provided by HTTP/2 for assets which require using HTTPS.

Controlling Settings with Constants
All of the above settings can be defined in your wp-config.php which will override the value saved in the database. For more information, see Settings Constants

Settings Constants

All settings within WP Offload Media and the Assets Addon can be defined using two constants within your wp-config.php file.

WP Offload Media

define( 'AS3CF_SETTINGS', serialize( array(
    // Storage Provider ('aws', 'do', 'gcp')
    'provider' => 'aws',
    // Access Key ID for Storage Provider (aws and do only, replace '*')
    'access-key-id' => '********************',
    // Secret Access Key for Storage Providers (aws and do only, replace '*')
    'secret-access-key' => '**************************************',
    // GCP Key File Path (gcp only)
    // Make sure hidden from public website, i.e. outside site's document root.
    'key-file-path' => '/path/to/key/file.json',
    // Use IAM Roles on Amazon Elastic Compute Cloud (EC2) or Google Compute Engine (GCE)
    'use-server-roles' => false,
    // Bucket to upload files to
    'bucket' => 'mybucket',
    // Bucket region (e.g. 'us-west-1' - leave blank for default region)
    'region' => '',
    // Automatically copy files to bucket on upload
    'copy-to-s3' => true,
    // Rewrite file URLs to bucket
    'serve-from-s3' => true,
    // Bucket URL format to use ('path', 'cloudfront')
    'domain' => 'path',
    // Custom domain if 'domain' set to 'cloudfront'
    'cloudfront' => 'cdn.exmple.com',
    // Enable object prefix, useful if you use your bucket for other files
    'enable-object-prefix' => true,
    // Object prefix to use if 'enable-object-prefix' is 'true'
    'object-prefix' => 'wp-content/uploads/',
    // Organize bucket files into YYYY/MM directories
    'use-yearmonth-folders' => true,
    // Serve files over HTTPS
    'force-https' => false,
    // Remove the local file version once offloaded to bucket
    'remove-local-file' => false,
    // Append a timestamped folder to path of files offloaded to bucket
    'object-versioning' => true,
) ) );

Assets Pull Addon

define( 'AS3CF_ASSETS_PULL_SETTINGS', serialize( array(
    // Rewrite enqueued style/script URLs to CDN domain
    'rewrite-urls' => false,
    // CDN domain to use
    'domain' => 'assets.example.com',
    // Serve files over HTTPS
    'force-https' => false,
) ) );

!!! IMPORTANT !!!

The above defines should be placed before:

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');


AWS + UBUNTU DIFFERENCES

  • Redirect Rules: https://aws.amazon.com/premiumsupport/knowledge-center/redirect-http-https-elb/
  • Security
  • Domains
  • Permalinks – https://stackoverflow.com/questions/12292992/permalinks-on-wordpress-ec2 – different for Ubuntu servers / different from traditional servers
    https://guiem.info/permalinks-on-wordpress-amazon-ec2/
  • Ubuntu servers – these have different rules
  • Setting site limits – max-memory / max upload size etc. all in different file than php.ini / wp-config / htaccess – can be overwritten with htaccess – but is that the right one?
  • File Permissions


These procedures are intended for use with Amazon Linux. For more information about
other
distributions, see their specific documentation. Many steps in this tutorial do not
work
on Ubuntu instances. For help installing WordPress on an Ubuntu instance, see WordPress in the Ubuntu
documentation.


AWS AND WORDPRESS

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hosting-wordpress.html

https://us-west-1.console.aws.amazon.com/systems-manager/automation/execute/AWSDocs-HostingAWordPressBlog-AL?region=us-west-1

https://us-west-1.console.aws.amazon.com/systems-manager/automation/execute/AWSDocs-HostingAWordPressBlog-AL2?region=us-west-1


Amazon Lightsail – https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-tutorial-launching-and-configuring-wordpress
https://aws.amazon.com/getting-started/hands-on/launch-a-wordpress-website/
Amazon Elastic Compute Cloud (Amazon EC2) – https://aws.amazon.com/elasticache/memcached/wordpress-with-memcached/

BEST PRACTICES:
https://aws.amazon.com/blogs/architecture/wordpress-best-practices-on-aws/

[pdf-embedder url=”http://projects.nakedsword.com/wp-content/uploads/2020/07/wordpress-best-practices-on-aws.pdf”]

HIGH AVAILABILITY WEBSITE – BEGINS PAGE 262
[pdf-embedder url=”https://clickety-clack.click/img/clickety-clack-site/prevsiteimgs/2020/07/awseb-dg.pdf”]
[pdf-embedder url=”https://clickety-clack.click/img/clickety-clack-site/prevsiteimgs/2020/07/deploying-wordpress-with-aws-elastic-beanstalk.pdf”]
MARKETPLACE:
https://aws.amazon.com/marketplace/search/results/ref=dtl_navgno_search_box?page=1&searchTerms=wordpress


You are responsible for updating the software packages and maintaining security patches
for your server. For a more automated WordPress installation that does not require
direct
interaction with the web server configuration, the AWS CloudFormation service provides
a WordPress
template that can also get you started quickly. For more information, see
Getting Started in the
AWS CloudFormation User Guide. If you’d prefer to host your WordPress blog on a
Windows instance, see Deploying a WordPress Blog on Your Amazon EC2 Windows Instance in the
Amazon EC2 User Guide for Windows Instances. If you need a high-availability solution with
a decoupled database, see Deploying
a High-Availability WordPress Website
in the
AWS Elastic Beanstalk Developer Guide.

MORE NOTES::

This tutorial assumes that you have launched an Amazon Linux instance with a functional
web
server with PHP and database (either MySQL or MariaDB) support by following all of
the
steps in Tutorial: Install a LAMP Web Server with the Amazon Linux AMI for Amazon Linux AMI or
Tutorial: Install a LAMP Web Server on Amazon Linux 2
for Amazon Linux 2. This tutorial also has steps for configuring a security group
to allow
HTTP and HTTPS traffic, as well as several steps to ensure
that file permissions are set properly for your web server. For information about
adding
rules to your security group, see Adding rules to a security group.

We strongly recommend that you associate an Elastic IP address (EIP) to the instance
you are using to host a WordPress blog. This prevents the public DNS address for your
instance from changing and breaking your installation. If you own a domain name and
you
want to use it for your blog, you can update the DNS record for the domain name to
point
to your EIP address (for help with this, contact your domain name registrar). You
can
have one EIP address associated with a running instance at no charge. For more
information, see Elastic IP addresses.

If you don’t already have a domain name for your blog, you can register a domain name
with Route 53 and associate your instance’s EIP address with your domain name. For
more
information, see Registering Domain Names Using
Amazon Route 53
in the Amazon Route 53 Developer Guide.

To complete this tutorial using AWS Systems Manager Automation instead of the following
tasks,
run one of the following Automation documents:
(Amazon Linux) or
(Amazon Linux 2).


Possible Permission Fixes

Amazon EC2 Apache Setup Permissions for WordPress


Amazon EC2 Apache Setup Permissions for WordPress

I have been doing my best to figure out the Amazon EC2 Apache setup of permissions to enable WordPress to be able to manage all of the files on my Amazon EC2 instance without WordPress asking for FTP permissions when I try to upload a plugin or theme via the Admin site. I ended up having to give file and group ownership of the files in my html folder to apache user for WordPress to run correctly. This article and its comments helped me reach this conclusion.

sudo su
chown -R apache:apache /vol/html

 

I then set permissions to what the hardening WordPress guide recommends for my html root as all my WordPress files are there as I am running MultiSite with multiple domains.

find /vol/html/ -type d -exec chmod 755 {} ;
find /vol/html/ -type f -exec chmod 644 {} ;

As apache doesn’t have a login I feel this is worth the risk though there is probably a better way to do this. I then added ec2-user to the apache group and changed the permissions of the wp-content folder to have group write permission 775.

useradd -G apache ec2-user
sudo chmod -R 775 /vol/html/wp-content
This allows FileZilla or any other program logged in as ec2-user the ability to change files and folders in the wp-content folder only. If anyone has a better way of doing this I would like to know. I am only using SSH and SFTP to access the server with key files.


https://aws.amazon.com/blogs/startups/how-to-accelerate-your-wordpress-site-with-amazon-cloudfront/


https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/php-hawordpress-tutorial.html


[pdf-embedder url=”https://clickety-clack.click/img/clickety-clack-site/prevsiteimgs/2020/07/wordpress-best-practices-on-aws.pdf”]


Introduction

WordPress is an open-source blogging tool and content management system (CMS) based on PHP and MySQL that is used to power anything from personal blogs to high- traffic websites.

When the first version of WordPress was released in 2003, it was not built with modern elastic and scalable cloud-based infrastructures in mind. Through the work of the WordPress community and the release of various WordPress modules, the capabilities of this CMS solution are constantly expanding. Today, it is possible to build a WordPress architecture that takes advantage of many of the benefits of the AWS Cloud.

Simple Deployment

For low-traffic blogs or websites without strict high availability requirements, a simple deployment of a single server might be suitable. This deployment isn’t the most resilient or scalable architecture, but it is the quickest and most economical way to get your website up and running.

Considerations

We will start with a single web server deployment. There may be occasions when you outgrow it, for example:

• The virtual machine that your WordPress website is deployed on is a single point of failure. A problem with this instance causes a loss of service for your website.

• Scaling resources to improve performance can only be achieved by “vertical scaling,” that is, by increasing the size of the virtual machine running your WordPress website.
Available Approaches

AWS has a number of different options for provisioning virtual machines. There are three main ways to host your own WordPress website on AWS:

• Amazon Lightsail – https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-tutorial-launching-and-configuring-wordpress
https://aws.amazon.com/getting-started/hands-on/launch-a-wordpress-website/
• Amazon Elastic Compute Cloud (Amazon EC2) – https://aws.amazon.com/elasticache/memcached/wordpress-with-memcached/
• AWS Marketplace


https://github.com/aws-samples/aws-refarch-wordpress


https://aws.amazon.com/getting-started/hands-on/build-wordpress-website/

In this project, you will learn how to deploy and host WordPress, an open-source blogging tool and content management system (CMS) based on PHP and MySQL. You will implement an architecture to host WordPress for a production workload with minimal management responsibilities required from you. To accomplish this, you will use AWS Elastic Beanstalk and Amazon Relational Database Service (RDS). Once you upload the WordPress files, Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. Amazon RDS provides cost-efficient and resizable capacity, while managing time-consuming database administration tasks for you.


Scroll to Top