Jetpack: Dummy content front-facing modules on local installs

[krogsgard]

I would love if there was a way to showcase dummy content for activated, front-end facing Jetpack modules.

For instance, I cannot test or style related posts at all until I get them on a dev server. For this and other front-end facing features, having something visible (dummy content is fine!) when dev mode is enabled would be _enormously_ beneficial.

I do not know the best route to take, but this is the type of thing that is immensely frustrating when trying to utilize Jetpack but being unable to do so in development.

[georgestephanis]

Hrm. Two main ways to implement, I think, would be to either roll it in for dev_debug mode, or do it as a seperate plugin that just filters get_modules to make them locally activate-able and provides the dummy data.

I'm thinking the latter at the moment, will look at it as a weekend hack project in the next month or so if nobody beats me to it.

[krogsgard]

@georgestephanis I think that an add-on plugin would be fine. Could bundle it in one to enable local dev, honestly. Though priority for that would may require it to be an mu-plugin. Anyway, this would be great. There are a number of modules w/ this issue and it's a major barrier to doing a proper job w/ Jetpack.

[kraftbj]

For reference, modules that have front-facing content that can't be displayed in dev mode currently:

• Jetpack Comments (though the form itself is iframe'd from wp.com so mainly checking the h3, spacing, etc)
• Google+ Authorship (the post-content "flair")
• Likes
• Related Content
• Subscription Widget
• VideoPress

[krogsgard]

@kraftbj Is there any custom markup or a wrapper for social widgets, or is it only the Twitter/FB markup?

[kraftbj]

@krogsgard The Twitter Timeline/Facebook Like Box? Both of those are available in dev mode.

The Gallery widget used to be restricted to when Tiled Galleries was enabled, but since 3.0, that is available in dev mode. None of the other "Extra Sidebar Widgets" widgets required a connection, unless I'm overlooking something :).

[jeherve]

Also suggested here:
https://wordpress.org/support/topic/connecting-a-vagrant-box-to-jetpack?replies=1&view=all

[joshbetz]

I think rolling this into JETPACK_DEV_DEBUG makes the most sense. For related posts in particular, we could query the local database for some random posts.

[jeherve]

Also suggested here:
https://wordpress.org/support/topic/related-posts-and-other-connected-features?replies=1&view=all

[jeherve]

Also suggested in #3673

My suggestion is that if JETPACK_DEV_DEBUG is enabled then related posts can be enabled also. Instead of using the wordpress.com search api you would select X latest posts. This means the content won't actually be related - but I don't think that's an issue when developing.

I have spent this afternoon working on a small plugin which does this for me - but it's not ideal since thumbnails don't work. Plus I think it would be nice for other developers to be able to use this too.

You can see the code I am using here: https://gist.github.com/BinaryMoon/cca23cdb72a9ce42a0460e8d881ff021

cc @BinaryMoon

[jb510]

+1 on on the need for some solution here. It's long been a major frustration trying to style front end elements like the subscribe widget and related posts widgets on development sites. I really feel strongly that the approach of "hiding things that don't work without a connection" is absolutely the wrong approach. I _hate_ playing the game of "oh, look the subscribe widget was working yesterday and now it's nowhere to be found, what gives?"

At least output an html comment in these situations like '.' Or better show the widget in the admin but with a not that it's disabled. Something more than leaving us to guess where it went and why.

[jb510]

While dummy content would be better than nothing, I'd rather have real but deactivated or non-functional content.

What I mean is:

• show me my real subscribe widget, but disable the button action.
• show me my real posts in related post, just they don't really need to be based on analyzed data, just show the latest 3 recent posts for example.

The reason is the for front end dev I want to see real content so I know if they're is an issue with the real content, and we often modify these widgets using their hooks, I need to see those modifications.

[jeherve]

I really feel strongly that the approach of "hiding things that don't work without a connection" is absolutely the wrong approach.

Just to be clear, things aren't just hidden. The modules don't even run, so outputting any kind of content is a bit more complicated. In the case of the subscription widget for example, it is not even registered.

show me my real posts in related post, just they don't really need to be based on analyzed data, just show the latest 3 recent posts for example.

Agreed. I like the approach suggested in #3673, for example.

The reason is the for front end dev I want to see real content so I know if they're is an issue with the real content, and we often modify these widgets using their hooks, I need to see those modifications.

That makes total sense. Until we all find a solution that works for everyone, I'm afraid I can only suggest that you run your tests on a live sandbox, where Jetpack can be connected to WordPress.com.

[jb510]

Just to be clear, things aren't just hidden. The modules don't even run, so outputting any kind of content is a bit more complicated. In the case of the subscription widget for example, it is not even registered.

I'm aware... but to reiterate they _should_ run. I, and I suspect every developer wants, all the code the runs on live to first run on dev/staging. There are countless reasons for this, front end dev is actually one of the less important ones. These widgets have hooks, we need to test the code that runs on those hooks.

I was a huge fan of _DEV_DEBUG when it was put in it's been a big help, but it was conceived poorly and shouldn't have prevented code from running, it should have just prevented it doing bad things (like adding subscribers, or sharings posts to social media). I get it's a big change and it'll take time, but a week doesn't go by I don't curse JP for this exact thing.

[kraftbj]

Using the JETPACK_STAGING_MODE constant is more akin to what I think you're wanting to use. The issue here, though, is it's intended to be used on a staging site spun off of a connected site, e.g. using WP Engine's one-click staging site system (which activates this mode too).

Everything will look/act exactly like production, except no posts/option changes/data are sent up to WordPress.com and you would not be able to disconnect Jetpack.

[jb510]

Thanks Brandon I wasn't aware of that until your other comment and I'm checking it out.

I love the jetpack_known_staging filter... Going to try adding all our local and dev domain paths to our mu/core plugin.

[jeherve]

Also suggested here:
https://twitter.com/ziodave/status/794934419761012744

[chaselivingston]

Also requested in https://twitter.com/Tmeister/status/840365373815947265

[websupporter]

This would be a great enhancement for devs. Thanks a lot to @BinaryMoon for his workaround. I was playing a bit with the "Related Posts" and maybe someone wants to have a look, if this would be a sane approach: https://github.com/websupporter/jetpack/commit/866418fd4603b17c59769bf809ddd8fcc71ae40c

This approach suggests a new module header Has Staging. If it is set to Yes and staging is active, it overwrites requires_connection. I can imagine this logic might need to have some more thought when it comes to other modules.

The second step was to extend the Customizer Preview and let also staging sites use this preview.

Thanks for taking the time to have a look, if this makes sense :)

[jeherve]

Also mentioned in #8131

[dsifford]

@jeherve Are PRs accepted for this? I'd be willing to take a stab at it when time allows.

[jeherve]

@dsifford Sure thing! This can help you get started:
https://github.com/Automattic/jetpack/blob/master/.github/CONTRIBUTING.md#write-and-submit-a-patch

[dsifford]

@jeherve Ok great, thanks..

I guess one question I have before starting to dive into this is: Fundamentally, why is it a problem if the subscribe and top posts widgets are active on a localhost installation? I can't seem to wrap my head around why that is even an issue to begin with.

Can you maybe clarify that?

[BinaryMoon]

Both of those things require a connection to wordpress.com. For subscriptions, the subscribers are stored on .com and emails are sent from there. For top posts the posts use the stats module.

Personally I don't care about data being accurate (for development purposes) - just that data works. So top posts can just show a list of the latest posts, and the subscription widget just needs to display the widget and a random number of subscribers. There's no need to connect to .com for dev reasons.

You can see my attempt at dummy data for related posts here:
https://github.com/Automattic/jetpack/issues/3673

I still use this for my own local development. No idea if it's the best way to do this or not - but it works for me.

[dsifford]

Thanks @BinaryMoon

I'm still a bit confused. What prevents a local site from connecting to wordpress.com? Just because the site is itself running on 127.0.0.1, doesn't mean it is only able to access resources locally. You can still load whatever resources you need to externally (e.g. images, scripts, etc). There should be no problem with the site making a connection to wordpress.com.

Is it the authentication part of the connection? Does wordpress.com deny requests from sites whose hostname doesn't match the expected hostname of the registered site?

[jeherve]

What prevents a local site from connecting to wordpress.com?

Nothing. As long as you have a working Internet connection, your local site should not have any problems making requests to third-party services. That's why you can download plugins in the Plugins menu, for example.

However, WordPress.com then communicates back to your site, to verify the request. If your site sends a request to say "Hey WordPress.com, my site is google.com, get all the info about that site URL linked to my WordPress.com account so I can access it and edit it.", WordPress.com will make a query back to your site to verify that information, and to make sure that whoever is making the request is allowed to access that information.
However, since your site is hosted locally, it can't be reached from the outside world. That's why things like the Top Posts Widget or the Subscriptions Widget won't work on your local site; WordPress.com can't communicate back with that site to confirm that you are allowed to access and modify stats or the list of subscribers that are stored on WordPress.com.

Back to the issue, and as @BinaryMoon mentioned, we would not really need real information here; the Top Posts Widget could list random posts, or the 10 most recent posts, and that would be enough to style it. The Subscriptions Widget could be displayed normally and display a custom error message whenever someone tries to submit their email address.

Ideally, you would not need to modify the 2 widgets themselves. You would return a custom response here and here when Development mode is active.

[dsifford]

Got it. So it is indeed an authentication issue. Thanks for clarifying @jeherve

I'll check out the two locations you linked to (hopefully) later this week and see if I can come up with something. 👍

[stale[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive in the past 6 months.
• It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

[stale[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive in the past 6 months.
• It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

[mathetos]

I've tried workarounds above and they don't seem to be compatible with version 7.2.1 of Jetpack. Would love to be able to run Related Posts in a local environment specifically for troubleshooting plugin conflicts for technical support reasons.

[stale[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive in the past 6 months.
• It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

[stale[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive in the past 6 months.
• It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.