Redirects

Because the VIP Platform uses NGINX (not Apache), there are no .htaccess files. Redirects for URLs must be handled with alternative methods. The most suitable solution(s) for a site’s redirects should be chosen based on the amount and types of redirects needed.

• Redirects with a 302 HTTP response status are cached by the page cache for 1 minute, and redirects with a 301 HTTP response status are cached for 30 minutes.
• Some redirects can be written directly into a site’s theme code.
• To use more than one domain per site, set up vip-config.php to redirect secondary domains to a desired primary domain. This is particularly useful for mapping domains on a multisite, where redirects between non-www domains and www variants do not occur automatically. 

Plugins for handling redirects

• The Safe Redirect Manager plugin is useful for managing a small number of redirects (fewer than 250), and for redirects that will change frequently. Safe Redirect Manager also allows the use of wildcard or regex in redirects.
• The WPCOM Legacy Redirector plugin is designed for managing a large number of redirects (greater than 300) for inactive legacy URLs that now return a 404 HTTP response status code.

Redirects for files

Redirects cannot be configured for any URLs that include /wp-content/uploads/*. The VIP File System, which resides upstream from application code, serves all files at that path. A reverse proxy is a possible solution for making a static asset available at a specific URL.

By default, redirects and custom rewrite rules cannot be configured for any assets that match the regex \.(css|js|jp(e)?g|gif|png|swf|ico)$, regardless of the file’s URL. NGINX will return a 404 for requests for any file URIs that match that regex and do not exist within the VIP File System path (i.e. /wp-content/uploads/). It is possible to request VIP Support to disable this default behavior, and instead allow these types of requests to fall back to application code. Custom PHP logic can be added to application code to capture and rewrite the request (301 moved permanently) to another path that does exist. This alternative method can be useful capturing non-compatible paths for images post-migration, for instance.