Opened 13 years ago
Last modified 5 years ago
#19627 assigned feature request
Themes should be able to opt-in to a static front page
Reported by: | nacin | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Themes | Keywords: | |
Focuses: | Cc: |
Description
A theme should be able to register that they are designed to have a static front page by default. Core should then pick up on this as part of the activation process and allow them to pick or create a page, or ignore it and show posts on the front.
Twenty Twelve will most likely need this (http://wpdevel.wordpress.com/2011/12/20/default-theme-twenty-twelve/).
Attachments (2)
Change History (81)
#20
@
13 years ago
19627-patch1.diff is an example of the latter. It allows a theme to register that it is optimized to be used with a static front page template by appending the following line to the theme's style.css file:
Front Page: static
#24
@
13 years ago
- Owner set to koopersmith
- Status changed from new to assigned
This came up in IRC today during the weekly meeting. It is going to be end up being super-simple.
add_theme_support( 'static-front-page' )
All this will do is add another section to the 3.4 customizer that lets the user know the theme explicitly supports a designed static front page, and offer the same dropdown already provided for at wp-admin/options-reading.php.
Assigning to koopersmith as this will have zero implementation outside of the customizer.
#25
@
13 years ago
My idea is to use something like add_theme_support( 'static-page' , array( 'front' => (ID|slug), 'posts' => (ID|slug) )
, the array is optional.
The Customizer will fetch this and shows the same dropdown menu as on options-reading.php
. The values, defined in the array, will be selected by default. If the user wants to use a static page, he/she just needs to check/confirm it.
#26
@
13 years ago
Perhaps the add_theme_support() call could allow for a description from the theme letting them know about their implementation. A distributed theme isn't going to be able to line up post slugs or IDs.
#28
@
13 years ago
Should we just support add_theme_support( 'static-page' )
for 3.4 and maybe extend it with 3.5 and Twenty Twelve?
The Customizer should, if the theme supports it, display the setting section for a static page .
#29
@
13 years ago
Any theme hypothetically supports a static front page already. I think the add_theme_support() call is only good for descriptive text as to what the theme does special when it comes to static headers (or an explicit "Your theme supports a static front page." line).
#32
@
12 years ago
Discussed at dev hack day at WCSF 2012, we are going to keep it at future release and not work on this for 3.5.
This ticket was mentioned in Slack in #themereview by chipbennett. View the logs.
9 years ago
#44
follow-ups:
↓ 45
↓ 47
@
9 years ago
Perhaps the add_theme_support() call could allow for a description from the theme letting them know about their implementation. A distributed theme isn't going to be able to line up post slugs or IDs.
What if theme author could declare the default template that static page should use in the add_theme_support
?
Themes with custom front page usually include special front page template, and users need to get out of Customizer and choose that template for the static page they just assigned as front page. What if theme author was able to suggest a default template for that page, that is applied automatically (but of course can be changed from page edit screen)?
#45
in reply to:
↑ 44
@
9 years ago
Replying to alex27:
Perhaps the add_theme_support() call could allow for a description from the theme letting them know about their implementation. A distributed theme isn't going to be able to line up post slugs or IDs.
What if theme author could declare the default template that static page should use in the
add_theme_support
?
Themes with custom front page usually include special front page template, and users need to get out of Customizer and choose that template for the static page they just assigned as front page. What if theme author was able to suggest a default template for that page, that is applied automatically (but of course can be changed from page edit screen)?
Wouldn't that be front-page.php
?
That's why using the template hierarchy correctly is important. If done correctly, the user doesn't have to select a custom page template.
#46
@
9 years ago
I agree with using front-page.php. But we need a way to combine it with a selectable posts page.
I also think static-front-page is the wrong name for this, since it doesn't have to be static, it could be a combination of whatever the theme author wants.
#47
in reply to:
↑ 44
@
9 years ago
Replying to alex27:
Perhaps the add_theme_support() call could allow for a description from the theme letting them know about their implementation. A distributed theme isn't going to be able to line up post slugs or IDs.
What if theme author could declare the default template that static page should use in the
add_theme_support
?
Themes with custom front page usually include special front page template, and users need to get out of Customizer and choose that template for the static page they just assigned as front page. What if theme author was able to suggest a default template for that page, that is applied automatically (but of course can be changed from page edit screen)?
I like this idea, what I consider important is to give freedom to authors to be able on a theme basis to suggest the default home template, we as theme authors knows what the majority of users expect/want from a specific theme.
I am excited to see this implemented!!
This ticket was mentioned in Slack in #themereview by codeinwp. View the logs.
9 years ago
This ticket was mentioned in Slack in #themereview by greenshady. View the logs.
9 years ago
#50
@
9 years ago
The frontpage.patch tries to add the option to select page templates for the frontpage setting. In this way you no longer need to create a dummy page for that template and assign it as a frontpage, you can just select from the available templates in the theme ( http://prntscr.com/7h8cmb ) . In order to do it i have added a new boolean parameter for wp_dropdown_pages, named "include_templates" that will show also the templates when is set to true.
A new feature that the patch is introducing is add_theme_support("custom-frontpage", "template_file"); which will enable developers to set by default a frontpage when the user is first installing the theme. Basically, if the theme has this support, on after_switch_theme action we will set the show_on_front = 'page' and page_on_front = "template_file" . We will also save the old values of those settings and we will rollback them when the theme is removed.
Let me know what do you think about this
This ticket was mentioned in Slack in #themereview by codeinwp. View the logs.
9 years ago
#52
@
9 years ago
I think selecting a page template, rather than an actual page, would be very confusing. It also really doesn't address the issue of no page being selected for the Front Page (or for the Posts page).
Other options:
- Have a separate dropdown select for page template (if the Theme provides custom page templates) to be selected to use with the Front Page.
- Add a "create new page" option to the existing dropdown-pages select for Front Page and for Posts Page. Selecting this option would create a new page, with a core-defined title, and core-defined post content (e.g. "This page was auto-generated for the front page" - or something)
- Similar to 2, omit "create new page" option, and if no page is selected, auto-create a new page, with a core-defined title, and core-defined post content (e.g. "This page was auto-generated for the front page" - or something)
#53
@
9 years ago
@Chip thank you for the comments!
I really think that the way how this is working now ( create an empty page, then select that page as frontpage) is just wrong, let's assume for a sec that you have just discovered WordPress today, do you find this logic easy to understand/use ) ?
Now back to your suggestions, which we also took into consideration when came with this solution :
- Is not very different to what we are doing, we can create another dropdown, but I am not sure I see the point, however any feedback is welcome
- This is a good idea, however what I don't like is that if the user is trying 3-4 themes, he will end up with x extra pages that need to be deleted
- Like 2, we have discussed this internally and this again might confuse the user, to auto-create content, however is still better that what we have at the moment
Would be happy to get other feedback and find a common solution :)
This ticket was mentioned in Slack in #themereview by codeinwp. View the logs.
9 years ago
#56
@
9 years ago
Any updates on this? It's been over 4 years now since this was opened, yet no changes :( ... what do you say about a message when the theme is changed/activated that will ask the user what is the purpose of the site,blog or something else? Depending on this the default settings will be set.
This ticket was mentioned in Slack in #themereview by codeinwp. View the logs.
9 years ago
#58
in reply to:
↑ 57
@
9 years ago
Any updates on this ? Would love to have it implemented (somehow or the other )
#59
@
9 years ago
I think authors should be allowed to create a page with title and content they choose and set it as their default front page. The current situation when every theme on wordpress.org looks the same should have been resolved a long time ago. WordPress is no longer just a blog platform and in case if an author wants to create eCommerce theme then there is no way he can show how it will look like to the potential user. User checks the preview and sees a blog even though it is capable of doing much more.
If I create a theme I know what it should look like and a template would improve the current situation but I don't like the idea of allowing authors to choose just the template because then authors will create hard-coded templates and the reason for that will be that the current demo content that is provided for every single theme on wordpress.org looks just awful and in most cases doesn't represent what it actually can do.
I vote for a customizable content + template. WordPress can do much mure than just a blog and authors should be allowed to show that.
#60
@
9 years ago
The demo content and preview of themes is a completely different issue.
It seems like every theme author has their own idea of what this ticket is about and what the underlying problem is.
#61
@
9 years ago
@poena, they are totally different issue, however demo is just another big problem that this issue will solve :).
If automatically creating a page and setting it as frontpage on theme activation over the solution that we have proposed ( the patch), I will be happy to submit another patch with this one, we just need to make sure this is what we need.
#62
@
9 years ago
Forget about demos and other stuff. Let's get back to the original issue posted:
A theme should be able to register that they are designed to have a static front page by default. Core should then pick up on this as part of the activation process and allow them to pick or create a page, or ignore it and show posts on the front.
In a nutshell, what we're looking to do is have WP provide an option to use the static front page on theme activation. No need to go overboard with this.
If you want to completely change how the entire front page system works, that's a much larger discussion, will probably take longer to implement, and will have backwards-compatibility concerns. Taking a step back and looking at how this might work within the *current* system is probably the best bet.
Here's how a solution should work based on the proposal:
- Theme has
add_theme_support( 'static-front-page' )
(or something to that effect). - User activates theme.
- WordPress notices that the theme supports a static front page.
- WordPress asks user if they would like to use the theme's static front page.
- User can select to utilize the theme's static front page or opt to show their blog posts.
- If user chooses the static front page, they can select a page (or create a new page).
This can be tackled with something as simple as an admin notice and would be a huge first step.
This ticket was mentioned in Slack in #themereview by poena. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by chriscct7. View the logs.
9 years ago
#65
@
9 years ago
- Keywords close added
There doesn't appear to be a great amount of demand for this. Suggested close as maybelater
#66
follow-up:
↓ 69
@
9 years ago
@chriscct7 - What makes you think there is not much demand? There are 51 watching this ticket. Most are theme developers. What could you recommend that we make progress on this ticket?
#67
@
9 years ago
- Keywords close removed
Let's not close this please. Also echoing what Ulrich said.
#69
in reply to:
↑ 66
@
9 years ago
Replying to grapplerulrich:
What could you recommend that we make progress on this ticket?
A patch based on comment:62
#70
@
9 years ago
What if we just changed the wording so that the user does not expect the blog to be on the front page?
Then the user wouldn't need to take any action, it wouldn't be as intrusive as an admin notice asking the user to select a page.
And we wouldn't need to do any changes to the template hierarchy.
If the theme supports a static front page, change "Front page displays... Your latest posts" to
"Front page displays... Your default front page" or similar.
This ticket was mentioned in Slack in #themereview by jcastaneda. View the logs.
9 years ago
This ticket was mentioned in Slack in #themereview by greenshady. View the logs.
8 years ago
#74
@
8 years ago
- Owner koopersmith deleted
I don't think @koop is going to be working on this anytime soon and want to make sure it's clear this needs someone to drive.
This ticket was mentioned in Slack in #core by davidakennedy. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-themes by jorbin. View the logs.
8 years ago
#78
@
8 years ago
As 29 mentions, all themes should support a static front page already, even if it uses the same template as other pages. What's the goal here? To make it more obvious that a static front page can be used? To change the user's static front page option automatically on a theme switch (it's an option
, not a theme_mod
for a reason)? To display text implying that the current theme supports a static front page in a specific way? To allow themes not to support a static front page? The Your theme supports a static front page
text should probably go away regardless.
#16379 and #38013 are probably more relevant projects for improving the way static front pages can be changed.
We could do something like 62, but that assumes that a significant number of users would activate a theme without first previewing it in the customizer, where the ability to change the front page is a clear part of the flow. An admin notice probably isn't the best UX, because the user likely wants the blog index on the front if they left the option that way. Core could also start defaulting to a static front page if that would help, since that's a more common behavior. Perhaps renaming "Static Front Page" to "Front Page" for the customizer section title could also help.
Should it perhaps display a select box with a list of pages to choose from or simply give a notice that the theme is recommended to be used with a static home page and give a link to the reading settings page (similar to how a theme supporting widgets gives a link to configure them)?