Make `wp-source` homepage settings and conditional tags to match WordPress

đź—Ł Feature Discussions
1

Description

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.

Possible solution

@mmczaplinski has proposed this solution: Make `wp-source` homepage settings and conditional tags to match WordPress

2

From: data.isHome is not working since update

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.

However, in the WordPress Conditional Tags we have:

  • 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 :dizzy_face:).
  • 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.

3

OK, I’ve tried to untangle this a little bit further.

WordPress has the following concepts which I took from the Option Reference:

image
image2076Ă—833 102 KB

For reference, here are the definitions:

show_on_front

Screen Shot 2020-10-08 at 6.03.31 PM

page_on_front & page_for_posts

Screen Shot 2020-10-08 at 4.56.16 PM
Screen Shot 2020-10-08 at 4.56.16 PM1346Ă—378 21.4 KB

The crucial part for understanding all of this is the definition of is_home() algorithm:

  • If 'posts' == get_option( 'show_on_front' ) :
    • On the site front page:
      • is_front_page() will return true
      • is_home() will return true
    • 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 :smile:

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.

4

Fair enough. :blush:

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:

WordPress Dashboard Frontity State Frontity Conditional Tags
Homepage homepage isHome
Posts page postsPage isPostArchive
5

Okay, I extended the tables above to include also the WP settings and WP conditional tags.

This is what @mmczaplinski has proposed:

WP dashboard WP settings WP cond. tags Frontity state Frontity cond. tags
Homepage page_on_front is_front_page() pageOnFront isFrontPage
Posts page page_for_posts is_home() pageForPosts isHome

And this is how Frontity works currently:

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
6

@luisherranz I would like to know your opinion on this as well :blush:

7

Hey, great research guys!

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 :slightly_smiling_face: