Right now, Frontity settings and conditional tags related to the homepage are based on the WordPress dashboard:
WordPress Dashboard
Frontity State
Frontity Conditional Tags
Homepage
homepage
isHome
Posts page
postsPage
isPostArchive
That doesn’t honor either the WordPress settings or the WordPress conditional tags:
WP dashboard
WP settings
WP cond. tags
Frontity state
Frontity cond. tags
Homepage
page_on_front
is_front_page()
homepage
isHome
Posts page
page_for_posts
is_home()
postsPage
isPostArchive
We should make a decision on this so that the terminology we use is as similar as possible to that used by WordPress and at the same time as understandable as possible.
I’m not sure if we should do that, @luisherranz.
I remembered that we tried to avoid some confusion that is around these terms in WordPress.
The thing is that, in the WordPress dashboard, the term homepage is used to refer to the root of your site (what we usually call homepage). Based on this settings we created the options state.source.homepage and state.source.postsPage.
is_home(), which returns true for the post archive page, even though you have set your homepage as a static page in the WordPress settings (in that case, is_home() would be false for the homepage ).
is_front_page(): which returns true for the static page you specified as your homepage, or for the post archive if your homepage displays your latest posts (so it is always true for what your homepage displays).
So, we took the decision of matching what WordPress calls homepage in its dashboard.
Anyway, if we eventually decided to match both the WordPress settings and the conditional tags, we should explain in detail why we would have chosen those names for isHome() and isFrontPage() and why isHome() would not be true for the page specified in state.source.homepage.
If assigned, WordPress ignores the pages assigned to display the site front page or the blog posts index
If 'page' == get_option( 'show_on_front' ) :
On the page assigned to display the site front page:
is_front_page() will return true
is_home() will return false
On the page assigned to display the blog posts index:
is_front_page() will return false
is_home() will return true
So, what I understand from all of this is:
frontity WP setting WP conditional
homepage === page_on_front === the page where is_front_page() === true
postsPage === page_for_posts === the page where is_home() === true
So, right now, frontity’s isHome is the same as the is_front_page() from WordPress, which I think is confusing!
What to do
I think in the ideal world we should have named the options in Frontity the same way as they are named in WordPress internally (but camelCased):
pageOnFront
pageForPost.
Then we could also have the isHome and isFrontPage properties which would correspond to those options in WordPress.
So, concretely, we could do this:
Add a pageOnFront property to source.state.
Add a pageForPosts property to source.state.
Alias homepage to pageOnFront and deprecate the homepage property.
Alias postsPage to pageForPosts and deprecate the postsPage property.
Change how isHome property is computed to align with WordPress’s is_home() rather than the current behaviour of is_front_page(). This would be a breaking change.
Add an isFrontPage property to the data. This would have the same logic as isHome has currently.
That would make a lot of sense. The only thing is, to use these settings in Frontity, you must specify them as well in your WordPress dashboard. So, you would have to explain how and why these terms are related.
WordPress Dashboard
Frontity State
Frontity Conditional Tags
Homepage
pageOnFront
isFrontPage
Posts page
pageForPosts
isHome
Maybe we could deprecate isHome as well and change it by isPostsPage, or just use isPostArchive, which is the equivalent term we have right now.
I know it is confusing not to follow what WordPress is doing. But for me, it is also confusing to follow that!
BTW, the terms that Frontity are using currently are these:
I like the fact that is_home() can be mapped to isPostArchive in Frontity, which is much more explicit.
So Frontity “doesn’t need” an is_home().
I also don’t like the fact that if we move isHome to isFrontPage it’s a breaking change.
So, what about this a mix between your proposals:
1. Changes for Source v1
WP dashboard
WP cond. tags
Frontity state
Frontity cond. tags
Frontity alias (deprecated)
Homepage
is_frontpage()
homepage
isFrontPage
isHome
Posts page
ishome()
postsPage
isPostArchive
-
2. Breaking Changes for Source v2
WP dashboard
WP cond. tags
Frontity state
Frontity cond. tags
Homepage
is_frontpage()
homepage
isFrontPage
Posts page
ishome()
postsPage
isPostArchive (or isHome)
My reasoning behind this:
I’d stick to WP dashboard names for the Frontity state
I agree with Michal that the WP database setting names are less confusing than the WP dashboard names. Unfortunately, I think WordPress developers are not familiar with those database names and it is less confusing to match the WP dashboard names, because that’s the names the developers they see when they need to configure this.
I’d try to get rid of the is_home() !== isHome inconsistency
I agree with David that the WP is_home() is quite confusing. But it’s also confusing that we use isHome for a different thing. I’d try to get rid of that and switch from isHome to isFrontPage.
I’d try to start with a non-breaking change
That way, people can start moving away from using the isHome to the isFrontPage gradually. And hopefully, by the time we switch to Source v2, most of the people will be using isFrontPage instead of isHome.
Finally, match WordPress
Even though I agree with David that isPostArchive is much more explicit than isHome and we should promote the use of that flag, I think I would still add isHome in Source v2. I’m not 100% convinced about this one though. Maybe we could just remove it.
Anyway, great work guys. I think this FD can be framed under the “moving towards Source v2” scope