Forum Replies Created

Viewing 14 replies - 1 through 14 (of 14 total)
  • Plugin Author Sammy Nordström

    (@samface)

    As an update and final comment on this issue; the latest release (v0.5.1) fixes some php warnings/notices, although I suspect some may still show the first time you install and not all variables are defined yet.

    However, it should be noted that this plugin has yet to be released as version 1.0, ie it’s not yet a full stable release. Consider it more like a public beta and that issues like this is to be expected. This because the code base is still being refactored from release to release, making it futile to write error checks for every variable that is almost certain to be rendered obselete in the next rewrite anyways. Once we’re closing up on a real stable release though, of course it should not be ignored nor left uncared for. With that in mind, I thank you once again for your feedback and mark this topic as resolved.

    Plugin Author Sammy Nordström

    (@samface)

    Not sure what you mean by hardcoding but the log file path you are referring to is just the default setting that you may set to any path you like under the General Settings tab. Just make sure it’s a path that the webserver has write access to.

    Plugin Author Sammy Nordström

    (@samface)

    We do have the tools and processes for developing with CI, although Travis really doesn’t do the trick for us since it only supports Github and we strongly prefer Bitbucket. We use Jenkins in combination with Sauce on Demand by Sauce Labs. It’s really neat stuff if you’re interested in that kind of thing. However, errors like the above are still prone to go undetected when you haven’t foreseen all possible scenarios and/or just haven’t got the resources to anticipate them. As with so many other projects like these, it’s matter of time and money resources rather than tools or know how.

    Plugin Author Sammy Nordström

    (@samface)

    Hi!

    Thank you for notifying us. We do develop with debugging on, it’s just not a guarantee for detecting all issues. In this case, it’s probably a matter of variables that is loaded from the database that was set in our development environment but not when doing a fresh install. We should of course have tested for this as well, but as an open source project without paying customers to finance the development, we apply the release early release often philosophy.

    So again, thank you for letting us know and expect it to be fixed in our next update. 🙂

    Plugin Contributor Sammy Nordström

    (@samface)

    We’re happy to report that the issue we had has now been resolved and that it was not caused by the Simple Fields plugin at all. In other words, disregard our bugreport. 🙂

    Sorry if we sent you on a wild goose chase.

    Plugin Contributor Sammy Nordström

    (@samface)

    It’s an issue with TinyMCE, with WP 3.9 comes TinyMCE 4. The visual editor needs to be instantiated a bit differently. I fixed it in another project like this:

    // The old way of adding TinyMCE to a textarea:
    // tinyMCE.execCommand('mceAddControl', false, id); 
    
    // The new way:
    ed = new tinyMCE.Editor(id, tinyMCE.settings, tinyMCE.EditorManager);
    ed.render();

    Not sure of how applicable it is to Simple Fields (the sources have been refactored several times over since I worked on it), but hopefully it is of some help. 🙂

    Thread Starter Sammy Nordström

    (@samface)

    That didn’t work entirely as expected. As it turns out, you need to do it a bit differently to ignore sticky posts in Ajax requests as well. I ended up doing it as a plugin in order to hook into the right actions and filters, like this:

    <?php
    /*
    Plugin Name: BP Ignore Sticky Groups
    Description: A plugin to ignore sticky groups everywhere except on the groups page
    Version: 1.0
    Requires at least: 3.6
    Tested up to: 3.8
    Author: samface, angrycreative
    Author URI: http://angrycreative.se
    License: GPLv2
    Network: true
    Text Domain: bp-ignore-sticky-groups
    Domain Path: /languages/
    */
    function bp_ignore_sticky_groups() {
    	$bp =  buddypress();
    
    	if( bp_is_active( 'groups' ) && class_exists('BP_Sticky_Groups') ) {
    
    		if( empty( $bp->groups->extend ) )
    			$bp->groups->extend = new stdClass();
    
    		if( empty( $bp->groups->extend->bp_sticky_groups ) )
    			$bp->groups->extend->bp_sticky_groups = BP_Sticky_Groups::instance();
    
    		function allow_sticky_groups() {
    			if (!is_admin() || (defined('DOING_AJAX') && DOING_AJAX)) {
    				remove_action( 'bp_groups_get_paged_groups_sql', 'disallow_sticky_groups', 1, 1 );
    				add_filter( 'bp_groups_get_paged_groups_sql', array( BP_Sticky_Groups::instance(), 'alter_bp_groups_query' ), 10, 2 );
    			}
    		}
    
    		function disallow_sticky_groups( $sql = "" ) {
    			if (!is_admin() || (defined('DOING_AJAX') && DOING_AJAX)) {
    				remove_filter( 'bp_groups_get_paged_groups_sql', array( BP_Sticky_Groups::instance(), 'alter_bp_groups_query' ), 10 );
    				add_action( 'bp_groups_get_paged_groups_sql', 'disallow_sticky_groups', 1, 1 );
    			}
    			return $sql;
    		}
    
    		add_action( 'bp_before_groups_loop', 'allow_sticky_groups', 1 );
    		add_action( 'bp_after_groups_loop', 'disallow_sticky_groups', 1 );
    
    		add_action( 'bp_groups_get_paged_groups_sql', 'disallow_sticky_groups', 1, 1 );
    	}
    
    }
    
    add_action( 'bp_include', 'bp_ignore_sticky_groups' );

    Preferrably the Sticky Posts plugin would enable the site admin to choose when and where the sticky posts should be applied, but the above solution does the trick for me right now.

    Thread Starter Sammy Nordström

    (@samface)

    Oh sorry, forgot about a line of code that needs to be at two due places within the function ‘duplicate_post_plugin_upgrade()’ of the file duplicate-post-admin.php:

    add_option('duplicate_post_copyauthor','0');

    And THAT should be it. 🙂

    Thread Starter Sammy Nordström

    (@samface)

    Btw, I work for a company that supports and maintains a multitude of WordPress-sites and this problem occurs in the same manner on all WordPress-installations having this plugin. Due to this we have to write down all UA-codes before updating and then switch over to Firefox after completing the updates for manually re-entering the UA-codes. I can’t imagine this how it is supposed to work.

    Tried resetting all settings too, btw. No improvement.

    I’m having the same issue. Furthermore it refuses to let me enter a UA-code manually. Ticking the box does absolutely nothing. It keeps wanting me to authenticate with a google-account. What am I doing wrong?

    Thread Starter Sammy Nordström

    (@samface)

    btw: we have a dedicated server with gdlib 2.1, debian 7, nginx, php5-fpm.

    Plugin Contributor Sammy Nordström

    (@samface)

    Hi sguk!

    Like plux wrote, thanks for the feedback! We knew that there were more bugs that needs fixing when releasing this update but we felt the bug fixes in this update needed to be released now so that the plugin would atleast be usable with WP 3.3, even if with a few glitches.

    Now, keep reporting bugs and watch out for more updates coming soon! 🙂

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