WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 8 years ago

Last modified 7 years ago

#11279 closed enhancement (worksforme)

Support for putting all "blog" content under /blog/

Reported by: mikeschinkel Owned by: ryan
Milestone: Priority: low
Severity: minor Version:
Component: Permalinks Keywords: dev-feedback
Focuses: Cc:

Description

Here's another URL related issue. For the longest time I've wanted to move everything blog related (i.e. not "Pages") including tags, categories, and posts under the "/blog/" URL path. Let me explain with hypothetical URLs:

example.com/products/
example.com/support/
example.com/about/
example.com/contact/
example.com/blog/
example.com/blog/category/{category_slug}/
example.com/blog/tag/{tag_slug}/
example.com/blog/{year}/{month}/{post_slug}/

You'd think this would be easy but unfortunately it has been a very elusive beast.

I met Matt at WordCamp Birmingham and he proposed a(n ugly) hack. The hack required moving everything index.php and wp-config.php into a /wp/ subdirectory and then in index.php I changed the require link to:

require('./wp-blog-header.php');

And added this in wp-config.php:

define('WP_SITEURL', 'http://example.com/wp');

It worked, except for it broke the media uploads (I didn't learn that until much later, and who knows what else it breaks?)

This shouldn't be so hard, don't you agree?

Can we make this work without an ugly hack, i.e. as an option in the admin console (and w/o having to move code to non-standard locations?)

Is there any will to add support for this pattern into core itself?

Change History (14)

#1 @mikeschinkel
10 years ago

Oops, that was suppose to say:

require('./wp/wp-blog-header.php');

#2 @Denis-de-Bernardy
10 years ago

  • Component changed from General to Permalinks
  • Keywords reporter-feedback added; blog posts urls url path removed
  • Milestone changed from Unassigned to Future Release
  • Owner set to ryan

that /wp/ hack sounds very odd.

doesn't this work?

  1. create/publish a static page and a blog page.
  1. set the permalink structure to /blog/whatever/you/want/
  1. set the category and tag stubs to blog/category and blog/tag

it may turn slow (since verbose rules would end up being used) but I can't see any reason why it shouldn't work...

#3 @dd32
10 years ago

What denis said should work.

I do exactly that on a regular basis for non-blog oriented WordPress sites. Except, I dont set the category/tag stubs, as they seem to get set automatically sometimes..

#4 @dd32
10 years ago

  • Milestone Future Release deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Setting Home/Blog to static page and prefixing the permalinks with /blog/ works for me. Theres no reason to change the category/tag stubs as if the permalink structure starts with a constant, thats prefixed to the cat/tag stubs anyway (Unless you change them, THEN you need to preix, ie. 'blog/section' for cats)

If this does not achieve what you want, re-open with the deficincies in the setup.

#5 @mikeschinkel
10 years ago

  • Priority changed from normal to low
  • Resolution worksforme deleted
  • Severity changed from normal to minor
  • Status changed from closed to reopened

Hi Guys,

Turns out that what you suggested *seems* to work but it's hard to no for sure until I have a chance to test all aspects of the site. If I find an issue with it I'll return with the details. I apologize for opening the ticket unaware that there was actually a way to accomplish this.

That said, I was not aware of how the blog posts setting worked. I think what threw me was how it ignores the the template and the content for the page with the slug "blog." Does it not seem counterintuitive? Wouldn't it make more sense to instead ask for a path slug for the posts page in the Permalink section rather than for the user to have to create a dummy page none of which is actually used? I think this would be a lot more obvious for the average user and especially the beginning user.

I've reopened in case this is something you'd consider; if not then just close it as you have given a workaround.

#6 @dd32
10 years ago

  • Keywords dev-feedback added; reporter-feedback removed
  • Milestone set to Future Release

I think what threw me was how it ignores the the template and the content for the page with the slug "blog." Does it not seem counterintuitive?

I can see where you're coming from.. And its a bit strange at first for some. Another way to look at it, is that its not a page, Its a Static place holder.

Pages can have templates applied to them, Templates are often used to ignore the content of the page and serve something different.

But the main advantage of having the 'Blog' place holder page, is that it then appears in all the Page menu's, Theres no hacking to add it in, it just works..

If you dont want to have a speciic "Blog" page, then you can simply set a static front page, and leave the Blog page blank, That requires that your theme lists the posts somewhere for you though, as you no longer have a "posts" page, which comes in handy for situations where the website has a custom "News" secion built into it, such as a sidebar widget or a footer.

I'm going to leave this open for now with with some dev-feedback, The method works, but do other dev's think it could be made easier perhaps? (Seting to future release pending change suggestions or closure)

#7 @mikeschinkel
10 years ago

@dd32: Good points, and yes I do see how using a Page makes the menu easier.

Something to consider as custom post types are added: maybe there's a "placeholder" type that can be used for when content is not needed? For example, I have in my own sites where I use a page template to let the user enter a URL redirect both for internal and external redirects. Would be nice to have ability to create a first class page for adding those.

Which broaches a broader subject and that's making "post type" features more atomic (where "post type" includes "Posts", "Pages" and custom post types.) It would be really nice to be able to define the feature sets that a given post type would include, i.e. templates, tags, categories, title, body, custom fields, etc. etc. Pages and Posts could default to what they currently have now, but if I wanted to use tags for pages then I could just add that feature to the Page type definition.

If I need to peel either of these issues off as separate trac items please suggest the best title so that the community would best know what I am referring to.

#8 follow-up: @dd32
10 years ago

Which broaches a broader subject and that's making "post type" features more atomic

That has actually started being implemented in a way, Have a look at [11998] and with #9674 coming along for 3.0, Should make it much easier. - Best to take any more discussion related to that over there

A placeholder content type could be of use, I'm not sure its used by core often enough to require a first-class item yet though.. This is certainly a use of it however.. Maybe revisit it after #9674 has been implemented?

#9 in reply to: ↑ 8 @mikeschinkel
10 years ago

Replying to dd32:

That has actually started being implemented in a way, Have a look at [11998] and with #9674 coming along for 3.0, Should make it much easier. - Best to take any more discussion related to that over there

Nice!!!

A placeholder content type could be of use, I'm not sure its used by core often enough to require a first-class item yet though.. This is certainly a use of it however.. Maybe revisit it after #9674 has been implemented?

Sounds like a plan.

#10 @nkuttler
9 years ago

  • Cc wp@… added

#11 follow-up: @mikeschinkel
8 years ago

This has been handled.

#12 @mikeschinkel
8 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

#13 in reply to: ↑ 11 @ocean90
8 years ago

Replying to mikeschinkel:

This has been handled.

By which ticket? Better resolution would be worksforme or duplicate.

#14 @ocean90
7 years ago

  • Milestone Future Release deleted
  • Resolution changed from fixed to worksforme
Note: See TracTickets for help on using tickets.