The /private Directory

The framework automatically sets up a /private directory to store files that should not be publicly accessible. This directory is located outside the web root, meaning no direct HTTP requests can reach it. However, any part of your application that runs within the fully loaded environment (plugins, theme code, CLI scripts) can still read and manage these files.

---

Overview

• Purpose: Store private assets (e.g., PDFs, configuration files, datasets) that are not intended for the public web.
• Constant: Access the directory path via PRIVATE_DIR_PATH, which the framework defines at runtime.
• Availability: Only usable after the framework is fully initialized (e.g., from within your theme’s functions.php, custom plugins, or CLI commands).

How It Works

1. Framework Provisioning
   The framework creates a secure /private directory outside your web root. Since it’s not web-accessible, direct requests via a URL will fail.

2. Placing Files
   Simply drop your private files—such as PDF documents, import/export data, or other files into the /private folder. You do not need to manually create this directory.

3. Referencing Files in Code
   When you need to access a file, concatenate its filename or subfolder path with PRIVATE_DIR_PATH. For example:

   $file_path = PRIVATE_DIR_PATH . '/my_docs/secret.pdf';
   
   if ( file_exists( $file_path ) ) {
       // Perform operations such as reading or serving the file
       $contents = file_get_contents( $file_path );
   }

   example in your plugin

   function serve_protected_file($file_name) {
       $file_path = PRIVATE_DIR_PATH . '/pdf-files/' . basename($file_name);
   
      // Check if user is logged in
       if (!is_user_logged_in()) {
   	    wp_die("You are not authorized to download this file.");
       }
   
       if (!file_exists($file_path)) {
   	    wp_die("File not found.");
       }
   
       header('Content-Type: application/octet-stream');
       header('Content-Disposition: attachment; filename="' . basename($file_path) . '"');
       header('Content-Length: ' . filesize($file_path));
   
       readfile($file_path);
       exit;
   }

   Since PRIVATE_DIR_PATH is defined after the framework loads, ensure your code resides in a context where the framework is available (e.g., a plugin’s main file, theme functions, or a CLI script).

---

Best Practices

• Validate Access: If you’re serving these private files to end users through your application (e.g., via a protected download endpoint), ensure you perform robust permission checks to prevent unauthorized access.
• Organize Files: Create logical subfolders in /private (e.g., docs, pdfs, data_exports) to keep your private assets well-structured and maintainable.
• Secure Handling: Avoid direct output of file contents to the browser without appropriate checks. Use streaming or controlled downloads when serving private files to authorized users.
• Audit & Logging: If you manage sensitive documents or large volumes of data, consider logging access attempts or changes to aid in troubleshooting and security oversight.
• No Public Access: Remember, files in /private are never meant to be publicly reachable via a URL. This is by design for security purposes.

---

Note: Do Not Store Sensitive Data

The /private directory is designed for private files, but it is not intended for storing highly sensitive information like:

❌ API keys
❌ Passwords
❌ Private encryption keys
❌ Database credentials

For storing sensitive secrets, use environment variables or a secure secrets management system instead.

The /private directory, automatically managed by the framework, offers a safe place for any files you’d prefer to keep out of the public eye—such as PDFs, data exports, or other private assets. Leverage PRIVATE_DIR_PATH to interact with these files at runtime, while continuing to enforce any additional authentication or authorization measures within your application.