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'?

[wpmuguru]

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

[wpmuguru]

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

[Denis-de-Bernardy]

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.

[wpmuguru]

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/

[djio]

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?

[nacin]

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

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

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

[djio]

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!

[wpmuguru]

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.

[djio]

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.

[wpmuguru]

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.

[wpmuguru]

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

[kawauso]

'ms_blog_prefix' filter

[kawauso]

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.

[djio]

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

[kawauso]

As before, no unclosed comment block

[kawauso]

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

[jeremyfelt]

It'd be fun to start doing something with collision detection here with the side effect of ditching the /blog prefix.

12002.4.diff​ is a refresh of the patch from 2 years ago. I haven't had a chance to fully test it yet.

[ocean90]

#29039 was marked as a duplicate.

[SergeyBiryukov]

#30712 was marked as a duplicate.

[karincom]

Replying to SergeyBiryukov:

#30712 was marked as a duplicate.

Thank you indeed for the work you are doing.

Wordpress Multisite -> Subfolders Installation -> Permalink Structure

Being unable to find a way to replace the '/blog' slug in root domain, I am using a cron job to update the rewrite rules as work around ('/blog' to '/en').

SQL QUERIES... /blog to /en slug on root blog, multisite, subfolders installation

UPDATE bb_options
SET option_value=replace(option_value,'blog/','en/')
WHERE option_name = 'permalink_structure';

UPDATE bb_options
SET option_value=replace(option_value,'blog/','en/')
WHERE option_name = 'category_base';

UPDATE bb_options
SET option_value=replace(option_value,'blog/','en/')
WHERE option_name = 'tag_base';
 
UPDATE bb_options
SET option_value=replace(option_value,'blog/','en/')
WHERE option_name = 'rewrite_rules';

It is working beutifully in my site.

So, '/blog' slug is hardcoded for the root blog.
But... it is very easy to change, so, it should be easy to create such parameter.

REQUEST
Why not include such parameter in wp-config.php? At least for subfolders installation.

if (empty($parameter)) {$parameter='blog/';}

So, not allow it to be empty, for avoiding collisions or things like that.
Just ideas... eventually not that easy.

THanks for reading this.

[MeharBhagat]

Works for me on WP version 4.1

wp-admin -> options-permalink.php ->

if ( is_multisite() && !is_subdomain_install() && is_main_site() )
	$blog_prefix = ''''/blog'''';

Change '/blog' to '/AsYouWish'

[karincom]

Replying to MeharBhagat:

Works for me on WP version 4.1

wp-admin -> options-permalink.php ->

if ( is_multisite() && !is_subdomain_install() && is_main_site() )
	$blog_prefix = ''''/blog'''';

Change '/blog' to '/AsYouWish'

Even simpler:

if (empty($blog_prefix)) {$blog_prefix = ''''/blog'''';}

Now, we need a place to entry $blog_prefix parameter:

a) wp-config.php
b) Super-Admin Dashboard -> General Settings.

$blog_prefix input interface (for root blog) can be only seen if is_multisite() && !is_subdomain_install(). For other blogs (not the root one), you always see that interface.

It should work... and it looks like a simple udate.
Currently, my cronjob works beutifully. Of course, just a workaround.

[apsolut]

any way we can use

if ( is_multisite() && !is_subdomain_install() && is_main_site() )
	$blog_prefix = ''''/blog'''';

inside functions.php, so we dont edit core files ?

[jjabba]

Is there any progress on this issue? I would love to be able to change the /blog/* slug on the main blog in my newly installed network. I know a bit of php so perhaps I could help out?

[atomicjack]

Replying to jjabba:

Is there any progress on this issue? I would love to be able to change the /blog/* slug on the main blog in my newly installed network. I know a bit of php so perhaps I could help out?

Feel free to do so - use version control to create .diff or .patch files to show the modified code.

[QROkes]

As a temporary solution, this works very well:

​https://github.com/dasllama/Remove-Blog-Slug

[jeremyfelt]

Some notes after staring at this for a bit:

• You can change the /blog prefix on the main site now by updating the Permalink Structure through wp-admin/network/site-settings.php. This will work, but then break as soon as permalinks are modified in the site's wp-admin/options-permalink.php because that page forces the /blog prefix on everything for the main site.
• I don't think this ticket is necessarily about collision detection. We should address that separately. There are a handful of related tickets out there. #11766, #13459. #24776 is probably the best for overall description of need in the global context.
• I think it's okay if /blog is still set as the default during network setup.
• I don't think we need a new filter to manage this.

To address the issue in this ticket, we need to make it possible to change or remove /blog in the permalink structure for the main site.

This seems to mean checking for /blog at the beginning of the existing permalink structure for the main site. If it exists, continue to enforce it whenever permalinks are updated. If it doesn't, defer to the decision made by the network admin through site-settings.php.

[jeremyfelt]

12002.5.diff enforces the /blog prefix only when the /blog prefix is currently part of the permalink structure on the main site.

[jeremyfelt]

In 34749:

MS: Provide better UI when a main site's /blog prefix is changed.

The main site on a new network is forced by default into using /blog as the prefix for its permalink structure. This can be changed easily through the network admin, though the options-permalink.php screen is then unusable to make further changes to the structure.

Now, if /blog/ is not at the beginning of the permalink_structure option, we do not force /blog as a prefix in the UI.

Fixes #12002.