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.