WordPress.org

Ready to get started?Download WordPress

Forums

WP Statistics
[resolved] deprecations and other WP_DEBUG warnings (11 posts)

  1. kitchin
    Member
    Posted 7 months ago #

    Here are a few others:

    includes/includes/functions.php Line 58.
    Change
    return $result[0];
    to
    return $result ? $result[0] : 0;

    wp-statistics.php Lines 111-140
    All these add_menu()'s should have unique
    'id' => 'wp-statistic_menu-001',
    etc.

    wp-statistics.php Lines 223
    For
    $log_type = $_GET['type'];
    $log_type = @$_GET['type'];
    is good enough but
    $log_type = preg_replace('/[^\w-]/', '', (string)@$_GET['type']);
    is a lot safer if your code morphs in the future.

    The problem is people use WP_DEBUG, often with backtraces, to develop other plugins. So if yours is emitting a bunch of stuff, it gets in the way!

    http://wordpress.org/plugins/wp-statistics/

  2. Greg Ross
    Member
    Plugin Author

    Posted 4 months ago #

    All known debug warnings have been resolved in current version, closing thread.

  3. kitchin
    Member
    Posted 2 weeks ago #

    The add_menu()'s are still causing warnings. Here is the fix.

    wp-statistics.php Line 283 (version 7.0.2)

    $wp_admin_bar->add_menu( array(
    	'id'		=>	'wp-statistic-menu-001', // *fix*
    	'parent'	=>	'wp-statistic-menu',
    	'title'		=>	__('User Online', 'wp_statistics') . ": " . wp_statistics_useronline()
    ));
    
    ... [4 more similar fixes then]...
    
    $wp_admin_bar->add_menu( array(
    	'id'		=>	'wp-statistic-menu-006', // *fix*
    	'parent'	=>	'wp-statistic-menu',
    	'title'		=>	__('View Stats', 'wp_statistics'),
    	'href'		=>	get_bloginfo('url') . '/wp-admin/admin.php?page=wp-statistics/wp-statistics.php'
    ));
  4. Greg Ross
    Member
    Plugin Author

    Posted 2 weeks ago #

    Can you try using:

    'id'		=> 	false,

    instead and see if it clears up the warning as well?

  5. kitchin
    Member
    Posted 2 weeks ago #

    Id should not be empty.

    wp-includes/class-wp-admin-bar.php

    if ( empty( $args['id'] ) ) {
    	// [ checks for other problems, then: ]
    	_doing_it_wrong( __METHOD__, __( 'The menu ID should not be empty.' ), '3.3' );
    	// Deprecated: Generate an ID from the title.
    	$args['id'] = esc_attr( sanitize_title( trim( $args['title'] ) ) );
    }
  6. Greg Ross
    Member
    Plugin Author

    Posted 2 weeks ago #

    False isn't empty, from the WordPress Manual:

    Arguments
    $defaults = array(
    	'href' => false,
    	'parent' => false, // false for a root menu, pass the ID value for a submenu of that menu.
    	'id' => false, // defaults to a sanitized title value.
    	'meta' => false // array of any of the following options: array( 'html' => '', 'class' => '', 'onclick' => '', 'target' => '', 'title' => '' );
    );
  7. kitchin
    Member
    Posted 1 week ago #

    That part of the manual is way out of date, I'll fix it. The problem here is for other developers who use WP_DEBUG to catch coding mistakes. You have minor warnings on other Dashboard pages for undefined variables indexes and stuff, but this particular one pollutes all Dashboard pages, so really gets in the way. I'm on the verge of writing my own script to fix your code each time you push an update.

    Steps to reproduce (plugin ver. 7.0.4):

    1. define('WP_DEBUG', true) in wp-config.php.

    2. Dashboard / Statistics / Settings / Show stats in menu bar / true

    3. Dashboard

    Results:

    Notice: WP_Admin_Bar::add_node was called incorrectly. The menu ID should not be empty. Please see Debugging in WordPress for more information. (This message was added in version 3.3.) in /../wp-includes/functions.php on line 3245

    (Repeated 6 times.)

    Expected Results:

    No warnings.

    Also, there's a ton of files in wp-content/plugins/wp-statistcs/vendor/ you can leave out. GeoIP is great, a geo lookup that doesn't need giant db tables, and it's just as fast in my testing (can't recall which was faster, they were close enough). But GeoIP distributes with that composer junk: guzzle, symfony and all that. Probably none of it is used. I figured out how to get rid of it in my plugins, could probably do the same in yours. Tell me if you want the code.

  8. Greg Ross
    Member
    Plugin Author

    Posted 1 week ago #

    Strange the documentation was clear but I agree it doesn't behave that way, so I've added in menu item id's for them. It will be in the next release.

    I agree the other junk is annoying, but not so much I really want to mess with it all that much ;)

    I've cleared up a pile of other WP_DEBUG warnings as well.

  9. kitchin
    Member
    Posted 1 week ago #

    The documentation is basically Wikipedia. It's community edited. The real documentation is in the PHP files at the head of each function (usually).

  10. kitchin
    Member
    Posted 1 week ago #

    I should amend that. The documentation we're talking about (Function Reference) now has that highlighted link to the new "WordPress Reference," which is supposed to be canonical and derived from the source in-line documentation. But for example the entry for "add_menu" is pretty sparse:
    http://developer.wordpress.org/reference/classes/wp_admin_bar/add_menu/

    And fuller entries still need formatting work:
    http://developer.wordpress.org/reference/classes/wp_admin_bar/add_node/

    IMHO, the community edited Function Reference should be getting the official attention from WP that instead went to building that new WP Reference tool. It's never going to have all the examples and discussion that make the web smart.

  11. Greg Ross
    Member
    Plugin Author

    Posted 1 week ago #

    The codex is still a better resources at this point and still official documentation. At the end of the day though you have to go with what works, not what's documented ;)

Reply

You must log in to post.

About this Plugin

About this Topic

Tags