• Resolved nikdow

    (@nikdow)


    Noticed that jetpack updated from 14.7 → 14.8 at 2025-07-01 20:20:39 (UTC).

    Now if we edit a Registration Form block, the field that was edited shows text “Warning” when the front-end opens the form/page.

    The HTML is

    <span class="visually-hidden">Warning</span>

    Fields that we haven’t edited are not showing the above. If I edit another field, it starts showing the above text.

    I tried turning “required” off, saving and the problem persists. Turned “required” on again.
    The text is even appearing on a Paragraph block within the form.

    The page I need help with: [log in to see the link]

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter nikdow

    (@nikdow)

    Back-graded to Jetpack 14.7 and the Warning text is gone, without touching the form in edit mode.

    Looks like a jetpack bug?
    This site runs an extremely simple theme of our own.

    Plugin Support Animesh Gaurav (a11n)

    (@bizanimesh)

    Hello @nikdow – thanks for reporting the issue!

    Now if we edit a Registration Form block, the field that was edited shows text “Warning” when the front-end opens the form/page.

    I just want to make sure I’m understanding the issue correctly. Could you please confirm if the following steps can reproduce the problem?

    • Install Jetpack v14.7
    • Next, add the Registration Form block and make any editing — for example, set the “Name” field as required.
    • Then, update Jetpack to version 14.8, and the error should appear.

    Could you confirm if the steps mentioned above are correct, or if any additional or specific edits are required to trigger the error? I’m unable to reproduce the issue using above steps, so please let me know if I might be missing something.

    Thread Starter nikdow

    (@nikdow)

    Thanks for those testing suggestions, which I carried out.

    With 14.7 installed, I edited the form. Surprisingly all the blocks within the Registration Form Block were labelled as having invalid content – they were all OK last login. They all responded OK to the recovery button. The form displays correctly in the front end.

    I edited some fields and saved. No problems appear in the front end. With 14.8, editing any field in the form results in the spurious “warning” message.

    Loaded up 14.8 and restarted PHP. Warning messages on all the fields. I’ve put a screenshot here:
    https://drive.google.com/file/d/16L9jL0vbDeXwv7sykUBudxY5q8_ovNuv/view?usp=sharing

    Deleted 14.8 and loaded up 14.7. No warning messages.

    Could there be something missing from our theme causing this behaviour?

    Plugin Support Chatoxz (a11n)

    (@chatoxz)

    Hello there, Sebastian from Jetpack here. I hope you are doing well.

    Thanks for the extra details.

    I tried the steps mentioned, but I was not able to reproduce this on my test site.

    I did a quick review, and I noticed an error with the connection between your site and Jetpack. Jetpack needs this connection to function correctly for most of its features, and this issue could be related.

    To be more specific, I am seeing a 401 error code. If a site has HTTP 401 protection (HTTP Basic) enabled, then Jetpack will not be able to communicate with the site unless special allowances are made. Please get in touch with your hosting provider and ask them to check this, and let us know so we can review the connection again.

    Additionally, can you please reach out to us from this form https://jetpack.com/contact-support/?hpi=1 and mention this forum thread?

    Cheers,

    Camille Spain

    (@moonjellydigital)

    I’ve noticed the problem @nikdow describes on multiple sites running classic or hybrid themes. I haven’t seen the problem on any of the numerous sites with different FSE (full site editing) themes I’ve updated.

    For some reason there’s Jetpack plugin CSS that gets loaded on FSE themes but doesn’t always get loaded on classic and hybrid themes.

    To fix the “Warning” text under the form fields you can add the CSS for a class named .visually-hidden. The Jetpack CSS for this class looks like this:

    .visually-hidden {
    clip: rect(0 0 0 0);
    clip-path: inset(50%);
    height: 1px;
    overflow: hidden;
    position: absolute;
    white-space: nowrap;
    width: 1px;
    }

    If a form validation error message is showing above your submit button, you can add the styles for that too. The HTML you’re looking for is this:

    <div class="contact-form__error" data-wp-class--show-errors="state.showFromErrors">
    <span class="contact-form__warning-icon">
    <span class="visually-hidden">Warning.</span><i aria-hidden="true"></i>
    </span>
    <span data-wp-text="state.getFormErrorMessage">Please fill out the form correctly.</span><ul> </ul>
    </div>

    Here’s the Jetpack CSS I’m getting on block themes when the form doesn’t have a validation error:

    .contact-form__error {
    background-color: var(--jetpack--contact-form--error-color);
    color: var(--jetpack--contact-form--inverted-text-color);
    display: none;
    gap: var(--warning-icon-margin);
    padding: 1em;
    }

    When there’s a form validation error Jetpack adds the class show-errors to the contact-form__error div like so:

    <div class="contact-form__error show-errors" data-wp-class--show-errors="state.showFromErrors">
    <span class="contact-form__warning-icon"><span class="visually-hidden">Warning.</span><i aria-hidden="true"></i></span>
    <span data-wp-text="state.getFormErrorMessage">Please fill out the form correctly.</span><ul> </ul>
    </div>

    The CSS for when there’s a form error is this:

    .contact-form__error.show-errors {
    box-sizing: inherit;
    display: inline;
    min-width: 100%;
    }

    Or you can write your own styles for those classes if the default Jetpack CSS doesn’t match the theme.

    Thread Starter nikdow

    (@nikdow)

    Thanks Camille. I located the problem in index.php in our theme, which I’ve reproduced below. Located but not diagnosed, instead I went back to an earlier index.php in our most basic theme, located 2nd below. Problem went away. I then made a child theme to fix the layout provided by index.php so it matches the broken one, still no problem with JetPack 14.8, so we are good for now.

    The theme that breaks for jetpack 14.7:

    <?php get_header(); ?>
    <section class="entry-content">
    <div class="gc-content">
    <?php
    global $wp_query;

    if ( is_category() || is_archive() || is_home() ){

    $posts = new WP_Query( $wp_query->query_vars );

    if ( $posts->have_posts() ) {
    while ( $posts->have_posts() ){
    $posts->the_post(); ?>
    <div class="post">
    <h2><a href="<?php the_permalink(); ?>"><?php echo get_the_title(); ?></a></h2>
    <a href="<?php the_permalink(); ?>#comments"><span><?php echo get_comments_number(); ?> Replies</span></a>
    <?php the_post_thumbnail(); ?>
    <?php the_content(); ?>
    </div>
    <?php
    }
    }
    } else {
    the_content();
    }
    ?>

    <?php if ( get_comments_number() > 0 ): ?>
    <?php comments_template(); ?>
    <?php endif; ?>

    </div>
    <div class="gc-sidebar">
    <?php include_once "sidebar.php"?>
    </div>
    </section>
    <?php get_footer(); ?>

    and our old theme that doesn’t have the issue, but doesn’t have the required sidebar:

    <?php
    /**
    * The main template file
    *
    * This is the most generic template file in a WordPress theme
    * and one of the two required files for a theme (the other being style.css).
    * It is used to display a page when nothing more specific matches a query.
    * e.g., it puts together the home page when no home.php file exists.
    *
    * Learn more: {@link https://codex.wordpress.org/Template_Hierarchy}
    *
    */

    get_header(); ?>
    <div id="primary" class="content-area">
    <main id="main" class="site-main" role="main">

    <?php
    // Start the loop.
    while ( have_posts() ) : the_post();

    // Include the page content template.
    get_template_part( 'content', 'page' );

    // If comments are open or we have at least one comment, load up the comment template.
    if ( comments_open() || get_comments_number() ) :
    comments_template();
    endif;

    // End the loop.
    endwhile;
    ?>

    </main><!-- .site-main -->
    </div><!-- .content-area -->

    <?php
    get_footer();

    So we adapted the above index.php to add back in the sidebar, via a child theme:

    <?php
    /**
    * The main template file
    *
    * This is the most generic template file in a WordPress theme
    * and one of the two required files for a theme (the other being style.css).
    * It is used to display a page when nothing more specific matches a query.
    * e.g., it puts together the home page when no home.php file exists.
    *
    * Learn more: {@link https://codex.wordpress.org/Template_Hierarchy}
    *
    */

    get_header(); ?>
    <section class="entry-content">
    <div class="gc-content">

    <?php
    // Start the loop.
    while ( have_posts() ) : the_post();

    // Include the page content template.
    get_template_part( 'content', 'page' );

    // If comments are open or we have at least one comment, load up the comment template.
    if ( comments_open() || get_comments_number() ) :
    comments_template();
    endif;

    // End the loop.
    endwhile;
    ?>

    </div><!-- .site-main -->
    <div class="gc-sidebar">
    <?php include_once "sidebar.php"?>
    </div>
    </section><!-- .content-area -->

    <?php
    get_footer();
    • This reply was modified 4 months, 3 weeks ago by nikdow.
    Camille Spain

    (@moonjellydigital)

    Glad to hear you found a fix for your theme, @nikdow.

    Located but not diagnosed has been my experience with getting all the styles to load on non-block themes, and not just with JetPack. I think it’s interesting that the non-working one uses a custom query and the final version you posted doesn’t.

    One of my clients’ sites has a problem on some versions of WordPress with not loading the styles for the block header and footer on PHP templates (added with do_blocks). The site started with a block theme, but then we had to add a couple PHP templates because of conditional logic. And the templates have to use custom queries because they do fancy things with custom post types.

    Looking at your templates makes me wonder if using a custom query loop is more likely to cause problems with loading styles.

    Plugin Support lastsplash (a11n)

    (@lastsplash)

    Hi @nikdow and @moonjellydigital

    I have shared the additional discussion here with our Jetpack development team so that they can investigate further to see if they can determine the issue.

    If you can point to a theme (or themes) in WordPress.org that cause the issue, that might help them narrow it down.

Viewing 8 replies - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.