Fancy permalinks should be enabled on new sites

[Denis-de-Bernardy]

Code to do this:

$permalink_structure = '';
$cat_base = '';
$tag_base = '';

if ( got_mod_rewrite() && is_file(ABSPATH . '.htaccess') && is_writable(ABSPATH . '.htaccess') )
{
	$permalink_structure = '/%year%/%monthnum%/%day%/%postname%/';
}

update_option('permalink_structure', $permalink_structure);
update_option('category_base', $cat_base);
update_option('tag_base', $tag_base);

$wp_rewrite->flush_rules();

The above has been tested by hundreds of users -- this has been built into my theme for over two years.

Moved to 2.7.. I doubt it will be added to a maint. release. Can be moved to 2.6 if there is a patch added.

turns out the above code stopped working with wp 2.5

corrected code recreates wp_rewrite before flushing:

$GLOBALS['wp_rewrite'] =& new WP_Rewrite();
$GLOBALS['wp_rewrite']->flush_rules();

I think the "update" lines should be within the if block, otherwise you are calling them unnecessarily on servers that don't have the rewrite functionality.

Do you really think this is needed? If you want it enabled, then what for is the permalink setting page? Leave it to the user. This should not be forced on users.

Do you really think this is needed? If you want it enabled, then what for is the permalink setting page? Leave it to the user. This should not be forced on users.

Do you really think this is not needed? If you dont want it enabled, then simply go to the permalink settings page? Set defaults to the most commonly used settings, make life easier for users.

(Kinda sarcastic there btw)

I've always wondered why fancy permalinks are not enabled by default, Granted, They're not hard to enable, And its simple to tell if its going to work (in most cases). I guess the fact it relies on the .htaccess being listened to is the main reasoning why its not, afterall, there are other web servers than apache.

If this is going in then it just needs patchifying really. I'd do it myself but I've no idea which file this would belong in.

@mrmist: maybe in wp-admin/includes/upgrade.php, in function wp_install()

wp-admin\includes\upgrade.php diff

Attached patch containing code suggested above.

Tested against stock 2.7 on a php5 / apache system and worked as expected (pretty permalinks on). Could probably do with a quick check on a rewrite system I guess.

attachment upgrade.diff added.

Questions:

• Why is not everything inside the if block?
• Why update the tag/cat base? They're just being set to the default anyway
• Is a reference really required for the WP_Query object?

Alternate version of patch with DD32's comments in mind

@DD32: The reference was for old issues on the shutdown hook. I take it they've probably been fixed since.

tried upgrade_v2.diff on the nightly build and seems to work fine.

After flushing, we should check to make sure .htaccess exists and that it actually contains rules. If not, use unfancy links.

Also, use $wp_rewrite->set_permalink_structure(). You won't need to update the option or create a new WP_Rewrite option then.

done

Replying to ryan:

After flushing, we should check to make sure .htaccess exists and that it actually contains rules. If not, use unfancy links.

won't this achieve this already?

is_file(ABSPATH . '.htaccess') && is_writable(ABSPATH . '.htaccess')

won't this achieve this already?

That only checks the file exists, Not that it contains the correct rules, Nor does it check that the web server abides by those rules.

The check in my mind should be a HTTP Request to a rewritten URL, That'll ensure that the rules have taken and the server supports it.

Replying to DD32:

won't this achieve this already?

That only checks the file exists, Not that it contains the correct rules, Nor does it check that the web server abides by those rules.

The check in my mind should be a HTTP Request to a rewritten URL, That'll ensure that the rules have taken and the server supports it.

I would have hoped that, if the file is writable it would get written. but yeah, there are servers out there that do this wrongly. then again, these won't get caught by settings / permalinks either, will they?

I would have hoped that, if the file is writable it would get written.

Yeah.. you'd hope so..

then again, these won't get caught by settings / permalinks either, will they?

Nope, But thats beside the point, It should check it there as well (That was mentioned many moons ago too..). But more of the fact, Since this is a default, It needs to default to something that DOES work, non-fancy permalinks always do work, which is why they're the defacto standard, To change it, The checks need to make absolutely sure they work IMO

the updated patch moves the burden of making sure things got changed to the save_mod_rewrite_rules() function.

oh, I think I found the ticket where writable htaccess files don't get written: #9246

Maybe do a head request on get_permalink(1) and make sure it doesn't 404?

or we could simply make sure that the file_get_contents(ABSPATH / .htaccess) contains the relevant rules, but the real point is: what should happen when the rules are not contained.

it could have two reasons:

• file is not writable
• file is writable but we failed to write to it

we currently manage the first, but not the second.

Punting due to time constraints, will consider in next release cycle.

What about offering (a basic) Permalink Config with the Installer? This could enable it as well and if something goes wrong it is not that problematic. Compare to if the Installer fails to init the DB.

moving this to future. maybe someone will give it some love.

amazing how these new reports lead straight to bugs that need attention.

See aso #12404 and #12405, with an extra discussion on using query string based permalinks

I ended up closing #12404 as a duplicate, with some thoughts included in a comment there.

Since #16687 is now done that stops the basic /%postname%/ having a performance penalty, and r18547 adds the option to the UI, would it make more sense for default permalinks to use this most simplified pretty permalink format available, rather than something with extraneous time-based components?

#22147 was marked as a duplicate.

Replying to GaryJ:

Since #16687 is now done that stops the basic /%postname%/ having a performance penalty, and r18547 adds the option to the UI, would it make more sense for default permalinks to use this most simplified pretty permalink format available, rather than something with extraneous time-based components?

I'd agree with that. Anything blocking this patch from being committed?

Since this patch came out, nginx has risen to be a common use case (vs edge). We're not even auto-inserting/suggesting the conf rules yet. Not to mention iis.

It certainly seems possible to get this up for .htaccess, but we're leaving the others out in the cold.

I haven't dug into the actual .htaccess/server part of rewrite, but I imagine we have solutions that work on nginx and iis? Just use those once we've detected the web server platform?