Forum Replies Created

Viewing 15 replies - 91 through 105 (of 138 total)
  • Thread Starter John Sundberg

    (@bhwebworks)

    Hey Stephen,

    Thanks for taking care of that bug.

    I’ll keep that Gist snippet handy in case that error message shows up again.

    Unfortunately, its impossible from the message to determine which nonce check failed, and in my experience it’s usually because a plug-in is performing a nonce check when it shouldn’t be (i.e. the associated action is not being performed).

    Based on what you said there, would it make sense that the nonce check originated from EO, and because the event deletion wasn’t actually being performed due to the bug it resulted in the error message?

    John Sundberg

    (@bhwebworks)

    This filter worked for me, as long as the CPTs are hierarchical but don’t have page attributes.

    /**
     * Filter Simple Page Ordering to exclude Pages but include custom post types that are hierarchical but don't have page attributes
     *
     */
    
    	add_filter( 'simple_page_ordering_is_sortable', 'bhww_turn_off_simple_page_ordering_for_pages' );
    
    	function bhww_turn_off_simple_page_ordering_for_pages( $sortable ) {
    
    		$screen = get_current_screen();
    		$post_type = $screen->post_type;
    
    		$sortable = ( ! post_type_supports( $post_type, 'page-attributes' ) && is_post_type_hierarchical( $post_type ) );
    		return $sortable;
    
    	}

    The original Metro theme filtered the widget titles but did it in such a way that it conflicts with some plugins, like Jetpack. I wrote a blog post about it here, and created a plugin called Metro Theme Widget Titles that fixes the problem.

    Plugin Author John Sundberg

    (@bhwebworks)

    It does now, as of version 0.2.

    Marking as resolved…

    I ran into this issue with Tortoise SVN this past weekend.

    What worked for me was to do the initial SVN Checkout using https://plugins.svn.wordpress.org/[plugin-name] instead of http://

    After trying that I was able to commit, tag, and make changes to the repository to my heart’s content. πŸ™‚

    I don’t know if this is a bug in Tortoise SVN, or an obscure setting that I haven’t found yet. Either way, using https solved the issue for me.

    Plugin Author John Sundberg

    (@bhwebworks)

    You’re welcome!

    Thread Starter John Sundberg

    (@bhwebworks)

    Thank you Sam! Much appreciated!

    John

    Thread Starter John Sundberg

    (@bhwebworks)

    Actually, this gave me a good excuse to clean-up and revise some of the CSS changes I’ve made in the past to the EO calendar.

    I’m using this plugin on a site with WordPress 3.5.1 and Gravity Forms 1.7.5, and a form that creates custom post types along with the associated taxonomies, and it seems to working the way it’s supposed to.

    Thread Starter John Sundberg

    (@bhwebworks)

    Yep, it’s fixed. Thanks Stephen!

    Thread Starter John Sundberg

    (@bhwebworks)

    Thanks for the tip!

    For anyone else faced with this issue on the StudioPress Metro theme, this is what I came up with.

    Comment out this code in functions.php, like so:

    // Add span class to widget headlines
    /* add_filter( 'widget_title', 'metro_widget_title' );
    function metro_widget_title( $title ){
    	if( $title )
    	return sprintf('<span class="widget-headline">%s</span>', $title );
    } */

    You could also remove that code instead of commenting…up to you.

    Then you’ll have to create a plugin or mu-plugin with the following code, or something similar. I tried it in functions.php and it only affected the footer widgets, and not the sidebar widgets. WP Smith has an explanation on his site for why this is so, and you can find the link to that post in the code below:

    /**
     * Add span class to widget headlines
     *
     * @param  array $defaults Genesis defaults.
     * @return array           Modified Genesis defaults.
     *
     * @link http://wpsmith.net/2012/genesis/how-to-filter-the-genesis-sidebar-defaults/
     */	
    
    add_filter( 'genesis_register_sidebar_defaults', 'bhww_metro_widget_title' );
    
    function bhww_metro_widget_title( $defaults ) {
    
    	return 	array(
    		'before_widget' => '<div id="%1$s" class="widget %2$s"><div class="widget-wrap">',
    		'after_widget'  => "</div></div>\n",
    		'before_title'  => '<h4 class="widgettitle"><span class="widget-headline">', //Modified
    		'after_title'   => "</span></h4>\n", //Modified
    	);
    
    }
    Thread Starter John Sundberg

    (@bhwebworks)

    Thought I’d revisit this thread with some feedback after helping several clients with their events over the past couple months. Both are using current versions of WP and EO.

    One thing I’ve noticed is that on the admin Calendar View, when I delete an occurrence or break a series the calendar view goes back one month from the month I was viewing. So if I do this today (May 7) for an event in May, the calendar view reverts to April when it refreshes, even though April is finished already.

    I tried this again just now with a ‘test’ future recurring event set for five days in November. Each time I broke the series or deleted an occurrence the calendar view went back one month to October.

    —————–

    Regarding ‘breaking the event’ actually taking you to the Edit Event page instead of leaving you in the Calendar View (one month back…), what if this were an option in Event Organiser settings? I realize the downside of that is bloating the plugin with too many options, but for usability it could be a good option to have available.

    I see what you’re saying about using Calendar View for most of the admin workflow, as it’s much easier to see your events in a logical view, and being able to break a series or delete an occurrence from the calendar works really well.

    Still, I’d really like to see being able to go directly to the event edit page after breaking a series, since the reason I’d be breaking a series would be to edit that particular occurrence.

    Thread Starter John Sundberg

    (@bhwebworks)

    Stephen,

    Just sent a pull request on GitHub with this change.

    John

    Thread Starter John Sundberg

    (@bhwebworks)

    This is what I came up with:

    In includes/event-organiser-ajax.php I added this code at line 135:

    //Add class if all day
    if( eo_is_all_day() )
    $event['className'][] = 'eo-all-day';

    which adds the class ‘eo-all-day’ to all day events allowing me to specifically target the CSS for those events.

    Think this could be added to the plugin?

    Thread Starter John Sundberg

    (@bhwebworks)

    Excellent!

Viewing 15 replies - 91 through 105 (of 138 total)