General Settings Tab Not Allowing trailing URL slash to be stored in Site & WordPress address (URL)

[dsquared]

Thank you for all of the efforts you've made regarding plugins easier to maintain - I deeply appreciate it.

When WordPress is installed in a subfolder, attempts to add the trailing slash currently will not save properly. From this URL:
​http://www.domain.com/wordpressinstalledinfolder/wp-admin/options-general.php

The General Settings Tab - WordPress address (URL)
The General Settings Tab - Site address (URL)

Want to enter "​http://www.domain.com/wordpressinstalledinfolder/"
*it won't let me enter a trailing slash on the end like it will in other URL fields on the site.*

Request: Please tweak this field to allow storage of folder trailing slash.

[dd32]

This is the expected behaviour. The path is not supposed to include the trailing slash, the slash is added to links automatically.

[dsquared]

Replying to dd32:

This is the expected behaviour. The path is not supposed to include the trailing slash, the slash is added to links automatically.

Actually it is not normal and a trailing lash is the typical seen around the web. It is also the typical anticipated behavior as WordPress allows the storage of these slashes across other parts of the site - Blogroll, etc. Consistency in data formats are highly important.

It also causes a serious SEO issue as the URL and the years of links pointing to it have the trailing slash via a 301.

Thank you for reconsidering this request.

[billslawski]

The problem isn't whether you can include a trailing slash in the blogs setting, but rather that it seems that when a blog is set up in a subdirectory that the slash isn't added to links automatically the way that it is when the blog is located in the root directory.

Instead the server is adding a trailing slash via a 301 redirect. That's not the behavior in WordPress when a blog is in the root directory.

[demetris]

@dsquared, @billslawski,

Do you see this issue with links generated by WP itself or by Twenty Ten?

As far as I know, the functions for generating a home URL do not append the trailing slash automatically, which can lead to the 301 issue when WP resides in a subdirectory. But the trailing slash can be specified. The recommended function to show the home URL is home_url(), which in Twenty Ten and in core is used like this:

home_url('/')

There is also get_home_url(), which can be used like this:

get_home_url('', '/')

I am not sure this is the most intuitive way, but it is more or less standard in core and it works as it supposed to.

[dd32]

Instead the server is adding a trailing slash via a 301 redirect. That's not the behavior in WordPress when a blog is in the root directory.

That sounds like a theme is using the siteurl option directly without suffixing it as it is supposed to do. alternatively, using the new API's would also solve that problem. Demetris has hit it on the head as to the functions to use.

I do however agree with you, It would make more sense for the value in the field to always be trailingslash'd, however, for compatibility with WordPress, stored without a trailing slash.. This is simply due to the fact that people expect to see the trailing slash.

I'm setting to future release purely based on the previous paragraph, but some UI feedback on if displaying it like that would be appropriate needs to be answered too

[nacin]

Replying to dd32:

It would make more sense for the value in the field to always be trailingslash'd, however, for compatibility with WordPress, stored without a trailing slash.. This is simply due to the fact that people expect to see the trailing slash.

I second this.

[johnbillion]

If home_url() switches to returning a user-trailing-slashed URL, it'll break plugins and themes that are concatenating a path onto the end, eg.

home_url() . '/path'

instead of

home_url( '/path' )

Also it'll need to correctly handle sites that don't use a trailing slash on the end of the permastructure, as this affects all rewrite rules, not just permalinks.

[swissspidy]

Sounds like changing this would cause more harm than good for no great benefit.