Bug report: quick status in *every* loop

Last week I was thrilled to start playing with the Status plugin. It really is awesome. I'm using it heavily on a couple large sites now and a new pet project. But...

When you configure front-end display, it loads itself in "the_loop". That's cool. I like how it operates in the content part of the theme. But it's also loading again wherever the_loop is being called, for example, in the "recent posts" sidebar widget.

I don't exactly "hate" it, but this is weird, to say the least. Any way to defuse this behavior?

  • thescottbishop

    This is actually a bug I've been able to narrow down to the use of is_front_page() in the lib/class_wdqs_public_pages.php file. Pretty much, is_front_page() always returns true if query_posts is used to generate the current loop.

    To get around this, you need get is_front_page() before any template/plugin can override it with query_posts, and then store it for future use. I've gone ahead and attached a modified class_wdqs_public_pages.php - it stores the value during the wp action, and then references that instead.

    You'll have to correct this bug for every update, but hopefully this will get resolved by the authors here soon.



    I can't upload the file, so I've pasted the relevant code below:

    Starting at line 66:

    private function _check_permissions () {
    		global $current_user;
    		if (!current_user_can('publish_posts')) return false;
    		if (!$current_user->ID) return false;
    		if ($this->data->get('show_on_front_page') && !$this->_is_front_page) return false;
    		return true;
    	var $_is_front_page = false;
    	function wp() {
    		$this->_is_front_page = is_front_page();
    	function add_hooks () {
    		// Step0: Register options and menu
    		if (!$this->data->get('show_on_public_pages')) return false;
    		add_action('wp_print_scripts', array($this, 'js_load_scripts'));
    		add_action('wp_print_styles', array($this, 'css_load_styles'));
    		add_action('wp', array($this, 'wp'), 100);
    		add_action('loop_start', array($this, 'status_widget'), 100);
  • thescottbishop

    Turns out, there is a second issue - probably the one experienced by the original poster. If a custom wp_query object is used to display a subsequent loop, it will also insert the plugin. I've overcome this by checking to make sure that the current loop is the global loop.

    Line 60:

    function status_widget ($query) {
    		global $wp_query;
    		if ($query !== $wp_query) return false; //Make sure this is not a custom query object
    		if (!$this->_check_permissions()) return false;
    		echo "<div>";
    		include(WDQS_PLUGIN_BASE_DIR . '/lib/forms/dashboard_widget.php');
    		echo "</div>";
  • Shawn

    Scott - your code successfully eliminates the second instance of the status widget on public pages. THANK YOU!

    This fix ALSO effectively makes it remember more than just the subject of a new post. Duplicate 'status widgets' on public pages must somehow effect multiple submission forms which prevented anything except the title of my new post to be preserved, so I'd have to go into the 'posts' page and edit each one to recreate the content. I meant to come back and report that when I had a moment. This is the first free moment. :wink:

    Anyway, this fixes that issue, so now I have a few sites where I can quick post and actually create content again. Thanks!

  • thescottbishop

    Turns out, there is a second issue - probably the one experienced by the original poster

    Yea sorry - had recognized that by the second reply. The first fix addresses issues where you have "Show on front page only" selected, but use "query_posts()" to modify a loop on an internal page. The first reply above addresses that separate problem. Granted, "query_posts" is such a p.o.s. solution, and should really be replaced by a new wp_query object instead in all cases, that I could see you deciding not to address it on a standards viewpoint - but that's up to you.

    Either way, I probably should start a new thread as it's a different issue, but I hadn't realized that when I first posted.


  • Shawn

    @phil, this isn't an edit to WP core, just the one plugin file (lib/class_wdqs_public_pages.php).

    This fix does effectively eliminate the second instance, and it also ensure that the posts you publish thru Status on a page where previously two widgets appeared actually work. Prior to this the situation was that the content wouldn't get posted, only the title. I thought it was just me until I changed widgets to remove the 'recent posts' widget and then the content miraculously started being posted thru. Scott's fix above (or something equivalent) should be incorporated into the plugin to ensure that the plugin works in these situations.

    Oh, and the 'display on public pages vs login' issue I was having is somehow related to WP Firewall. It doesn't like a domain with "firefox" in it.

  • thescottbishop

    I hate to bring up this thread again, but the current download (1.2) for Quick Status includes no fix for any of the issues addressed above. As Elite stated, this isn't an edit to the WP core, just the one plugin file.

    I can either edit multiple other plugins and themes which use the WP_Query object in the standard expected manner, or I can edit the one issue in your plugin.

    Either way, I dislike having to make these edits every time you push an update of the plugin. Please implement a fix.

    I do like Phil's idea of using a custom hook to implement the widget, but that requires editing the plugin file as well, so we're at square one with that as well. It would be nice if, for example, you could disable all automatic insertion and then insert a function like "quick_status()" into your template wherever you want it to display.

    Despite my complaints, this is a great plugin. Just want to get it fully working.

  • Vladislav


    The latest plugin release (v1.3, just released) comes with several new options for placement on public pages, and some improvements to the old ones. Namely, the plugin now includes a safeguard that should prevent it from being included multiple times when using default placement options.

    Also, for advanced usage scenarios you could also opt to use your own, custom hook instead of the default one, or opt out of automatic inclusion on public pages altogether. If you decide to place the box manually, you can do that by adding a function call to your theme, to a place you wish to have your box rendered, like this:

    <?php if (function_exists("wdqs_quick_status")) wdqs_quick_status(); ?>

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.