Please Fix class-wp-widget-factory.php

  • peteschenkel

    (@peteschenkel)


    3 weeks, 2 days ago

    This is relatively simple and very logical request.

    Please fix this:

    ./wp-includes/class-wp-widget-factory.php
    public function __construct() {
    add_action( ‘widgets_init’, array( $this, ‘_register_widgets’ ), 100 );
    }

    public function register( $widget ) {
    if ( $widget instanceof WP_Widget ) {
        $this->widgets[ spl_object_hash( $widget ) ] = $widget;
    } else {
        $this->widgets[ $widget ] = new $widget(null, null);
    }
}

    Every time I do a WP upgrade, I have to add a stupid null to the new $widet reference because it is required per the instructions of the class constructor, and your are not doing so.

    Would it be too much to ask that you please meet the requirements defined of the class constructor here and pass it the parameters to which you have defined it requires?

    Thank you.

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter peteschenkel

    (@peteschenkel)

    3 weeks, 2 days ago

    It is a disaster if it breaks, it cannot complete the upgrade and it’s a spaghetti mess to work your way out to make it work. If it fails, this is my way out:


    if ( ! is_multisite() ) {
    TODO COMMENT OUT THESE LINES
        //wp_redirect( admin_url( 'upgrade.php?_wp_http_referer=' . urlencode( wp_unslash( $_SERVER['REQUEST_URI'] ) ) ) );
        //exit;
    }

    /**
     * Filters whether to attempt to perform the multisite DB upgrade routine.
     *
     * In single site, the user would be redirected to wp-admin/upgrade.php.
     * In multisite, the DB upgrade routine is automatically fired, but only
     * when this filter returns true.
     *
     * If the network is 50 sites or less, it will run every time. Otherwise,
     * it will throttle itself to reduce load.
     *
     * @since MU (3.0.0)
     *
     * @param bool $do_mu_upgrade Whether to perform the Multisite upgrade routine. Default true.
     */
    // TODO - Add this line
    require_once('/web/html/hfwordpress/wp-includes/ms-functions.php');
    if ( apply_filters( 'do_mu_upgrade', true ) ) {
        $c = get_blog_count();
    Nithin – WPMU DEV Support

    (@wpmudevsupport11)

    3 weeks, 2 days ago

    Hi @peteschenkel,

    Modifying the files in WordPress isn’t recommended; you have to pass null because widget instantiation is failing due to missing parameters, which would suggest there is a conflict.

    Did you try to rule out that the issue isn’t due to 3rd party plugins/themes?

    Please do try to run a conflict test and see if you are able to replicate the issue with a default WP theme and with all the plugins disabled without passing null.

    The above should help to rule out what might be causing.

    I was able to find a similar report here:
    https://core.trac.wordpress.org/ticket/56127

    Please refer the above for more info.

    Regards,

    Nithin

    Thread Starter peteschenkel

    (@peteschenkel)

    3 weeks, 2 days ago

    I told you the problem exactly. Please refer to the constructor requirements, and the missing requirement that is not being passed.

    threadi

    (@threadi)

    3 weeks, 2 days ago

    First of all:
    Thank you for your ideas and suggestions for optimizing the open source code of WordPress. It’s great that you’ve investigated the cause of your problem in more detail.

    For a more accurate assessment of the problem, it would be good to have a precisely reproducible scenario that developers making changes to the code can refer to in order to look into it. This includes, for example, using the latest version of WordPress (6.8.1) without any plugins and with a standard theme. Since you are concerned with classic widgets, the TwentyTwentyOne theme would be ideal.

    Do you have the problem in exactly this configuration? If not, I would recommend that you first rule out possible causes in your project. Deactivate all plugins and switch the theme to TwentyTwentyOne. Does the problem still occur? Then describe your procedure again here so that it can be reproduced.

    Why am I asking this and why is it necessary?

    We are in a forum where users help other users. Normal WordPress users like @wpmudevsupport11 and I are here to help you, who are also a normal user. If the problem you described can be reproduced in the above-mentioned ways, you (or someone who is able to reproduce what you describe) can open a ticket for it in the Core Trac mentioned above. Developers who extend and optimize the core work through the tickets there. Most of them are not active here in the forum, and the forum does not serve as a starting point for changes to the core, but it can provide incentives for a ticket in Core Trac.

    I still like to use classic themes from time to time and have never encountered the problem you describe. Therefore, I would be very interested in a detailed description, as described above, from you.

    In summary:
    Please describe your project structure in more detail so that it can be reproduced.

    Thread Starter peteschenkel

    (@peteschenkel)

    3 weeks, 1 day ago

    Provide me a place to send you 2 images and it will prove my point. They are diffs.

    threadi

    (@threadi)

    3 weeks, 1 day ago

    You are also welcome to provide screenshots. Here in the forum you can do this as described here: https://wordpress.org/support/forum-user-guide/block-editor/#adding-screenshots

    However, screenshots probably do not replace the conditions described above to recreate your scenario. I am curious to see what can be seen, but I would still like to ask you for the above information so that we can help you in some way.

Viewing 6 replies - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.

Tags