Introduction: The Architecture Gap in Shared Hosting

Modern PHP frameworks like CodeIgniter 4 are designed with a “Public Folder” architecture. This means only the /public directory should be exposed to the web, while the /app, /system, and /writable directories remain one level above, safe from direct URL access. However, many shared hosting services, such as Lolipop! in Japan, force the web root to a specific directory, often making this ideal structure difficult to implement.

In this article, I will demonstrate how to bridge this gap using advanced .htaccess manipulation, ensuring your application remains secure without needing a VPS or dedicated server.

Why Directory Isolation Matters

If you upload all framework files directly to the document root, sensitive files like .env (containing database credentials and API keys) could potentially be accessed via a browser. By isolating the public assets, we create a “firewall” at the file-system level. This is a fundamental principle of web application security.

The Solution: Multi-Layer .htaccess Configuration

To make CodeIgniter 4 work seamlessly on shared hosting where you cannot change the DocumentRoot, we need to handle requests at the root level and “silent-forward” them to the public folder.

Step 1: The Root Directory .htaccess

Create an .htaccess file in your main project folder (the one containing both app/ and public/). This script acts as a traffic controller.

# Disable directory browsing for security
Options -Indexes

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /

    # 1. Direct access to existing files in the public directory
    # This ensures CSS, JS, and Images are loaded correctly
    RewriteCond %{DOCUMENT_ROOT}/public/$1 -f
    RewriteRule ^(.*)$ public/$1 [L]

    # 2. Prevent infinite loops by checking if we are already in the public folder
    RewriteCond %{REQUEST_URI} ^/public/
    RewriteRule ^(.*)$ - [L]

    # 3. Route all other requests to the CodeIgniter front controller
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ public/index.php/$1 [L,QSA]
</IfModule>

Step 2: Troubleshooting “Login Redirect Loops”

A common issue when using this method is the “Redirect Loop” after authentication. When a user logs in, the framework might try to redirect to /dashboard, but the .htaccess might interpret this incorrectly. Ensure your app/Config/App.php has the $baseURL set correctly to your full domain (e.g., https://mushirabe.achlabo.com/) to help the framework generate absolute URLs.

Comparison: Dynamic Sitemap vs. Physical Sitemap

During the development of “Mushi-Labe,” I experimented with dynamic XML generation via a Sitemap Controller. While dynamic generation is superior for rapidly changing content, for a stable tool, a physical sitemap.xml in the public/ folder is more performant. It bypasses the PHP engine entirely, reducing server load and avoiding conflicts with authentication filters.

Conclusion

Successfully deploying a modern framework on legacy shared hosting requires a deep understanding of server-side URL rewriting. By implementing these .htaccess rules, you achieve a professional-grade security posture while benefiting from the cost-effectiveness of shared hosting environments.