Multisite should not lock the root blog into using a /blog prefix

[wpmuguru]

MU Trac Ticket: ​http://trac.mu.wordpress.org/ticket/409

I don't think WPMU should lock the root blog into using a /blog prefix on permalinks. Currently, the /blog on the beginning of permalinks is hardcoded.

I realise this was probably added to stop conflicts when not using a VHOST solution, but when using VHOST to put other blogs into subdomains, why lock the root blog's permalinks as such?

Could the /blog requirement be removed if VHOST is 'yes'?

The vhost configuration was addressed in ​http://trac.mu.wordpress.org/changeset/1104.

See http://core.trac.wordpress.org/ticket/11766 for additional considerations for patching this.

Adding the info from #11766:

avoid_blog_page_permalink_collision() only checks for collisions with static pages.

to avoid further potential collisions, it should add an additional filter, to start with. and it should also try:

• attachments in the event the main blog uses the /%postname%/ structure.
• categories, tags, etc in the event a plugin strips their respective stubs
• anything that is not a post, page, attachment or revision, and which has no parent.

Comment from #11766:

Replying to wpmuguru:

If custom permalinks are using in MU folder install /blog is added to the beginning of the permalinks base (ex. /blog/%postname%/) on the main blog.

The only blog collision that might occur is with pages because they are not offset with /blog. In a non-vhost install:

page name on the main blog -> news -> ​http://domain.com/news/
blog name -> news -> ​http://domain.com/news/

Just to pont a real life situation:
Where I come from, and I mean Brazil, major companies block some words like hot, sex, porn, fuck, and also blog to avoid waste of employees labor time with "minor distractions". So, the employees can't access blogspot and so, but they can't also access their own company's posts because of the infamous mandatory /blog/ prefix

I don't mean creative or development companies, but any other market or industry. It's sad but true. I encounter myself in the position of a long-time developer facing this same problem over and over: when I offer Multisite solutions using WP to my clients I must always ask how is their proxy/firewall policy agains the 'blog' word, and most of the time people won't change the policy so I must find another solution. I believe that in this case hardcoding a solution will never be a solution, because I'll lose it in next WP update.

My idea for a solution is to set this "compatibility mode to avoid conflicts" as an option in the main settings page. In addition the word 'blog' should be optional too, if I prefer 'news' instead (or any other), there would be no problem with proxies, blockers, etc.

As a conclusion, each scenario is different, we cannot impose a (commonly blocked) word as a mandatory prefix if we want to keep growing in the professional market.

---

I tried removing the /blog/ completely in the code but my website just ignores it, please check
​www.djio.com.br in the categories sidebar widget: every category has a /blog/ prefix and it doesn't work if a manually remove the prefix i the URL.

I usually help the community with Localizations of WP Core and Plugins (GlotPress, etc.) but I didn't want to mess with anything submiting a patch without knowing exactly the implications, so I ask, what exactly files deal with /blog issue?

"Version" is the earliest version something affects. In this case it would be MU, or 3.0.

This is, at its core, a Multisite ticket.

I'm changing back the title, as it was more descriptive previously.

I'm removing the severity, as this is not a blocker for release. You *can* remove /blog/ completely at the moment, it's collision detection that's missing. Indeed, this is an enhancement, not a bug.

Looking forward to 3.3 - what if the /blog was only forced when a custom structure is used? If the permalinks are set to any of the presets, then a clash with pages is extremely unlikely.

That would be relatively light changes compared to doing a complete rework. I'd be up for it for early 3.3.

Thanks again for the enlightenment, Nacin!
=)

wpmuguru, I usually use /%category%/%postname%/ with some serious cache activated.
But if I heard right, this structure today uses lots os process in the server side and might be avoided.

This would be a bonus to have this set as a preset, I found this permalink structure very effective to SEO.
Is there any chance you consider dealing with this to 3.3?

Thanks in advance!

Replying to djio:

wpmuguru, I usually use /%category%/%postname%/ with some serious cache activated.
But if I heard right, this structure today uses lots os process in the server side and might be avoided.

This would be a bonus to have this set as a preset, I found this permalink structure very effective to SEO.

Sorry, I was not suggesting that we add presets. I was referring to the presets that are currently there. The /blog is there to prevent collisions when a custom structure like /%category%/%postname%/ is used.

Adding a range of presets similar to that one would not alleviate the collision issue. Nor would it address the potential performance issues associated with some custom structure choices.

Replying to wpmuguru:

Adding a range of presets similar to that one would not alleviate the collision issue. Nor would it address the potential performance issues associated with some custom structure choices.

I undestand they are separated issues... maybe I didn't put it right.

It seems you are familiar with this part of the core, so I was asking if you could deal with this performance issue while using custom permalink structures as well. But this is another task and probably there's already a ticket for it.

Thanks for the respondes.
Look forward to the next version.

Replying to djio:

It seems you are familiar with this part of the core, so I was asking if you could deal with this performance issue while using custom permalink structures as well. But this is another task and probably there's already a ticket for it.

The performance issue with some of the custom structures exists in single WP sites as well as networks and is completely unrelated to the /blog issue which is subdirectory network specific.

Replying to wpmuguru:

Looking forward to 3.3 - what if the /blog was only forced when a custom structure is used? If the permalinks are set to any of the presets, then a clash with pages is extremely unlikely.

This is out as a potential solution - super admins can create blogs that are just numbers (ex. 2011).

'ms_blog_prefix' filter

Attached patch with what headway I've managed to make on this.

It introduces a 'ms_blog_prefix' filter which defaults to '/blog', as well as simplifying avoid_blog_page_permalink_collision() and forcing it to check any post types that aren't public rather than just pages. The various permutations of permalinks, the odd structure of attachment permalinks and any kind of taxonomy aren't accounted for.

Thanks kawauso for the patch!
Hope it be revised and published sometime before 3.3.
=)

As before, no unclosed comment block

Last patch somehow ended up with an unclosed comment block. Marking ticket as needs-patch again after chatting to westi as it still needs work to cover:

• Attachment permalinks (that change depending on whether they're attached, though they could just always be checked)
• Taxonomy slugs
• Custom permalink structures
• Any other permalink bases used by the main site