WordPress 4.2 Will Automatically Enable Pretty Permalinks for New Sites on Installation

photo credit: gordon2208 - cc
photo credit: gordon2208cc

WordPress 1.0 introduced search engine friendly permalinks using mod_rewrite. Setting your site to use pretty permalinks is usually one of the first things that administrators do after installation.

WordPress 4.2 will add a new function that will automatically enable pretty permalinks, if the server supports it, at the time of installation. This means that in most cases you’ll never be greeted with ugly permalinks again.

The new function is the result of a ticket that was originally opened seven years ago. In the upcoming release, pretty permalinks will be enabled if WordPress can verify that they work. It will cycle through the various permalink formats, and if they all fail to work, WordPress will fall back to ugly permalinks.

By default, WordPress will set the following permalink structure for a new site, if possible, using mod_rewrite or nginx rewriting: /%year%/%monthnum%/%day%/%postname%/

Under configurations without rewrites enabled, it will set /index.php/%year%/%monthnum%/%day%/%postname%/ for PATHINFO (“Almost Pretty”) permalinks.

Eric Lewis, a contributor on the ticket, commented on the upcoming change, “Delivering pretty permalinks by default seems in line with a bunch of core philosophies – great out-of-the-box, design for the majority, simplicity, clean, lean and mean.”

If you frequently create new WordPress sites or development sites, the automatically enabled pretty permalinks in 4.2 should save you a step in the setup process.


35 responses to “WordPress 4.2 Will Automatically Enable Pretty Permalinks for New Sites on Installation”

    • It would be interesting to know the most popular permalink structure(s).

      If a significant percentage of users use an alternative structure to the new default, like /%postname%/ or /%category%/%postname%/, making it a requirement for them to download a plugin to change that seems like a bad move.

    • Aside from the ability to change the permalink, don’t forget there is also another important use case of the Permalinks page.

      Flush rewrite rules to debug issues caused by plugins that return 404 for certain pages / new post types. Sometimes this happen because there is a conflict between two plugins.

      Usually an easy fix to that solution is: Go to your Permalinks page, don’t change anything, and simply click on Save Permalinks.

      This is huge help for beginners who don’t want to flush rewrite rules by placing a code in their functions.php file.

  1. This is great – stoked this is finally happening. It would be nice, however, to have the option of your preferred permalink structure as part of the install process – my reason being that I never use %day% in my permalinks and almost always just use %postname%, so even though this sets pretty permalinks, I will always still go and edit them on any production site. That obviously has the downside of adding another step to the installation process though, so not sure what the best solution is there.

    • In my experience, permalinks are one of those settings in WordPress that are set and forget. Once you have the ones you like, you never touch them again unless it’s part of the troubleshooting process. That’s an interesting idea to present the options on install and I don’t think it would be hard to explain what they are on the screen.

      This move is aligned with the decisions over options development philosophy but as you illustrate, WordPress doesn’t make the right decision for you.

    • This change is just about providing a better default for the majority of users. The change has a net benefit to inexperienced and first time users, and effectively makes no difference to those users who would change their permalink structure anyway.

    • I agree with Huge.

      When I read the title of this article I just knew that they would default it to a type that I never use. In 99.9% of the sites I’ve made and worked on, I only ever used just %postname%.

      I think it comes to the core team still treating WP as a blog instead of a CMS. I’d wish they’d get over that already.

  2. I for one just use the number id and sure hope I won’t be forced to change it in any way…

    And as a rule, always options, no decisions forced on users. Why I dread updating pretty much anything for the past several years and put it off as much as I can or even avoid it altogether, with this mindset being so common now.

    • I know they claim not to use %category% but I have used it like this. note post_id thrown in to make sure no identical links that may conflict.


      I don’t see a problem with this; however, unless you want to run buddypress or some other feature that requires permalinks, url rewrites, and caching, I would just leave the default on a small traffic site. No need in changing the default without good reason whatever that default may be.

  3. Perhaps the default is being set to be efficient with /%year%/%monthnum%/%day%/%postname%/ for cache plugins such as WP Super Cache that WP offers right next to JetPack as a top 5 add-on at installation. WP Super Cache can be set to ignore certain pages; “Add here strings (not a filename) that forces a page not to be cached. For example, if your URLs include year and you dont want to cache last year posts, it’s enough to specify the year, i.e. ’/2004/’. WP-Cache will search if that string is part of the URI and if so, it will not cache that page…” i.e. wp-.*\.php or index\.php


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: