Cancel

Sarah Gooding

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

photo credit: gordon2208 - cc
photo credit: gordon2208 – cc

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.

Category: ,
Tags:
35

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.

      • I see where you’re coming from and once things are added to the core of WordPress, especially UI, it’s near impossible (not impossible) to remove.

    • 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.

      • Yep, that’s the one killer reason why it’s a good idea NOT to remove the options from core thus, they’ll probably always be there.

  3. 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.

  5. Agree with Hugh. Choice of format on install would be ideal. But it’s nice to see them do something rather than nothing on this little issue.

  6. How would this affect multisite installations already running? My customer requires ugly permalinks, and we have new sites created almost daily.

    • Oh, hang on. Are you maybe asking about future sites on multisite? I assume they will use whatever it defaulted to before, but I’m not certain.

      • Ryan – That’s exactly what I was asking. We require ugly permalinks on all current and newly created sites on our multisite installation.

  7. I wonder why the newly elected default setting is the one with the date in it? …can’t help thinking that including the date is a bad move for the majority of users and it would be better to just go with ‘postname’… :(

  8. Forgot to mention: “The new function is the result of a ticket that was originally opened seven years ago.” – so it didn’t take long then?! Lol

  10. 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.

  11. Sounds good to me since it’s one of the first things that I change on all new installs.

    And then as Jeff suggests “In my experience, permalinks are one of those settings in WordPress that are set and forget.”

    • 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.

      /%year%/%category%/%post_id%/%postname%

      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.

  16. For the past 2 years, I have not read a blog post with the ugly link so i was beginning to wonder why in recent updates, this point is not addressed.

    good to know 4.1 has it sorted out ;)

  17. We run a multisite setup and ours default to /postname/ so I’m agreeing with the others in that , if it’s between postdate and postname, I’d much rather prefer postname

  21. 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

  22. Thanks for the post! I had a problem with my permailinks and this article was helpful. I appreciate you putting this out here for us

You may also like

Newsletter

Subscribe Via Email

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

%d bloggers like this: