• Resolved mummybot

    (@mummybot)


    I am trying to use the Webpack tool for managing my assets on my localhost setup. I have a virtual host set up for my WordPress site, and Webpack offers the ability to proxy a domain so that Webpack assets can be reloaded on the fly. See my issue on Stackoverflow for the the detailed Webpack and vhost set up.

    When running the Webpack dev server it is accessible at https://localhost:9090.

    When I set up the Webpack proxy to point to another vhost (test.dev) with an index.php and I visit https://localhost:9090 it displays the contents of index.php.

    When I set up the Webpack proxy to point to my WordPress vhost (wp.dev) and I visit https://localhost:9090 it immediately does a 301 redirect (looking in Chrome dev tools or Charles debugger) to https://localhost and serves whatever my computer has set at localhost instead. It appears WP is stripping the port from the URL, although I really have no idea what is going on.

    My environment is:
    Mac OSX El Capitan
    Apache/2.4.16 (Unix) default Mac version
    Wordpress: 4.4.2

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter mummybot

    (@mummybot)

    I have the default rewrite rules in my .htaccess file:

    # BEGIN W3TC Browser Cache
    <IfModule mod_deflate.c>
    <IfModule mod_headers.c>
    Header append Vary User-Agent env=!dont-vary
    </IfModule>
    <IfModule mod_filter.c>
    AddOutputFilterByType DEFLATE text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/html text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon application/json
    <IfModule mod_mime.c>
    # DEFLATE by extension
    AddOutputFilter DEFLATE js css htm html xml
    </IfModule>
    </IfModule>
    </IfModule>
    # END W3TC Browser Cache
    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>

    # END WordPress

    Thread Starter mummybot

    (@mummybot)

    The 301 is being served by Apache – see request/response below.

    General
    Request URL:https://tpbc.dev:9090/
    Request Method:GET
    Status Code:301 Moved Permanently
    Remote Address:127.0.0.1:9090
    Response Headers
    view source
    cache-control:no-cache, must-revalidate, max-age=0
    connection:close
    content-length:0
    content-type:text/html; charset=UTF-8
    date:Wed, 17 Feb 2016 12:20:31 GMT
    expires:Wed, 11 Jan 1984 05:00:00 GMT
    location:https://tpbc.dev/
    pragma:no-cache
    server:Apache/2.4.16 (Unix) PHP/5.5.30
    x-powered-by:PHP/5.5.30
    Request Headers
    view source
    Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
    Accept-Encoding:gzip, deflate, sdch
    Accept-Language:en-US,en;q=0.8
    Connection:keep-alive
    Cookie:wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_0e15adf49b0952e6bcf9eb9ad44d196c=mummybot%7C1456329666%7CmJXdoM5IBEKLGA8y1PIm23fcgqClZ8Ha9Oe68MGFE06%7Ccc11340ef4061903448380d32690acd2e01b682aca96e2a2bc0d5698c7bf95af; wp-settings-time-1=1455710985
    Host:tpbc.dev:9090
    Upgrade-Insecure-Requests:1
    User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36

    Thread Starter mummybot

    (@mummybot)

    Solved at Stackoverflow!

    WordPress uses canonical URLs to help normalize URLs for content from different sources:

    [Y]ou can’t control who links to you, and third parties can make errors when typing or copy-pasting your URLs. This canonical URL degeneration has a way of propogating. That is, Site A links to your site using a non-canonical URL. Then Site B see’s Site A’s link, and copy-pastes it into their blog. If you allow a non-canonical URL to stay in the address bar, people will use it. That usage is detrimental to your search engine ranking, and damages the web of links that makes up the Web. By redirecting to the canonical URL, we can help stop these errors from propagating, and at least generate 301 redirects for the errors that people may make when linking to your blog.

    This rewriting is what strips the Webpack-dev-server port number when attempting to proxy. The solution is to add in your theme/functions.php:

    remove_filter('template_redirect', 'redirect_canonical');

    We obviously don’t want this running on the live site, so add a variable to the wp_config.php to set depending on environment:

    wp-config.php

    // Toggle to disable canonical URLs to allow port numbers.
    // Required for Webpack-dev-server proxying.
    define('DISABLE_CANONICAL', 'Y', true);

    yourtheme/functions.php

    // Hack for Webpack dev server
    if (DISABLE_CANONICAL == 'Y') {
        remove_filter('template_redirect', 'redirect_canonical');
    }

    I have experienced issues with the browser “caching” the previous URL redirect, so when you make a change it may not appear immediately. Try opening the URL in incognito mode, using a different browser, or restarting the Webpack and Apache servers.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘WordPress through development proxy does 301 redirect’ is closed to new replies.