Tag: WordPress

Setting up a Cloudflare SSL certificate for Bitnami WordPress on Google Cloud Compute Engine

Bitnami WordPress on Google Cloud Compute Engine does not out of the box ship with SSL turned on, site owners need to secure communication to and from their website using SSL.

Here’s how to configure SSL using a free Cloudflare SSL certificate for Bitnami WordPress on Google Cloud Compute Engine.

Creating certificate files with Cloudflare

First we generate and download the SSL certificate files from Cloudflare.

    1. Open up your site profile on Cloudflare.com
    2. Switch to the Crypto tab
    3. Within the Origin Certificates section click the Create Certificate button
    4. Ensure the Let Cloudflare generate a private key and a CSR option is set to RSA
    5. Click Next
    6. With the Key format field set to PEM (Default) highlight and paste the contents of the Origin Certificate and Private Key blocks into separate new files on your Desktop:
      • Origin Certificate: server.crt
      • Private Key: server.key

Configuring Apache on your WordPress Bitnami instance

  1. Now we connect with SSH to the hosting server; your Google Cloud Compute Engine instance. You can do this via the Google Cloud Platform > Compute Engine > VM Instances > Connect with SSH or with your preferred terminal client.
    1. Open an SSH session to your Google Cloud Compute Engine instance
    2. Navigate to the /opt/bitnami/apache2/conf/ directory with the following terminal command: 
       cd /opt/bitnami/apache2/conf/
    3. Delete or rename the existing server.crt and server.key files in this directory (I prefer to rename them to server.crt_legacy and server.key_legacy): 
       sudo mv server.crt server.crt_legacy

 sudo mv server.key server.key_legacy
    4. Create two new files in their place: 
       sudo touch server.crt

 sudo touch server.key
    5. With your preferred terminal text editor paste the contents of the two Cloudflare certificate files mentioned above into these new files on your hosting server 
       sudo nano server.crt

 sudo nano server.key
    6. Restart the Apache service 
      sudo /opt/bitnami/ctlscript.sh restart apache

Enable SSL within Cloudflare

  1. Open up your site profile on Cloudflare.com
  2. Switch to the Crypto tab
  3. Change the SSL dropdown from Flexible to Full
  4. Change the Always use HTTPS option to On
  5. Change the Automatic HTTPS Rewrites option to On

That’s it!

Hiding the Bitnami corner banner on new Google Cloud Compute Engine instances

By default new Bitnami instances show a corner banner on all pages. To remove this connect to your Google Cloud Compute Engine instance via SSH and enter the following commands:

  1. sudo /opt/bitnami/apps/wordpress/bnconfig –disable_banner 1
  2. sudo /opt/bitnami/ctlscript.sh restart apache
  3. sudo /opt/bitnami/ctlscript.sh restart nginx

That should be it. If you get the terminal error “Error: There has been an error.” running the bnconfig command try the following:

  1. cd /opt/bitnami/apps/wordpress/conf
  2. sudo nano httpd-app.conf
  3. Comment out the following line:

    Include “/opt/bitnami/apps/wordpress/conf/banner.conf”

    to…

    # Include “/opt/bitnami/apps/wordpress/conf/banner.conf”

  4. Save changes
  5. sudo /opt/bitnami/ctlscript.sh restart apache
  6. sudo /opt/bitnami/ctlscript.sh restart nginx

That’s it! 🙂

Fixing Installation Failed message on Bitnami WordPress and Google Cloud Compute Engine

Getting WordPress installed on Google’s Cloud Compute Engine service is super easy using the Bitnami Launchpad for Google Cloud Platform, the gotcha is the default permissions set during installation mean you cannot use the WordPress Administration to update Theme’s, Plugins or WordPress core itself.

To set the file and directory permissions correctly you will need to connect via SSH to the container that your WordPress instance is installed on.

Here’s how to set the directory and file permissions correctly, split up into the different WordPress core directories:

WordPress base directory

sudo find /opt/bitnami/apps/wordpress/htdocs -type f -exec chmod 664 {} \;

sudo find /opt/bitnami/apps/wordpress/htdocs -type d -exec chmod 775 {} \;

sudo chown bitnami:daemon -R /opt/bitnami/apps/wordpress/htdocs

wp-admin

sudo find /opt/bitnami/apps/wordpress/htdocs/wp-admin -type f -exec chmod 664 {} \;

sudo find /opt/bitnami/apps/wordpress/htdocs/wp-admin -type d -exec chmod 775 {} \;

sudo chown bitnami:daemon -R /opt/bitnami/apps/wordpress/htdocs/wp-admin

wp-includes

sudo find /opt/bitnami/apps/wordpress/htdocs/wp-includes -type f -exec chmod 664 {} \;

sudo find /opt/bitnami/apps/wordpress/htdocs/wp-includes -type d -exec chmod 775 {} \;

sudo chown bitnami:daemon -R /opt/bitnami/apps/wordpress/htdocs/wp-includes

wp-content

sudo find /opt/bitnami/apps/wordpress/htdocs/wp-content -type f -exec chmod 664 {} \;

sudo find /opt/bitnami/apps/wordpress/htdocs/wp-content -type d -exec chmod 775 {} \;

sudo chown bitnami:daemon -R /opt/bitnami/apps/wordpress/htdocs/wp-content

That’s it!

Trends in persistent WordPress Administration notices

I’ve been helping out store owners in maintaining their stores for a little while now and the trend for Plugin and Theme developers to introduce persistent WordPress Administration notices for non-critical site activities or inappropriate site wide notices is becoming too common. I want to bring this to the attention of other WordPress users so that this can be addressed.

screenshot-woocommerce-notices

A ‘good’ developer will limit persistent notices to critical site activities only (e.g. caching Plugins, major database updates).

In the above case WooThemes Subscription and Envato’s Theme notices are considered critical; subscription sales won’t work and the Theme will be missing core functionality without addressing those notices.

Configuring default options for a CSV exporter or installing a Plugin update helper isn’t a critical activity.

A ‘great’ developer will still add the ability to dismiss these notices even in the case of a critical site activity.

Envato’s Theme and SkyVerge have added a dismiss option with their exporter setup notice but in SkyVerge’s case the notice does not need to be on all screens or considered an error. Dropping the error CSS class and limiting this setup notice to just the Plugins, Dashboard > Updates and own CSV Export screens would be better.

WooThemes don’t offer a dismiss option at all which makes for unnecessary nagging and screen clutter and goes against the WordPress Plugin Guidelines.

It’s fine to put an error message at the top of the admin for special cases, but it should be linked to a way to fix the error and it should be infrequent. Any form of “nagging” is absolutely prohibited.

That’s my rant. I’ll add an option to the next release of Store Toolkit for WooCommerce to hide that persistent notice so this post isn’t all for a lost cause.

Finally a Fix for XAMPP and WordPress Permalinks

Error 500 – Server error!

Fun times with Apache… Recent releases of XAMPP for Windows hide additional Apache overrides outside of the reach of …/apache/conf/httpd.conf. If you’re like me and exhausted all prior Google results to get Permalinks working with XAMPP give this one a go.

  1. Open …/apache/conf/extra/httpd-xampp.conf
  2. Replace all instances of AllowOverride None and AllowOverride AuthConfig with AllowOverride All
  3. Save changes
  4. Open XAMPP Control Panel and restart the Apache service or open the Windows Services dialog and restart the Apache2.4 Service
  5. Breathe and give that Error 500 tab a refresh

Woop! In case this doesn’t work it’s likely you’ve missed one of the basics:

  1. Open …/apache/httpd.conf
  2. Uncomment #LoadModule rewrite_module modules/mod_rewrite.so
  3. Replace all instances of AllowOverride None and AllowOverride AuthConfig with AllowOverride All
  4. Save changes
  5. As above, restart the Apache Service.