Skip to content
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

Sidebar: use the "preview" layoutFocus to preview the current site #5117

Merged
merged 1 commit into from
May 25, 2016

Conversation

lsinger
Copy link
Contributor

@lsinger lsinger commented Apr 29, 2016

Uses the preview layoutFocus to preview the current site when clicking it in the sidebar:

preview-card

To test:

  • Try clicking the site card on different sites (including Jetpack sites), check it works
  • Try cold refreshes
  • Make sure switching sites works OK
  • DISABLE_FEATURES=preview-layout make run — check behaviour is the same as master

@mcsf
Copy link
Member

mcsf commented May 4, 2016

Rebased against parent branch's rebase.

@mcsf mcsf force-pushed the update/sitecard-preview-layoutfocus branch from 814c4a4 to 38d373e Compare May 4, 2016 00:04
@ehg ehg force-pushed the update/sitecard-preview-layoutfocus branch 2 times, most recently from 0296023 to 8bbbe87 Compare May 11, 2016 14:05
@lsinger
Copy link
Contributor Author

lsinger commented May 12, 2016

Still works fine after rebase.

@ehg ehg force-pushed the update/sitecard-preview-layoutfocus branch from a5a6d99 to aad9d11 Compare May 12, 2016 16:53
@ehg
Copy link
Member

ehg commented May 12, 2016

Rebased against master :)

@mcsf
Copy link
Member

mcsf commented May 13, 2016

Noting here that, due to the way the backend generates the preview, we're not necessarily showing the user the same view that they would otherwise see via the actual frontend. For instance, private posts aren't shown:

screen shot 2016-05-13 at 09 59 08

I added a tentative task in this PR's TODO, which you should feel free to slate for later.

@ehg
Copy link
Member

ehg commented May 13, 2016

Added an external link icon in 4fd9547

@ehg
Copy link
Member

ehg commented May 13, 2016

Navigating in the preview doesn't work because of https://github.com/Automattic/wp-calypso/blob/master/client/my-sites/design-preview/index.js#L132

I wonder if this is something we can implement fairly easily.

@mcsf
Copy link
Member

mcsf commented May 13, 2016

Sounds fairly doable.

@ehg ehg mentioned this pull request May 16, 2016
6 tasks
if ( ! state.preview || ! state.preview[ selectedSiteId ] ) {
return { selectedSiteId };
}
const { previewMarkup, customizations, isUnsaved } = state.preview[ selectedSiteId ];
return {
selectedSite,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll probably also want to return selectedSite in the early return a few lines up.

@mcsf mcsf force-pushed the update/sitecard-preview-layoutfocus branch from 9332f55 to 411661d Compare May 16, 2016 22:13
@mcsf
Copy link
Member

mcsf commented May 16, 2016

@sirbrillig: while trying to fix the occurrence of blank previews, I noticed the implementation of state/preview/reducer and committed c1b5608.

Please let me know if it makes sense or if I missed a detail.

@sirbrillig
Copy link
Member

@mcsf: oh, thank you. That's something I was mentally trying to get at but it never quite happened. That should help prevent flickering when the preview hasn't changed.

@ehg ehg added this to the GuidedTours M2: Preview & Polish milestone May 17, 2016
@lsinger lsinger force-pushed the update/sitecard-preview-layoutfocus branch from c1b5608 to 8807ca1 Compare May 18, 2016 07:58
@sirbrillig
Copy link
Member

I briefly spoke with @lsinger in Slack about what it would look like to load the DesignPreview by URL instead of with markup from the API. Here's the upsides and downsides:

  1. Using the URL means that the preview will reflect exactly what the user sees on the front-end (eg: Typekit fonts), except that the view will be the "logged-in" view, including the masterbar and any other logged-in behaviors. (The API is set up to show the "logged-out" view to show what the site looks like to others.)
  2. If we want to hide the masterbar or anything else, we would need to do so via an addition to the query string in the URL or by including non-calypso javascript in the preview.
  3. Because the preview would be loaded into the iframe from a different domain, there is no way to read or modify the DOM from calypso. Applying customizations would therefore have to be done by including non-calypso javascript in the preview. (Not an issue if you're not applying changes to the preview.)
  4. Since the preview would be a full version of the site, all links will work in the iframe. This means that the user could navigate to a different page, a different site entirely, or even back into calypso, all from ​_within_​ the preview, which is a pretty terrible experience (this is already possible in the editor preview; here's an example of the editor opened within the editor preview: https://cloudup.com/c2zxgUu01Zx)
  5. Because we can't query the document object of the iframe, the onLoad function of DesignPreview/WebPreview won't work without some modifications.

Most of those aren't insurmountable, but they do require some planning. Number 4 is perhaps the most troubling to me because I'm not sure how to "fix" it, although hiding the masterbar sure would help.

@folletto
Copy link
Contributor

  1. If we want to hide the masterbar or anything else, we would need to do so via an addition to the query string in the URL or by including non-calypso javascript in the preview.

Note that this is already available: ?demo=true&iframe=true&theme_preview=true (could be refactored to be neater).

It's used by the Theme Showcase's preview and the iOS/Android apps afaik.

@ehg
Copy link
Member

ehg commented May 18, 2016

Note that this is already available: ?demo=true&iframe=true&theme_preview=true (could be refactored to be neater).

AFAIK that only works for the initial view, so any links clicked within the iframe will show the masterbar.

@ehg
Copy link
Member

ehg commented May 18, 2016

I guess we could load something like a more robust version of the following server side, to get around the masterbar issue at least:

(function(){
  window.onload = function() {
    var anchors = document.getElementsByTagName( 'a' );

    for (var i = 0; i < anchors.length; i++) {
        anchors[i].href = anchors[i].href + '?iframe=true&theme_preview=true';
    }
  }
})();

), delay );
};

export default wait;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put this little guy inside the Guided Tours directory as a quick fix, but where do you guys think it really belongs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lodash? ¯_(ツ)_/¯

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be fine here for now. We can always move it into lib when it's more mature.

@ehg ehg force-pushed the update/sitecard-preview-layoutfocus branch from a4259cb to e441666 Compare May 24, 2016 10:12
@ehg ehg force-pushed the update/sitecard-preview-layoutfocus branch 2 times, most recently from a2ea2aa to 6b141fc Compare May 24, 2016 11:25
@ehg
Copy link
Member

ehg commented May 24, 2016

@@ -151,7 +152,9 @@ module.exports = React.createClass( {
homeLink={ true }
enableActions={ true }
externalLink={ true }
onSelect={ this.trackHomepageClick }
onClick={ this.previewSite }
onSelect={ this.previewSite }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want onSelect here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAICT onSelect translates into the onTouchTap event? I'd assume we want that.

@ehg ehg force-pushed the update/sitecard-preview-layoutfocus branch from 86acbe9 to f866eb4 Compare May 24, 2016 12:32
@ehg
Copy link
Member

ehg commented May 24, 2016

Squished.

@ehg ehg added [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. and removed [Status] In Progress [Type] Task labels May 24, 2016
@@ -104,8 +104,9 @@ module.exports = React.createClass( {
);
},

trackHomepageClick: function() {
previewSite: function( event ) {
analytics.ga.recordEvent( 'Sidebar', 'Clicked View Site' );
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clicked View Site => Clicked Preview Site?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This event predates this PR, so we don't want to change it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, right, it's an actual event name—I'd assumed it was just a string representation for easier reading. Yes, in that light it makes total sense to keep!

@lsinger
Copy link
Contributor Author

lsinger commented May 24, 2016

The tooltip for the site card is Visit "SITE_TITLE". Can we change that to Preview "SITE_TITLE"?

@lsinger
Copy link
Contributor Author

lsinger commented May 24, 2016

Generally, this works for and looks good to me.

From time to time the preview takes a bit long to load--but I don't think that's something we could make work better.

The "background image for Dyad theme only shows when browser is forced to repaint through scrolling" is still happening for me, but it seems isolated to my machine. Would be thankful if someone else could try to reproduce:

  • have a site with the Dyad theme and a header image
  • when you open preview, does the header image show?

@ehg
Copy link
Member

ehg commented May 24, 2016

The tooltip for the site card is Visit "SITE_TITLE". Can we change that to Preview "SITE_TITLE"?

Changed this and the aria text in 24d46a5c5240df0e405da19f843053945c930961 — also, made sure we're not trying to open a preview when preview-layout isn't enabled in config — which should ensure we don't break non-dev envs(!)

@lsinger
Copy link
Contributor Author

lsinger commented May 24, 2016

which should ensure we don't break non-dev envs

👍 GOOD call, that one.

@bisko
Copy link
Contributor

bisko commented May 25, 2016

The "background image for Dyad theme only shows when browser is forced to repaint through scrolling" is still happening for me, but it seems isolated to my machine.

Works properly for me! It seems the theme works a bit strange when updating it through Customizer, because if you have featured content and a header image, the one or other are not properly "switched" until a full refresh after saving and publishing the changes.

Code looks good to me! 👍

A few things I noticed while testing:

  • Is there a need to send the URL query params (?iframe=true&theme_preview=true&frame-nonce=xxxxxx) when clicking the "Open in external window" button, since it opens the site?
  • Guided Tours interfere with the preview if the user clicks on the preview too quickly:

screen shot 2016-05-25 at 10 59 35

screen shot 2016-05-25 at 11 00 01

- Updating the Theme or Theme options through Customizer doesn't update the preview. It requires hard refresh of the whole page.

@ehg
Copy link
Member

ehg commented May 25, 2016

Thanks @bisko :)

the one or other are not properly "switched" until a full refresh after saving and publishing the changes.

Updating the Theme or Theme options through Customizer doesn't update the preview. It requires hard refresh of the whole page.

#5551

Is there a need to send the URL query params (?iframe=true&theme_preview=true&frame-nonce=xxxxxx) when clicking the "Open in external window" button, since it opens the site?

#5550

Guided Tours interfere with the preview if the user clicks on the preview too quickly:

Interesting, that's Trampoline, and that shouldn't be happening.

@bisko bisko added [Status] Ready to Merge and removed [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels May 25, 2016
@ehg ehg self-assigned this May 25, 2016
@ehg ehg force-pushed the update/sitecard-preview-layoutfocus branch from 24d46a5 to 3ac7bd5 Compare May 25, 2016 09:55
@ehg ehg merged commit a5defca into master May 25, 2016
@ehg ehg deleted the update/sitecard-preview-layoutfocus branch May 25, 2016 09:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants