How Oxwall builds and rewrites URLs

Oxwall ships with two URL modes. By default it produces query-string style links such as index.php?page=user&action=profile, which are functional but poor for search visibility and awkward to share. The second mode, enabled through the AdminCP, produces clean paths like /user/profile/john. That second mode is entirely dependent on Apache-style rewrite handling, and on a LiteSpeed shared server the LiteSpeed engine reads your .htaccess rules with mod_rewrite compatibility, so the same directives Oxwall documents for Apache apply without modification.

The rewrite logic lives in the .htaccess file at the document root of your Oxwall installation. When a visitor requests /user/profile/john, that file tells the server the path does not correspond to a real file or directory, so the request is internally forwarded to index.php. Oxwall's router then parses the original path from the REQUEST_URI and dispatches the correct controller. If the rewrite rules are missing, malformed, or pointing at the wrong base directory, every friendly URL returns a 404 while the query-string version keeps working — a telltale symptom that the problem is rewrite configuration and not the application itself.

Two configuration surfaces control this on a hosting account. The first is the Oxwall database, which stores whether friendly URLs are switched on and what the site's base URL is. The second is the physical .htaccess file. These two must agree. If you enable friendly URLs in the AdminCP but never write a valid .htaccess, the CMS generates clean links that the web server cannot resolve. Conversely, a perfect .htaccess with the feature disabled in the database means Oxwall keeps emitting query-string links and your rewrite rules sit idle. Understanding that both layers exist prevents most of the confusion that surrounds Oxwall URL troubleshooting.

One more detail matters on shared hosting: the RewriteBase. If Oxwall lives in the document root (for example public_html/), the base is simply /. If it lives in a subfolder such as public_html/community/, both the AdminCP base URL and the RewriteBase directive must reflect /community/. A mismatch here is the single most common cause of redirect loops and broken profile links after a move or fresh install.

Enabling friendly URLs and writing correct rewrite rules

Start in the Oxwall AdminCP. Log in at /admin, then open Settings → General Settings. Locate the Enable SEO-friendly URLs checkbox and turn it on, then save. Oxwall immediately begins generating clean links, so you should place the rewrite rules first or in the same session to avoid a window where visitors hit 404s.

Create or edit the .htaccess file in your Oxwall root using the cPanel Jupiter File Manager (or the DirectAdmin File Manager). In File Manager, click the gear icon in the top-right and enable Show Hidden Files (dotfiles) so the existing .htaccess becomes visible. Right-click it and choose Edit. A standard root-level Oxwall ruleset looks like this:

RewriteEngine On
RewriteBase /

# Serve real files and directories directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# Route everything else through Oxwall's front controller
RewriteRule ^(.*)$ index.php?/$1 [L,QSA]

If your installation sits in a subdirectory, change the base and keep the rest identical:

RewriteEngine On
RewriteBase /community/

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1 [L,QSA]

The two RewriteCond lines are important. They tell the server to skip the rewrite when the requested path is an actual file (like a CSS asset, an uploaded image in /ow_userfiles/, or a plugin script) or a real directory. Without those conditions, requests for static assets get funneled into index.php, which breaks styling and image loading while the pages themselves appear to load.

After saving, confirm the base URL in the database matches. In the AdminCP the value is under Settings → General Settings as the site URL. If you recently changed domains or moved folders and the AdminCP is inaccessible, you can correct it directly through phpMyAdmin (found in cPanel under Databases). Open your Oxwall database, browse the ow_base_config table, and locate the row where key is site_url. Edit its value to the exact live URL including protocol and trailing slash, for example https://example.com/. Clear the Oxwall cache afterward by deleting the contents of the ow_smarty/template_c/ and ow_static/ cache folders through File Manager so stale links regenerate.

If clean URLs still 404 after all this, verify that the LiteSpeed handler is reading .htaccess at all by adding a deliberate typo — the site should throw a 500 error. If it does not, your rules are in the wrong directory. Move the .htaccess so it sits alongside Oxwall's index.php.

Canonical redirects, HTTPS, and www consolidation

Search engines treat http://, https://, www, and non-www as separate origins. Serving the same Oxwall community on several of them splits ranking signals and can create duplicate-content dilution. Consolidate on one canonical host with redirect rules placed above the Oxwall routing block in the same .htaccess. Force HTTPS and a single hostname like this:

RewriteEngine On

# Force HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Force non-www (drop the www prefix)
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1 [L,QSA]

To prefer www instead, swap the second block for a rule that adds the prefix. Whichever host you choose, the site_url value in ow_base_config must match it exactly, or Oxwall will emit links to one host while the server 301-redirects to another, doubling the request count and risking a loop. Behind LiteSpeed on shared hosting the %{HTTPS} variable is set correctly for terminated SSL, so the HTTPS rule above works without proxy-header workarounds. If you administer other CMS platforms and want a deeper treatment of SSL edge cases and mixed-content cleanup, the walkthrough on UNA HTTPS & SSL on shared hosting covers proxy awareness patterns that translate directly.

Issue your SSL certificate first. In cPanel use Security → SSL/TLS Status and run AutoSSL, or in DirectAdmin open SSL Certificates and request a free Let's Encrypt certificate. Only enable the forced-HTTPS rule after the certificate is active, otherwise visitors hit a browser security warning on every request. After switching, load a profile page and open the browser console to catch mixed-content warnings from theme or plugin assets that hardcode http://; those are usually fixed by correcting site_url and clearing the template cache.

Sitemaps, 404 handling, and ongoing hygiene

Oxwall does not generate an XML sitemap in its core, so search engines rely on crawling internal links. You can help them by exposing a clean structure and handling errors gracefully. First, set a custom error page so broken links return a useful response instead of a bare server error. Add this near the top of .htaccess, above the routing rules:

ErrorDocument 404 /index.php?/base/error/404

Oxwall's router recognizes the base/error/404 path and renders a themed not-found page, keeping visitors on-site and returning a proper HTTP 404 status that crawlers respect. Avoid pointing the ErrorDocument at your homepage, since a 200 response for missing content creates soft-404s that confuse indexing.

For a machine-readable sitemap, the most reliable approach on shared hosting is a lightweight static sitemap.xml placed in your Oxwall root and updated periodically. List your stable, high-value paths — the homepage, main sections, and popular group or event pages — using absolute canonical URLs that match your chosen host. Because the file is a real file on disk, the !-f condition in your rewrite block serves it directly without passing through Oxwall's router. Submit it in Google Search Console under the domain property, then confirm coverage over the following days. If your community grows large and you want dynamic generation, several Oxwall plugins from the store add sitemap output; install them through Plugins → Add New in the AdminCP rather than uploading files manually, so dependency and permission handling stays intact.

Two hygiene practices keep the setup stable. When you diagnose a rewrite problem, watch the per-account error_log that appears in your Oxwall root or in the cPanel Errors interface; a 500 from a bad directive and a rewrite loop each leave distinct entries there. And whenever you change the domain, move the install, or toggle friendly URLs, treat site_url, RewriteBase, and the template cache as one unit — update all three together and clear the cache last. Keeping those three in agreement eliminates nearly every friendly-URL and canonical redirect issue Oxwall throws on a shared account.