This page describes some of the basic features of My Base Theme. Some of these are expanded in greater detail in subsequent pages.

• site_path_defs.php - A file of this name must be located within the themes root directory (typically public_html/wp-content/themes). This file will normally contain the statement:-
  
  require("{$_SERVER['DOCUMENT_ROOT']}/path_defs.php");
  
  The path_defs.php file typically contains a range of global definitions required by the various custom PHP scripts.

• wp-custom-scripts - A directory of this name must be contained within the root site directory (public_html).

• wp-custom-scripts/pages - This contains a directory structure corresponding to the page structure of the site. So for example for the web address https://www.mysite.com/mypage a sub-directory by the name of mypage would be created to contain any custom scripts for the given page. For the front page of the site, there would need to be a sub-directory whose name corresponds to the page slug for the front page (typically home).

• wp-custom-scripts/categories - If the WordPress site contains a blog then this directory can be created to operate in a similar manner to the page hierarchy.

When a given page is loaded from the site, the theme will check for a custom script for the given page within the hierarchy of the custom pages directory. If such a script is found then this will be run in place of the normal WordPress loop. If there is a sub-directory corresponding to the page address, then the custom script should be contained within the file _home.php within that directory. Alternatively the script could be contained in the file <pagename>.php in the sub-directory for the parent page. So for example, the script for https://www.mysite.com/page1/page2 could be contained in one of the following two locations:-

• public_html/wp-custom-scripts/pages/page1/page2/_home.php
• public_html/wp-custom-scripts/pages/page1/page2.php

Although the custom script is being run in place of the normal WordPress loop, it is still possible to create page content using the WordPress editor. The two following functions are defined for this purpose:-

• output_page_header() - This causes the page title to be output as an HTML level 1 header.

• get_content_part(<n>) - Where <n> is an integer parameter. This causes a given block of text from the WordPress page to be output. The text block within the WordPress page must be enclosed within a tag set of the form:-

  [part<n>]
  ...
  [/part<n>]

One of more of the following files may be placed in a given directory within the page hierarchy:-

• header_image.png
• header_image.jpg
• header_image_mobile.png
• header_image_mobile.jpg

On loading the page the theme works down the hierarchy to the page in question looking for image files to be used as the page header. If files are found at more than one level then the ones at the lower level take precedence. If a *.png file and the corresponding *.jpg file are found in the same location then the *.png file is selected. Items 3 and 4 in the list above are for use in mobile mode. Items 1 and 2 are used in desktop mode, but will also be used in mobile mode if mobile files are not specified.

This mechanism also operates for posts within the custom categories hierarchy.

The standard page footer for the theme can be overridden by creating a file footer.php at one or more levels in the custom page hierarchy and this holds the alternative footer content. Each footer.php file overrides any items higher up the tree.

The WordPress menu to be used for a given page must be specified by a file select_menu.php within the custom page hierarchy. On loading the page, any such files will be executed in order working down the tree. Because a menu must be specified for every page, it is mandatory for select_menu.php to exist at least at the top level of the hierarchy. (N.B. Any requirement to hide the menu on a given page should be handled within the child theme.) A typical select_menu.php file is as follows:-

$menu_id = 'main';
$menu_description = 'Main';
$hide_sidebar = true;

Line 1 matches the name of the menu within the WordPress admin interface. Line 2 specifies the menu description that will appear on the button to open the menu in mobile mode. Line 3 is optional and can be used to force the WordPress sidebar to not be displayed on the page.

The standard theme stylesheet style.css will be loaded into every page. Further stylesheets can be created by way of a file styles.css at various levels in the custom page hierarchy (note the slight difference in filename from the standard stylesheet). When a page is loaded, the theme works down the tree loading in order any stylesheets that are found.

This mechanism also operates for posts within the custom categories hierarchy.

A file authetication.php can optionally be placed at one or more levels in the custom page hierarchy. This will typically contain any particular user authentication parameters associated with the page. On loading the page, any such files will be executed in order working down the hierarchy.

A file metadata.php can optionally be placed at one or more levels in the custom page hierarchy. This contains the setting of one or more variables used in the generation of HTML meta tags. On loading the page, any such files will be executed in order working down the hierarchy.

See Handling of Meta Data for further details.

A file init.php can optionally be placed at one or more levels in the custom page hierarchy. This is used to hold any custom settings not specified elsewhere. On loading the page, any such files will be executed in order working down the hierarchy.