The Digital Tool Factory Blog

I recently had to start moving my various WordPress sites from the standard App Service to a standard app service on Linux, using NGINX. However, this does not work out of the box. After much googling and experimentation I came across this extremely well written blog post on the topic.

Basically just follow those instructions the letter and all your problems will be solved!

I like to do a little value add on these blog posts, but really the first has everything you need – this post is just to give credit and to find the solution again later.

Update March 23rd, 2023

You do have to add the following to the wpconfig file for it to work – that is the missing link – for some reason when the sites “transition” there is something off about their behavior to ssl – this fixes it

define(‘FORCE_SSL_ADMIN’, true);if (strpos($_SERVER[‘HTTP_X_FORWARDED_PROTO’], ‘https’) !== false)   $_SERVER[‘HTTPS’]=’on’;

This happened to me whilst working on a  pre-existing site recently.

The Problem

You are trying to install WordPress onto a subdirectory of an existing site that uses the .htaccess files for routing.  When you try to add in the changes needed for WordPress to work you break the existing site.

The Cause

WordPress .htaccess files do not play nicely with other .htaccess files

The Solution

Simply add in the WordPress generated .htaccess files in the WordPress directory, and everything magically works.

For Unix people this must be obvious, but for me it was surprisingly brilliant.

A silly one this time

The Problem

I was recently working on someone else’s WordPress theme that made extensive use of WordPress Widgets and the new dynamic sidebar feature.  I was able to recreate the widgets (there was a working staging site) but the on the production site the widgets did not appear.  What to do about disappearing WordPress widgets?

The Cause

I had changed the name of the theme.  For some reason the register_sidebar has to have the name hard coded, for example

register_sidebar( array(
		'name' => __( 'Banner Area', 'themename' ),
		'id' => 'Banner-area',
		'description' => __( 'Banner area', 'themename' ),

		'before_widget' => ' <div>',

		'after_widget' => '</div>',
		'before_title' => '<div><h1>',
		'after_title' => '</h1></div>',
	) );

The Solution

Just change the name of the theme to the new name and you’re all set!

So, you need to order a custom WordPress Post Type by a custom numeric field – how?

The Problem

You have a WordPress custom post types, and you need to order by a custom numeric field – how do you do that?

The Cause

You would think that it would be relatively simple, for example the below should work

<?php $loop = new WP_Query( array( 'post_type' => 'staff-member',

'posts_per_page' => 100, 'order' => 'ASC', 'orderby'	=>

'meta_value', 'meta_key' 	=> 'OrderByField','type' => 'numeric' ) ); ?>

But ‘OrderByField’ is treated as a text field, and the number 10, comes after 1, not 2.

The Solution

Use the magic keyword meta_value_num, so your WP_Query would look like this

<?php $loop = new WP_Query( array( 'post_type' => 'staff-member',

'posts_per_page' => 100, 'order' => 'ASC', 'orderby'	=>

'meta_value_num', 'meta_key' => 'StaffOrderBy',

'type' => 'numeric' ) ); ?>

the _num makes all the difference - WordPress will treat it as a numeric field.

The Problem

You are attempting to use WordPress taxonomies to create custom permalinks, and all you get are 404 errors.

To clarify, I was trying to use the taxonomies purely to maniplate custom page types and their permalinks, to create something like http://Domain.com/SummerCrops/Tomatos where SummerCrops is my custom taxonomy, and Tomatos is a page name

The Cause

WordPress is finicky about permalink syntax, specifically the difference between /%PostName%/ and /%PageName%/ – so for example a custom permalink structure of /%content%/%postname%/ would not work ,whereas  /%content%/%pagename%/ will.  Practically all online documentation refers to posts, not pages.

The Solution

Just use the custom permalink of /%content%/%pagename%/ and everything will be perfect.

The Problem

You are using a custom post type as the front page, and for no obvious reason it will not display in the custom template your wrote

The Cause

The front page always uses the font-page.php template in your theme, and if front-page.php is not present, then it will use the page.php template file.

The Solution

Create a front-page.php template file – it’s quite simple with that bit of missing information.