LineagePress Developer Manual: System Architecture

This document provides a high-level overview of the LineagePress plugin architecture. It is intended for developers who are new to the project.

Core Philosophy

The plugin is built on modern PHP principles, emphasizing separation of concerns, modularity, and maintainability. It leverages a PSR-4 autoloader for class loading and organizes its features into distinct, self-contained “systems.”

While originally developed as a broader genealogy suite (which later may be developed if there is interest), the current version focuses on importing GEDCOM files and displaying the resulting family tree data on the WordPress frontend.

Plugin Lifecycle and Initialization

The plugin’s lifecycle begins with lineagepress-pro.php and is orchestrated by the \LineagePress\Core\HP_Bootstrap class.

1. lineagepress-pro.php (Entry Point)

• Constants: Defines global constants like LINEAGEPRESS_PLUGIN_DIR and LINEAGEPRESS_VERSION.
• Requirements Check: Verifies that the server environment (PHP version, etc.) meets the minimum requirements before loading further.
• Autoloader Registration: Registers the \LineagePress\Core\HP_Autoloader, which handles loading all namespaced classes (e.g., \LineagePress\Core\...).
• Bootstrap Initialization: Calls \LineagePress\Core\HP_Bootstrap::init(), triggering the main initialization sequence.
• Activation/Deactivation: Registers activation and deactivation hooks handled by the \LineagePress\Core\HP_Activation class, which sets up or removes database tables and other persistent settings.

2. includes/class-hp-bootstrap.php (The Conductor)

• This class orchestrates the loading and initialization of all plugin components in a specific order.
• First, it loads necessary procedural files for the frontend and admin areas.
• Then, it initializes core handlers for AJAX, admin form posts, and database operations.
• Finally, it instantiates and initializes the major functional systems of the plugin:
  • Privacy System
  • Search System
  • Reports System
  • Asset (CSS/JS) Management
  • Template System
  • URL Rewrite Management

Directory Structure

The plugin’s code is organized into the following key directories:

• /admin: Contains all code related to the WordPress admin interface.
  • /admin/controllers: Classes that handle the logic for admin pages (e.g., saving settings, processing imports).
  • /admin/renderers: Classes responsible for rendering the HTML of the admin pages, separating logic from presentation.
• /includes: Contains the core business logic of the plugin.
  • /includes/database: A dedicated class for each custom database table, abstracting direct database queries.
  • /includes/Import: The powerful GEDCOM parsing and import engine.
  • /includes/privacy: Code related to user privacy features.
  • /includes/Reports: The reporting engine.
  • /includes/search: The search functionality.
• /public: Contains assets and code for the public-facing side of the website.
  • /public/css: Frontend stylesheets.
  • /public/js: Frontend JavaScript files.
  • /public/templates: The default templates for displaying genealogy data (e.g., individual profiles, family charts).
• /developer: Contains all developer documentation, including this manual and detailed guides for each system.
• /languages: Contains translation files for internationalization.

Key Design Patterns

• System-Based Modularity: Features are grouped into “systems” (e.g., Import System, Template System), each with its own set of classes and responsibilities, making the codebase easier to navigate and maintain.
• Controller/Renderer Pattern: In the admin area, Controller classes handle logic and data processing, while Renderer classes handle HTML output. This separation makes the code cleaner and easier to test.
• Service Classes/Managers: Classes ending in Manager or Handler often act as services that manage a specific resource or functionality (e.g., HP_Assets_Manager, HP_Admin_Menu_Handler).
• Database Abstraction: Each custom database table has a corresponding class in includes/database/. This abstracts the SQL queries and provides a clean API for the rest of the plugin to interact with the data, preventing raw SQL from cluttering the codebase.

---

This high-level architecture provides a foundation for understanding the more detailed system manuals.

---