-
Notifications
You must be signed in to change notification settings - Fork 383
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 page support #825
Add page support #825
Conversation
…draft and previews) * Use query var in permalinks containing query vars, instead of endpoint slug. * Remove needless and unslightly 1 value. * Add tests.
'name' => $this->get( 'blog_name' ), | ||
), | ||
'headline' => $post_title, | ||
'datePublished' => date( 'c', $post_publish_timestamp ), |
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.
These Schema.org properties are also relevant to WebPage
entities: http://schema.org/WebPage
So I don't see why we need to limit them just to 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.
@westonruter I would argue that. This really depends on the use cases but in most cases pages published/modified date are not relevant, or even inconvenient. It is a very common use case not to include the datePublished
and datePublished
. If we take Apple for example, we can see that datePublished
is used on news article but not on pages.
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.
True, but this is just in regards to the template rendering of the data. We're talking about metadata here. It should be up to the application to decide whether or not to show the datePublished
if the type
is WebPage
. In other words, the WP REST API for pages includes the published date, and that I think is a better parallel to the Schema.org metadata here.
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.
Sounds good, I am on board 😄
templates/footer.php
Outdated
</p> | ||
<a href="#top" class="back-to-top"><?php esc_html_e( 'Back to top', 'amp' ); ?></a> | ||
</div> | ||
</footer> | ||
|
||
<?php do_action( 'amp_post_template_footer', $this ); ?> |
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.
Putting this inside of footer
will be problematic for any themes that have their own existing footer.php
override.
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.
Great thoughts!
ff8b532
to
5dd2bc6
Compare
Merging this is dependent on @amedina confirming with the Google search team that we can reliably use |
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.
Thanks @weston, here is the CR and enhancement.
'name' => $this->get( 'blog_name' ), | ||
), | ||
'headline' => $post_title, | ||
'datePublished' => date( 'c', $post_publish_timestamp ), |
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.
@westonruter I would argue that. This really depends on the use cases but in most cases pages published/modified date are not relevant, or even inconvenient. It is a very common use case not to include the datePublished
and datePublished
. If we take Apple for example, we can see that datePublished
is used on news article but not on pages.
templates/admin/amp-status.php
Outdated
<div class="amp-status-actions"> | ||
<a href="#amp_status" class="save-amp-status hide-if-no-js button"><?php esc_html_e( 'OK', 'amp' ); ?></a> | ||
<a href="#amp_status" class="cancel-amp-status hide-if-no-js button-cancel"><?php esc_html_e( 'Cancel', 'amp' ); ?></a> | ||
<?php if ( $available ) : ?> |
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 really like that approach, in fact I think we could apply the same for CPT with support disabled. That said, I think it isn't really clear for the user as why it is disabled and why the ability to edit the status is removed. I would suggest to keep the edit link and display a warning when toggled (no visual noise on load, informative on toggle)? Here is a commit which implements it, the warning may be more target if need be and if time allows.
templates/admin/amp-status.php
Outdated
</fieldset> | ||
<?php else : ?> | ||
<div class="inline notice notice-warning"> | ||
<p><?php esc_html_e( 'AMP cannot be enabled on home page, front page, password protected posts and post types which do not support AMP.', 'amp' ); ?></p> |
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 think this message should only be shown if the post is the homepage, page for posts, password protected posts, or posts that don't support AMP. In other cases, we should show a different message such as when a plugin blocks AMP for a post via the amp_skip_post
filter. For example:
A plugin or theme has disabled AMP support.
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.
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.
Also probably should say that AMP cannot yet be enabled for those certain pages. Our intention is to eventually allow every page to be AMPed.
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.
Thanks for your feedback @westonruter. I improved the error messages to be more accurate in this commit. I had to add amp_post_supports_error()
function to avoid redoing all checks.
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.
Looks pretty good to me. Do tests pass all the AC?
Thanks @amedina, yes all AC are covered in this PR and we should be pretty close to merging and sending this to QA (once this commit is reviewed). |
Great @weston, all latest changes are good to go codewise from my perspective. |
This PR adds support for pages, refer to the ACs for more info...
Fixes #176.
Closes #188.
Closes #816.
Closes #619.
Inspired by #188 & #816
Kudos to @technosailor, @mjangda and @mpszone for their contribution.