Forum Replies Created

Viewing 15 replies - 1 through 15 (of 53 total)
  • The fatal error in image_get_intermediate_size() is apparently a separate issue, and you already opened multiple topics about that (the discussion should stay on one of those). The array key warnings appear when the image meta does not have the width or height, but attachment 456 has both of those in the page before it stops on the critical error.

    Redirecting the image attachment pages to the attachment itself should be the quickest way to prevent both errors. Those pages often are not very valuable, and you might benefit from removing them entirely. This is possible without a plugin since WordPress 6.4, but the All-in-One SEO plugin has the option under Search Appearance > Image SEO.

    However, if you appreciate those pages and can fix the fatal error with something else, this is another code snippet to try in a child theme or plugin for the array key warnings (similar to the SVG-related filter above, without restricting the image type).

    function add_missing_attachment_metadata_dimensions( $data ) {
    // A value of 0 is not useful for visitors, but it could prevent errors.
    $data['width'] = isset( $data['width'] ) ? $data['width'] : 0;
    $data['height'] = isset( $data['height'] ) ? $data['height'] : 0;

    return $data;
    }
    add_filter( 'wp_get_attachment_metadata', 'add_missing_attachment_metadata_dimensions', 10, 1 );

    If you have a child theme, you have multiple options. The simplest might be wrapping the printf in a condition like if ( isset( $metadata['width'] ) && isset( $metadata['height'] ) ). That would skip adding the entry meta if the image does not define width and/or height, so you might also want an else fallback.

    Steps:

    1. Add Twenty Eleven’s image.php template in your child theme (if you have not done that already).
    2. Edit the printf code that begins after $metadata = wp_get_attachment_metadata(); with one of the code snippets below (or something else, as you like).
    3. Save changes to the file, and upload it if you are not editing within the admin.
    4. Visit the attachment pages for images, especially any pages you know had the error messages.

    Snippet 1: Checks for width and height before outputting entry meta, and shows only the date if it does not find both dimensions.

    <?php
    $metadata = wp_get_attachment_metadata();
    if ( isset( $metadata['width'] ) && isset( $metadata['height'] ) ) :
    printf(
    /* translators: 1: Time, 2: Date, 3: Image permalink, 4: Image width, 5: Image height, 6: Parent permalink, 7: Parent post title, 8: Parent post title. */
    __( '<span class="meta-prep meta-prep-entry-date">Published </span> <span class="entry-date"><abbr class="published" title="%1$s">%2$s</abbr></span> at <a href="%3$s" title="Link to full-size image">%4$s &times; %5$s</a> in <a href="%6$s" title="Go to %7$s" rel="gallery">%8$s</a>', 'twentyeleven' ),
    esc_attr( get_the_time() ),
    get_the_date(),
    esc_url( wp_get_attachment_url() ),
    $metadata['width'],
    $metadata['height'],
    esc_url( get_permalink( $post->post_parent ) ),
    esc_attr( strip_tags( get_the_title( $post->post_parent ) ) ),
    get_the_title( $post->post_parent )
    );
    else:
    printf(
    '<span class="entry-date"><abbr class="published" title="%1$s">%2$s</abbr></span>',
    esc_attr( get_the_time() ),
    get_the_date()
    );
    endif;

    ?>

    Snippet 2: Checks for width and height individually within the entry meta printf, and gives fallback text if the dimension is not found. (The fallback could be '0' or 'unknown', for example.)

    <?php
    $metadata = wp_get_attachment_metadata();
    printf(
    /* translators: 1: Time, 2: Date, 3: Image permalink, 4: Image width, 5: Image height, 6: Parent permalink, 7: Parent post title, 8: Parent post title. */
    __( '<span class="meta-prep meta-prep-entry-date">Published </span> <span class="entry-date"><abbr class="published" title="%1$s">%2$s</abbr></span> at <a href="%3$s" title="Link to full-size image">%4$s &times; %5$s</a> in <a href="%6$s" title="Go to %7$s" rel="gallery">%8$s</a>', 'twentyeleven' ),
    esc_attr( get_the_time() ),
    get_the_date(),
    esc_url( wp_get_attachment_url() ),
    isset( $metadata['width'] ) ? $metadata['width'] : '0',
    isset( $metadata['height'] ) ? $metadata['height'] : '0',
    esc_url( get_permalink( $post->post_parent ) ),
    esc_attr( strip_tags( get_the_title( $post->post_parent ) ) ),
    get_the_title( $post->post_parent )
    );
    ?>

    The strong tag does work in Firefox with Windows 11, but not in the same way as it does in Chrome and other browsers:

    • Chrome’s default for strong tags is bold.
    • Firefox uses bolder, which is relative to the parent element’s weight.

    In Twenty Twenty-Five’s styles, the body weight is 300 (Light), and the headings are 400 (Regular). Chrome has a bold weight of 700 whether the strong text is in a paragraph or heading. Firefox also has 700 for strong text in the headings, but it only increases the 300 to 400 inside a paragraph for a very slight difference.

    If you like how other browsers show it, the simplest change might be to add Additional CSS:

    1. Open the Editor, under Appearance in the side menu.
    2. Open Styles.
    3. Find “Additional CSS” at the bottom of the style settings, and paste
      strong { font-weight: bold; }
    4. Click the “Review 1 change…”button and then Save.

    @vishy-moghan In the case of the WP Content Copy Protection plugin, you probably can use/reactivate it if you set the ‘Plugin icon on top admin bar’ option to ‘Hidden’ for now. (I suggested a change to the plugin author.)

    62335 was opened for a different issue.

    The screenshots given for Avada and Total themes both show a full-height section in the page content. Could you visit another page in the Customizer to determine if the full-height styles somehow affect the side panel or if you see error messages?

    The only way I successfully reproduced the extra-tall buttons was with Flexy as the active theme and WP_DEBUG on. Showing errors seems to have caused the problem for me, but if your situations result from the same, then the large image would be hiding error messages. Otherwise, it might result from a height or min-height on an element in the Customizer panel (such as the accordion button’s h3) with your themes.

    For a temporary fix, you could try adding this (in a custom plugin):

    function wp670_customize_admin_enqueue_scripts() {
    $css = '.accordion-section-title button.accordion-trigger { height: auto; }';
    wp_add_inline_style( 'customize-controls', $css );
    }
    add_action( 'admin_enqueue_scripts', 'wp670_customize_admin_enqueue_scripts' );

    I can find these two warnings when visiting the attachment page for an SVG because WordPress does not set their (full-size) dimensions in metadata.

    Unless you would prefer disabling all image attachment pages, you could try adding a filter to set both SVG dimensions to 0:

    function svg_attachment_metadata_dimensions( $data ) {
    if (
    ( ! isset( $data['width'] ) || ! isset( $data['height'] ) )
    && isset( $data['sizes']['thumbnail']['mime-type'] )
    && $data['sizes']['thumbnail']['mime-type'] === 'image/svg+xml'
    ) {
    $data['width'] = 0;
    $data['height'] = 0;
    }
    return $data;
    }
    add_filter( 'wp_get_attachment_metadata', 'svg_attachment_metadata_dimensions', 10, 1 );

    The term “mobile view” is not perfectly accurate. The video requires a minimum width of 900 pixels and a minimum height of 500 pixels by default, and zooming in would increase those values. The Customizer panel takes up 300 pixels, so the remainder of a desktop window could easily be under the minimum, too.

    @kel-dc experienced an issue with the video, apparently on a large screen, but the video preview did not appear in the Customizer panel for that situation.

    If you set the Navigation block’s justification to the right edge (third option), that should be a simpler (temporary) fix. The horizontal submenus go inside (against the arrow direction) with right justification.

    If you switch to another block-based theme, you likely would have the same issue with the Navigation block in that theme, too. I was able to find the same problem with Twenty Twenty-Three and Twenty Twenty-Four.

    I think you want to visit the Core Trac preferences page and set new notification rules that include
    “Never notify:” when “Ticket that I previously updated is modified”

    You have added comments on Core 43936 and 23432, so the default settings would subscribe you to notifications when someone modifies those tickets (with or without selecting the Watch option).

    I am not aware of any unsubscribe options for individual Trac tickets. Also, Meta Trac has a similar page if you need to edit that too.

    If your issue is related to Trac 51565, you could:

    1. Go to Appearance and then Menus.
    2. Check each menu item in the selected menu to ensure that it is complete and that it does not include any removed posts.
    3. Click the “Save Menu” button after you have verified the menu’s accuracy.
    4. If you have more than one menu, switch to the others, verify their accuracy and save changes.
    5. Return to Customize to find out if the post_status notices still print.

    If that still does not remove the notices, I recommend changing WP_DEBUG to false in wp-config.php to hide notices and errors.

    The custom font URL should always return a string, though the string can be empty.

    I had used an empty bracket in my own child themes for Twenty Fifteen and/or Twenty Sixteen, so my functions needed updating.

    It still might be worth hardening the function against type errors, especially for those two themes (because they allowed overriding the fonts URL function since version 1.0).

    If you mean the toolbar for Classic and Classic Paragraph blocks, you could try a temporary solution with Admin CSS until the Core fix is available.

    Until the Core fix is available, you could try a temporary solution with Admin CSS.

    Until the Core fix is available, you could try a temporary solution with Admin CSS.

    GB53540 seems to have fixed the sticky positioning in the Gutenberg plugin, and that change should be included in an upcoming WordPress maintenance release.

    For now, you could try adding the following in Admin CSS with a plugin such as Simple Custom CSS and JS or Add Admin CSS.

    .edit-post-visual-editor {
      overflow: visible;
    }

    I’m not sure whether Advanced Editor Tools should include some version of that (maybe using .mceContentBody .edit-post-visual-editor or .version-6-3-1 .edit-post-visual-editor) if it will be fixed in Core soon.

Viewing 15 replies - 1 through 15 (of 53 total)