-
Notifications
You must be signed in to change notification settings - Fork 897
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Indexable visibility columns #17757
base: trunk
Are you sure you want to change the base?
Conversation
This caused issues with the rename_column, as column_info expects an array
If a replacement is given the ORM uses the replacement automatically.
…o number_of_publicly_viewable_posts
is_public is replaced by a different approach in querying data and by is_publicly_viewable. If we would immediately replace is_public with is_publicly_viewable, that would be a BC break.
…icly_viewable value
Password protected posts still end up in the post-type- and termarchives and are publicly queryable. The difference is that the content is password protected. Because if this detail, these posts should be noindexed, but the archives should still update their data because the protected posts are still shown there
This prevents unsetting the last modified date on archive indexables when the last post of the post-type or taxonomy is removed. Also prevents moving the date back in time when performing a reindex action.
…IX-22-number-of-posts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the
has_public_posts
property is used, the code shows a deprecation warning and returns the value fornumber_of_publicly_viewable_posts
posts instead. This should yield the same result.
If that's what we want, then it's not currently happening, since has_public_posts
was a boolean value and number_of_publicly_viewable_posts
is an integer.
Also, if we want a match between the old has_public_posts
value and the new number_of_publicly_viewable_posts
one, I can imagine a case where these won't match and that is when we add images/attachments in a post.
Doing so, we will create an indexable for that attachment with number_of_publicly_viewable_posts = 0
as per the new code
but if I read the old code right, we would create the indexable for that attachment with has_public_posts = 1
as long as that post where the attachment was added is public.
$post_type = get_post_type( $post ); | ||
$post_status = get_post_status( $post ); | ||
|
||
return is_post_type_viewable( $post_type ) && $this->is_post_status_viewable( $post_status ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefix those functions with \
likeso:
$post_type = \get_post_type( $post );
$post_status = \get_post_status( $post );
return \is_post_type_viewable( $post_type ) && $this->is_post_status_viewable( $post_status );
|
||
$replacements = \array_merge( $post_statuses, [ $author_id ] ); | ||
$replacements = \array_merge( $post_statuses, [ $author_id ], $post_types ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a check if $post_types is array here, before merging it to the $replacement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! that could've been a nasty bug. I added validation higher up in the get_author_post_types so we're sure that we get an array.
$indexable->object_published_at = $aggregates->first_published_at; | ||
$indexable->object_last_modified = max( $indexable->object_last_modified, $aggregates->most_recent_last_modified ); | ||
$indexable->number_of_publicly_viewable_posts = $aggregates->number_of_public_posts; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This block is repeated 4 times throughout the builders.
Maybe create a separate function to avoid Code Duplication?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did consider it, but decided to not change more than I had to. I want to better abstract this when we revise the builders entirely. Do you think that's ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeap, for sure it's ok 👍 :)
@@ -18,13 +18,13 @@ class Indexable_Builder_Versions { | |||
*/ | |||
protected $indexable_builder_versions_by_type = [ | |||
'date-archive' => self::DEFAULT_INDEXABLE_BUILDER_VERSION, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm probably missing something here, but why don't we up the builder version for dates?
My thinking is that since we add the is_publicly_viewable
property, we should up this too, but maybe I don't get it :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right! I missed that one. Thanks for noticing!
…IX-22-number-of-posts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CR: 👍
With these new changes, we also take care of this remark, except the last part about attachments' has_public_posts
BC break, but as per our conversation with @diedexx that's ok.
|
||
$sql = " | ||
SELECT MAX(p.post_modified_gmt) AS last_modified, MIN(p.post_date_gmt) AS published_at | ||
SELECT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
idea: how about getting post ID's for an author first and iterating over those - using primary keys seems more efficient than where-ing over a set of fields.
If we use the same version number for two separate model changes in two separate releases, the later release won't receive automatic model updates because the version hasn't changed as of the previous release. Adding a comment of the version number, will cause a git merge conflict, which forces you to look at what the correct version number should be.
…IX-22-number-of-posts
During acceptance together with @increddibelly we found a bug: |
@diedexx Is this still relevant, or can it be closed? :) |
Yes, this is still relevant for indexable sitemaps |
A merge conflict has been detected for the proposed code changes in this PR. Please resolve the conflict by either rebasing the PR or merging in changes from the base branch. |
Context
Summary
This PR can be summarized in the following changelog entry:
number_of_publicly_viewable_posts
andis_publicly_viewable
is_public
andhas_public_posts
on the Indexable model.Relevant technical choices:
is_publicly_viewable
to be accurate for term, post-type and post Indexables.NULL
values as possible for the new columns. Sometimes we have to:is_public
instead of removing. The model is exposed through our surfaces, so removing the is_public property is a BC break.is_public
is still actively being set when (re)indexing. But all related code has been deprecated.has_public_posts
property is used, the code shows a deprecation warning and returns the value fornumber_of_publicly_viewable_posts
posts instead. This should yield the same result.is_post_publicly_viewable
has been copied to the post-builder because it was introduced in WP 5.7 and we still support 5.6.set_dreprecated_property
and marked it with@internal
so we can keep deprecated properties up to date during the deprecation period without throwing any deprecation warnings.Test instructions
Test instructions for the acceptance test before the PR gets merged
This PR can be acceptance tested by following these steps:
Prep
_yoast_indexables
.Database migration
number_of_publicly_viewable_posts
andis_publicly_viewable
.is_publicly_viewable
isNULL
for all indexables.number_of_publicly_viewable_posts
is populated and has the correct value. It should be eitherNULL
,0
or1
:0
for the home page and system-page indexables (OR the acutal number of publicly viewable posts in the home page. This value is updated rather quickly)0
for author indexables that authored no posts or only posts that are not published or have robots set tonoindex
for that post or are password protected.1
for author indexables that authored at least one post that is published and has robots set toindex
for that post and isn't password protected.NULL
for author indexables that authored at posts that are published and have robots set todefault
for that posttype and aren't password protected.NULL
for post, term and post-type archive indexables0
for attachment posts that don't have a parent; the attachment isn't linked to a post.0
for attachment posts that are linked to a post that is not published or have robots set tonoindex
for that post or is password protected.1
for attachment posts that are linked to a post that is published and has robots set toindex
for that post and isn't password protected.NULL
for attachment posts that are linked to a post that is published and have robots set todefault
for that posttype and isn't password protected.Posts
is_publicly_viewable
is1
is_publicly_viewable
is0
is_publicly_viewable
is0
number_of_public_posts
is0
for your new posts.Date archives
0
1
System pages
is_publicly_viewable
is set to1
Home page
number_of_publicly_viewable
value now matches the number of posts that is visible in your home page for not logged in users (use an incognito window)number_of_publicly_viewable
goes down and theobject_last_modified
reflects the moment you made the post private.Authors
number_of_publicly_viewable
value now matches the number of posts that is visible in your author archive for not logged in users (use an incognito window)number_of_publicly_viewable
goes down and theobject_last_modified
reflects the moment you made the post private.Post types
number_of_publicly_viewable
value now matches the number of posts that is visible in your post type archive for not logged in users (use an incognito window)number_of_publicly_viewable
goes down and theobject_last_modified
reflects the moment you made the post private.Terms
number_of_publicly_viewable
is 0.number_of_publicly_viewable
value now matches the number of posts that is visible in your term archive for not logged in users (use an incognito window). The value is1
.number_of_publicly_viewable
goes down and theobject_last_modified
reflects the moment you made the post private.Reindexing
Test instructions for QA when the code is in the RC
Impact check
This PR affects the following parts of the plugin, which may require extra testing:
UI changes
Other environments
Documentation
Quality assurance
Fixes FIX-21
Fixes FIX-22
Related to