-
Notifications
You must be signed in to change notification settings - Fork 808
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
Revue Block #14645
Revue Block #14645
Conversation
This is an automated check which relies on |
b1ebc3a
to
a80efae
Compare
376a59d
to
4eae567
Compare
This block looks very similar to our Jetpack Contact Form block. Is there any way we could reuse some of that here? |
For the button, is there any reason we can't use the core button block as a child block? |
Caution: This PR has changes that must be merged to WordPress.com |
@scruffian It occurred to me as well, but then in this case we don't really want for the user to customize the form at all.
This said, I've tried to keep the two as visually consistent as possible in the front end.
Admittedly I haven't tried, but off the top of my head, the Button block outputs an Also, even if Button saved as |
Thanks @Copons! Here are some thoughts after my review:
|
You can read about the rationale in pb5gDS-iT-p2 |
@jeherve @davemart-in The two blocks' needs are slightly different, so the implementation is slightly different as well. So, instead of having a container block with fields as children blocks (like Contact Form), I've hardcoded the three fields (names are still toggleable from the sidebar), and made the label and placeholder customizable. To customize the label, I've had to add a new prop to Contact Form's Now: I realize this is a very last minute change, so if we think it's too big to be tested properly, I can drop it from the PR and open it in a follow up. |
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 looks good to me. I only have some minor comments.
extensions/blocks/revue/revue.php
Outdated
> | ||
<div> | ||
<label> | ||
<?php echo $email_label; ?> |
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.
Should we escape 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.
You're right, this was a big distraction 😞
Updated in b9aa5a0
@davemart-in with Calendly, OpenTable and Google Cal, we removed the Edit option in the block tool bar which took the block back to preview mode to update the embed code, and instead added the embed code setting to the sidebar. In the Review block it has the edit option in the toolbar to update the username, should this be moved into the settings panel also for consistency with the other blocks? |
<TextControl | ||
label={ | ||
<JetpackFieldLabel | ||
label={ emailLabel } |
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.
|
||
const saveUsername = event => { | ||
event.preventDefault(); | ||
setAttributes( { revueUsername: username } ); |
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.
Should we add a .trim() to username here? currently if a user copies and pastes some spaces along with their username by mistake they get a 404 from revue when trying to submit the form.
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 we're in a good place now, and I would suggest merging this as is and addressing the feedback that was left in future PRs.
ob_start(); | ||
?> | ||
|
||
<div class="wp-block-jetpack-revue"> |
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.
Let's use Jetpack_Gutenberg::block_classes()
here maybe?
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 agree with @jeherve, this is in a good place to merge now and then follow up with another PR for the other suggested changes.
Merging for now. @Copons I'll let you handle the WordPress.com part as well as the remaining feedback? Thank you! |
As @jeherve suggested, I think this is good enough to ship. I thinking circling back around and updating this block to remove the Edit option is a good idea after this first iteration ships. Let's go ahead and move that to the sidebar at that point. |
r203320-wpcom |
* 8.3 release: changelog * Changelog: add #14516 * Changelog: add #14574 * Bring in changes from 8.2.1 and 8.2.2 * Update stable version * Bring in 8.2.3 changes * Changelog: add #14714 * Changelog: add #14639 * Changelog: add #14678 * Changelog: add #14673 * Changelog: add #14687 * Changelog: add #14704 * Changelog: add #14702 * Changelog: add #14541 * Changelog: add #14657 * Changelog: add #14622 * Changelog: add #14582 * Changelog: add #14638 * Changelog: add #14633 * Changelog: add #14571 * Changelog: add #14592 * Changelog: add #14539 * Changelog: add #14514 * Changelog: add #14643 * Changelog: add #14494 * Changelog: add #13739 * Changelog: add #14707 * Changelog: add #14736 * Changelog: add #14706 * Changelog: add #14730 * Changelog: add #14685 * Changelog: add #14727 * Changelog: add #14711 * Changelog: add #14742 * Changelog: add #14746 * Changelog: add #14725 * Changelog: add #13999 * Changelog: add #14740 * Changelog: add #14759 * Changelog: add #14703 * Changelog: add #14753 * Changelog: add #14754 * Changelog: add #14645 * Cahngelog: add #14599
Changes proposed in this Pull Request:
For this simple implementation we have decided to not use the Revue API, but simply show a subscription form, linked to a Revue user through its username, that on submit opens Revue in a new tab.
Notes
I've decided to reimplement (yet again) the submit button logic, copying it from the latest Gutenberg version (as of last week) that also has gradient backgrounds available, instead of using our own
SubmitButton
.This is mostly to be as consistent as possible to Core Gutenberg, both on the edit side and on the SSR.
I recognize this is definitely not ideal, and I'd rather use a single button implementation that was as similar to Core Gutenberg's Button block.
@pablinos (since you're working on it) do you think the work in this PR could be a good starting point for a
SubmitButton
update?Form styles aren't typically exposed by the theme to the editor to avoid conflicts with the editor styles. For this reason, the design is slightly different between editor and front end.
I don't have a good solution for this off the top of my head, but maybe I'm missing something. 🤔
Since the submit opens a new tab, going back to the post and seeing the form as nothing happened felt a bit awkward to me.
Currently, 1 second after the submission, when the user is supposedly on the Revue page, the form is replaced by a "You can complete your registration in the new page." message.
This message is not permanent, and it's enough to reload the post to see the form again.
I'm not sold on the copy or the look, and I guess we could embellish them in several ways.
What do you think? (cc @davemart-in)
Is this a new feature or does it add/remove features to an existing part of Jetpack?
Testing instructions:
Proposed changelog entry for your changes: