'with_front' => false

[mannieschumpert]

Just a suggestion: Maybe as an option, allow users to choose 'with_front' => false in the custom post type registration for sites that include /blog/ in the permalink settings.

[scotthack]

I'm not familiar with this. We'll look into it and see what/where this would be used.

[mannieschumpert]

It's part of the 'rewrite' array in the custom post type registration. So, line 339 of bracketpress.php would be 'rewrite' => array( 'slug' => $this->bracket_slug, 'with_front' => false ),.

Or, if you set it as an option, it'd look more like 'rewrite' => array( 'slug' => $this->bracket_slug, 'with_front' => $this->with_front_option ),.

[scotthack]

I'm not 100% clear on the function. This would allow for the following rewrite? domain.com/blog/bracket-name instead of domain.com/brackets/bracket-name ?

[mannieschumpert]

Close. If a user has their permalinks set to something like /blog/post-name/, by default a bracket's permalink would be mysite.com/blog/brackets/bracket-mybracket/. With 'with_front' => false, the permalink would be mysite.com/brackets/bracket-mybracket/.

It's an aesthetic choice that, admittedly, is a bit of an edge case, because there aren't that many users who would set their permalinks that way. However, the 'with_front' option has no effect on standard permalink settings, so wouldn't hurt anything if it was set by default.

(It came up for me because I was using the plugin for a client who did have their permalinks set that way.)

[scotthack]

Thanks! We'll certainly look into that. Please keep the suggestions coming. We'd really like to have the core part of this plugin have some community development help.

[ntemple]

I think the appropriate short-term solution here is to fun a filter during setup to let an external piece of code modify the rewrite rules before they are registered. I'd go ahead and add with_front across the board, however that may break backwared compatibility.

We can do that pretty quickly.

[kraftbj]

I think overall the 'with_front'=>false makes a lot of sense. Perhaps adding a checkbox to the settings that would allow it to be set to true if a user really wants it?

[ntemple]

I agree it should be the default.

Unfortunately, if we make that change today, it could break existing sites during the tournament.

We also don't want to clutter up the UI with all possible WordPress options. So what I suggest in the next version (after the tournament is):

a) make with_front=>false the default b) add a filter so people can turn it back back on if they need to with a simple plugin, or even create a UI to do so if necessary.

Does this coincide with your thinking?

On Thu, Mar 21, 2013 at 2:20 AM, Brandon Kraft notifications@github.comwrote:

I think overall the 'with_front'=>false makes a lot of sense. Perhaps adding a checkbox to the settings that would allow it to be set to true if a user really wants it?

— Reply to this email directly or view it on GitHubhttps://github.com/ntemple/bracketpress/issues/4#issuecomment-15221362 .

Nick Temple, CEO www.intellispire.com

Click Here to Learn More About Nick http://www.linkedin.com/in/nicktemple

[kraftbj]

I would go as far as saying nothing besides critical bug fixes should be released during the tournament!

The simple plugin or add_filter to functions.php makes sense enough. Scott mentioned the next year version would make it easier for non-devs, so I was thinking along that line re adding the option.

I'm not sure offhand if there's a way to detect if a front is set and, if so, then display the option. Keep the interface clean for the majority and only offer it for those who are in that particular group.

Another idea is to have an "advanced settings" plugin. Anything like this that is nick-picky can be thrown in there, so tutorials/support forums/etc dealing with these issues can just point to exactly what to change in that. Devs can still use filters via code, non-devs can follow instructions w/ the advanced settings plugin. Just thinking that, depending on how many of these little things come up, it might be a bit burdensome to have a large number of simple plugins.

Great plugin; looking forward to seeing it evolve.

[mannieschumpert]

FWIW, I agree that using a filter that devs would include is probably the best route. It seems a rather trivial thing to include in the options interface, and most users wouldn't even comprehend the purpose of the option.