# Business rules — wcu_wp

Evidence date: 2026-09-29. Source: `git@bitbucket.org:overdrive/wcu_wp.git` at `ed9b5b6` (`main`).

No business-rules document existed in the repository or in Silicon Ark. Rules below are taken from project code or from vendored code that changes who can do what. Vendor marketing text is not treated as a rule of this organisation.

Rules enforced only when a plugin or module is active are marked that way. Active plugins are a database setting and are **Unknown** unless noted.

## Identity and branding

### BR-001 — Footer designer credit

**Inferred as a business instruction, implemented as code.** The public footer credit must name Overdrive and link to `http://overdrive.co.za/`.

The implemented string is "Designed by Silcon Overdrive" (that spelling). The parent theme's credit ("Designed by ThemeBoy", `http://themeboy.com/`) does not show while the child theme is loaded, because the child defines `rookie_footer_credit()` first.

Evidence: `wp-content/themes/rookie-child/functions.php`, `wp-content/themes/rookie/functions.php`.

The copyright line is separate and was not customised: `© {current year} {WordPress site name}`. The site name is a setting. **Unknown**.

### BR-002 — WRU presentation

**Inferred.** The child theme title is "Rookie Child Theme for WRU". Colours and fonts in `style.css` are the committed visual rules (teal `#00a69c`, dark `#2b353e`, Oswald headings, Lato body).

There is no written brand guide in the repo. Whether these colours are the organisation's brand or a theme preset that was edited is **Unknown / Requires Confirmation**. The accent is applied consistently across links, buttons, menus, and SportsPress highlights, which is more than an untouched Rookie demo, but the file is still one large stylesheet rather than a documented brand system.

### BR-003 — Names WCU and WRU

**Unknown / Requires Confirmation.** The git repository is `wcu_wp`. The theme says WRU. No document in the repo expands either abbreviation or states that they are the same body.

## Who may see and edit what

### BR-004 — WordPress roles

**Implemented** by WordPress core, not by this project. Standard roles apply (administrator, editor, author, contributor, subscriber). This repository does not add a role and does not add capability checks of its own.

### BR-005 — Team-limited sports editors

**Vendor rule, conditional.** When the SportsPress Team Access module is enabled, users whose role is `sp_player`, `sp_staff`, `sp_team_manager`, or `sp_event_manager` are limited to SportsPress records for teams listed in their user meta key `sp_team`.

Limited post types: `sp_event`, `sp_calendar`, `sp_team`, `sp_table`, `sp_player`, `sp_list`, `sp_staff`.

Other roles are not limited by this function. The role list and the post-type list can be changed by filters (`sportspress_team_access_roles`, `sportspress_team_access_post_types`). This repository does not add those filters.

Evidence: `wp-content/plugins/sportspress-pro/includes/sportspress-team-access/sportspress-team-access.php`.

Whether the module is enabled, and whether those roles exist in the database, is **Unknown**.

### BR-006 — SportsPress required by the theme

**Vendor rule, implemented.** Rookie tells administrators that SportsPress is required (`required => true` in `rookie_register_required_plugins`). The check accepts any plugin that provides `SportsPress::instance`. SportsPress Pro does. If the free plugin `sportspress/sportspress.php` is also active, Pro deactivates it on `admin_init`.

Evidence: `wp-content/themes/rookie/functions.php`, `wp-content/plugins/sportspress-pro/sportspress-pro.php` (`deactivate_core`).

### BR-007 — No project-specific public registration rule

**Implemented absence.** The child theme does not add a membership form, a paid registration, or an age gate. Public registration, if it exists, is the WordPress setting "Anyone can register", which is not in git. **Unknown**.

NS Cloner is an admin tool for copying sites. It is not a public signup flow. `wp-signup.php` is stock WordPress multisite signup and is present because the whole core tree is vendored.

## Presentation rules

### BR-008 — Header colour comes from theme options

**Implemented.** The child header inner element is coloured with the `themeboy` option `primary`. Logo, site title, and tagline follow Rookie's usual options (`logo_url`, header text colour, "Display Site Title and Tagline"). Header search is on unless `nav_menu_search` is explicitly false.

Evidence: `wp-content/themes/rookie-child/inc/template-tags.php`.

The stored colour is **Unknown**. If `primary` is missing, the inline colour is empty and PHP will warn when it reads the key.

### BR-009 — Post meta visibility

**Implemented**, copied into the child from Rookie.

- The post date links to the permalink unless `themeboy` option `show_post_date` is set and false.
- The author byline is shown only when `show_post_author` is true. Default in this function: hidden when the key is absent.
- Category links on a post show only when the post type is `post` and the site has more than one category (`rookie_categorized_blog`, cached in transient `rookie_categories`).
- Tag links show on posts when the post has tags.
- Pages do not show category or tag blocks.

Evidence: `rookie_entry_date`, `rookie_entry_meta`, `rookie_entry_footer` in the child `inc/template-tags.php`.

### BR-010 — Second site stylesheet

**Implemented.** If the current blog ID is 2, enqueue `css/subsite-2.css`. No other ID is special-cased.

The file is not in the repository, so the rule cannot be satisfied from this tree. What visual difference blog 2 was supposed to have is **Unknown**.

Evidence: `wp-content/themes/rookie-child/functions.php`.

### BR-011 — Styles for plugins that are not in the repo

**Implemented CSS only.** The child stylesheet includes WooCommerce and BuddyPress selectors. Those plugins are not vendored. The CSS does not install them and does not change checkout or community rules.

Do not treat a shop or a community as a business rule of this product unless someone confirms the plugins are installed on the server.

## Sports data rules that are vendor defaults

These exist in SportsPress Pro's code and readme. They are **not** confirmed configuration for WRU. They apply only when the matching module is enabled and someone has entered data.

| Topic | Vendor behaviour | This repo's confirmation |
|---|---|---|
| Tournaments | Brackets, rounds, results | Module present. No tournament records in git |
| Sponsors | Logo, link, impressions and clicks | Module present. No sponsors in git |
| Staff directory | Email and phone on staff, click to email or call | Module present. No staff records in git |
| Birthdays | Player and staff age from a birthday field | Described in `readme.txt`. Not confirmed in use |
| Team colours | Palette stored per team | Module present. Colours not in git |
| Maps | Venue map via the Google Maps module | Module present. API key not in git |
| Multisite widgets | Sports widgets can read other sites in the network | Module present. Network status Unknown |

No scoring formula, league points system, or eligibility rule was added in the child theme or in any project-owned PHP file. If WRU has a points system, it is SportsPress settings in the database. **Unknown**.

## Deploy rules

### BR-012 — Production deploy is FTP from main

**Implemented.** Pushing `main` is what triggers deploy. There is no other deploy script in git.

The step runs `git ftp init` and then `git ftp push --resume` to `ftp://$FTP_HOST/`. Credentials are pipeline variables, not files.

**Requires confirmation:** running init on every production deploy. The commit message says the init was added on purpose (`ed9b5b6`, "Add initialize on git ftp"). git-ftp's init is a first-run action. Leaving it in the steady-state pipeline may make later deploys fail once the remote is initialised.

### BR-013 — QA deploy is a different FTP target

**Implemented in the pipeline file, not on a branch.** Branch `qa` would push with `--resume` to `$FTP_HOST_QA`. Init for QA is commented out. The remote has no `qa` branch, so this rule is not currently triggered.

The QA step is labelled "Build and Test production". That label is not a second production deploy. The host variables are the QA ones.

### BR-014 — What must not be deployed from git

**Implemented** by `.gitignore`, so these paths are not in the tree that git-ftp syncs (git-ftp uploads tracked files):

- `wp-config.php`
- `.htaccess`
- `web.config`
- `/wp-content/uploads/`
- `wp-content/debug.log`
- `*.sql`, `*.tar.gz`, `*.zip`
- `node_modules/`, `dist/`

A server that was deployed only from this repository still needs a `wp-config.php` created on the host. Uploads made on the host are not replaced by git, because they are not tracked.

**Inferred risk:** git-ftp syncs deletions of tracked files. It does not delete gitignored uploads. It will upload the whole WordPress core when those files change.

### BR-015 — Scan after deploy

**Implemented.** The SonarQube step is a later step on the same branch pipeline. It does not gate the FTP upload. A failed scan does not roll back FTP. A failed FTP step skips the scan.

No quality gate (coverage, ratings, or "must pass before deploy") is defined in the repository.

## Locale

### BR-016 — South African English package

**Implemented.** The committed core is the `en_ZA` WordPress package, with matching language files for core admin, Ninja Forms, Smart Slider 3, and Twenty Twenty-Five.

The database option that sets the site language can differ. **Unknown** if it was changed after install.

## Explicit non-rules

The following were looked for and not found in project-owned code:

- Membership fees, shop prices, or tax.
- Eligibility to play, age limits, or registration deadlines.
- A privacy notice, cookie banner, or terms page (those would be WordPress content).
- A custom password policy.
- Rate limits or captcha on login or forms (Ninja Forms may have add-ons; none are configured in git).
- An editorial approval workflow beyond WordPress post statuses.

If those rules exist, they are outside this repository (database content, another system, or a hosting control panel).