Custom Theme and front page

You might have a little bit skewed perception of what a theme does. The theme’s only job is to present the existing content, according to the options that are set. (all core WP options must work)
A theme can provide a front-page.php template file that handles the front page in its own way, but it must account for both choices for front page (static page or list of posts). The user can put whatever they want into the static page or any of the posts.
See the template hierarchy here: https://developer.www.ads-software.com/themes/basics/template-hierarchy/

So, when you try different themes, don’t expect them to change your WP options (they never should write any options except theme options). The theme will show your content the way your options are set already. And the theme should be able to show your content well when you change the options to show something else on the front page.

There are themes in the repository that supply page templates, but they are mostly generic since they have to work for all sites, all languages, all types of content that is in those pages.
Themes aren’t really about individual pages. They are for consistency across all pages of the site.

Thanks for the explanation . I do understand the theme hierarchy and that a theme should not change the front page settings however my question was about the accepted practice among theme developer with regards to the template files that are included for static pages . So what you are saying is as a theme user I would not expect any template pages for specific static pages ( like About Us or TOS or a particular style of front page ) but the general page template page.php ?

I have a related question . What if as a theme developer I choose to give the users the ability to choose from one of three static pages or the blog page index as a static front page ( which I code and include as a part of the theme with template file names frontpagestyle1.php , frontpagestyle2,php and frontpagestyle3.php while the index.php is used for the blog page index) . Do I create these as custom templates so that users can choose from them while they create the page , from page attributes or do I ask users to create a page( say with title frontpagestyle) and change the template name that they want to frontpagestyle.php ( to make use of the template hierarchy ) ?

• This reply was modified 5 years, 4 months ago by Rajarshi Bose.
• This reply was modified 5 years, 4 months ago by Rajarshi Bose.
• This reply was modified 5 years, 4 months ago by Rajarshi Bose.

Actually I just realized I do not quite understand the theme hierarchy … lol …
I am going through the link you ‘d sent making sense of it (again) .. but I would really appreciate if you could tell me how to go about doing what I want to in my previous post.

If you are building this theme for your own use, do it however you want.
If you want to distribute the theme in the WP repository, your theme won’t be accepted if it changes any options except for theme options. And even in theme options, it has to use the Customizer, which does it for you. (that means no calls to update_option or add_option)

The front-page.php template file is used if it exists, so no additional page template would be loaded. That’s why it has to handle both cases of page on front and posts on front.
Page (or post) templates are selected per page (or post) from within the editor. They still must be generic to work for any content that the user has in that page. The problem with page templates is that when a user switches themes, that page template is gone. Or if a user switched to your theme, they would have to go through and choose the template for each page (or post) to get that look. It’s too much burden for specific pages, since themes can be switched programmatically by plugins or even by the visitor on the front end.

If you want to have three layout choices for your front-page.php static page output, use a theme option in the Customizer that selects between the three, and the code in front-page.php checks that option to output the correct layout. (meanwhile it also checks if it is doing posts list instead)
The theme doesn’t care what the page content is; it just presents whatever is there according to the theme design.

The trick to the theme template hierarchy is that WordPress checks all the parameters of the URL to determine what was requested, and loads the correct template file to handle that request. The theme doesn’t have to do any queries of the database. It just presents what WordPress has already retrieved.

I am just two months into WordPress , learning it from home alone so please bear with my ignorance . Kindly correct me if I am wrong .
After your reply I went around digging a bit , so what I understand is themes( in
the Wp repository only ? ) are generic in nature made to display different types
of content . They are not meant for a single site and static pages .Static pages
are coded ( in for eg page-slug.php) or made using page builders. Theme’s main
functions seems to be enqueueing all the scripts and styles , create the header ,
footer , sidebar , create the blog index page template ( which you can overwrite
) and some generic page , archive , 404 etc templates .The only options WP
repository themes can store/read are the customizer options using which we decide
on the display inside a template file .

Suppose I have static code for different websites of a particular niche ( eg.
lawyers) .They have similar pages ( eg . about us , front page , our team etc) but different layouts , assets and content all hard coded . I want to turn them to WP sites and give users the ability to choose from the different static pages and change the assets and content in the HTML . Is this not normal in WP development ?

What I understand is if I want to do something like above I can either ( for WP
repository themes) make use of the customizer settings and use appropriate
templates based on the customizer settings or if I am distributing it outside the WP repository I can just include all the different templates and ask the end user to rename the files they need to make use of the template hierarchy . Is that correct ?

Except the blog posts and blog index page all the content will be in the template files and not in the WP database . So , if these are coded in custom page templates or template files and if admins changes the theme or if a visitor to a website can change the theme ( I am assuming by visitor you mean WordPress registered users for that site ) all my content will not be available . Is’nt it the same thing as adding content using a page builder and uninstalling the page builder ?

Lastly if I have to store the content for the static pages in the WP database and show them using my templates so they are available on theme change I need to make users enter them using the Add Page or Edit Page screen but later while showing the content how do I differentiate between different sections of content which has been entered all together ? Eg . I have a Our Team page with different team members , If users enter all the information in the Page Editor together while displaying how do I differentiate between the team members ?

I hope my question makes sense . Also want to thank you for your time , learnt a lot from your replies .

• This reply was modified 5 years, 4 months ago by Rajarshi Bose.

What you describe (hard-coded content) sounds like it should be HTML files, which can coexist just fine with WordPress. Or perhaps your content should be supplied by a plugin. In WordPress, the core code is responsible for determining what the request is, retrieving the data from the database, and loading the appropriate template file to display it. Everything else is an add-on, like a plugin or theme (WordPress doesn’t actually output the page, the theme does). Since the software is generic, the content is stored in the database so that it can be anything the user wants. But the theme should display what is retrieved, not something it supplies, because it has to work for all of the known requests.
To add new types of requests, you code a plugin that either defines a new REST API route or a custom post type or a custom taxonomy or even new rewrite rules for custom code to generate new content. But the plugin should mesh with the way WordPress works, so that it works with any theme (the new pages look like the standard pages and change when the theme changes).

You can write a plugin that presents the WP user with choices of your static pages, and then creates those pages in the database when they choose. (the plugin is only needed at the beginning and then can be deleted)
For team members, there are already a bunch of plugins that help you manage team info and present it in different ways. This can be the built-in user table enhanced with more fields, or a custom post type for users so it’s easily handled by the theme, or even a separate database table (which other plugins don’t know about so they can’t really interface with it).

For your project, you should keep the look of the site (the theme) separate from the data of the site (supplying About, Front page, Team pages). Years of experience has shown that putting it all in one package leads to trouble, especially if a site gets hacked, or when the user is ready for expansion or a new look.

There are many plugins that create pages. One example is a shopping cart plugin. It will typically create several pages, each with a shortcode: shopping cart, thank you page, my orders. The shortcode is constant, but the code to handle the shortcode can change with an update to the plugin. Yours might not need a shortcode, as it can hard-code the content and delete the plugin. Or you might use a shortcode so the user can choose at any time one of the other options (they just change the parameter in the shortcode), but then your plugin must be there to handle the shortcode.

After you reply I’d gone on a research spree . WordPress is very different from what I thought it to be . Everything is slowly beginning to false into place .
Thank you for your detailed reply . I will have this closed .