Forum Replies Created

Viewing 10 replies - 1 through 10 (of 10 total)
  • Thread Starter g4ry

    (@g4ry)

    Yup… Seems to have been the right fix! 🙂

    Alice have you tried using Google Chrome to inspect and troubleshoot your CSSes? Chrome is a great browser for nailing down CSS issues like those you’re describing. With your page in Chrome, right-click over the element you want to inspect and select “Inspect element”, and you’ll get all sorts of useful tools.

    I agree with sonOfhobs… Since it’s recorded as a varchar I can type in “FREE!” as the cost and it’s saved–even with the exclamation point. Must be something outside this plugin, like Eventbrite as mentioned.

    It sorta does have this capability already, but only in the Single event view. The default List view template still shows ending times. I got it to work the way you’re describing by creating a custom template for the List view with a few extra lines of code taken from the Single view.

    First, follow the plugin’s instructions for creating custom templates. Essentially, you do the following:

    1) Create a subfolder called “events” in your theme’s main folder.
    2) Copy the file “/wp-content/plugins/the-events-calendar/views/list.php” into this subfolder. Leave the original file alone, this copy in your theme’s folder is the one you want to modify.

    Next, open the new list.php and look for the code that displays the end date (lines 39-42):

    <tr>
    	<td class="tec-event-meta-desc"><?php _e('End:', $spEvents->pluginDomain) ?></td>
    	<td class="tec-event-meta-value"><?php echo the_event_end_date(); ?></td>
    </tr>

    Replace it with this:

    <?php if (the_event_start_date() !== the_event_end_date() ) : ?>
    	<tr>
    		 <td class="tec-event-meta-desc"><?php _e('End:', $spEvents->pluginDomain) ?></td>
    		 <td class="tec-event-meta-value"><?php echo the_event_end_date(); ?></td>
    	</tr>
    <?php endif; ?>

    With this change, just like in the Single event view, any event that has an End date/time that’s the same as the Start date/time will not have the event’s end time displayed in the List view.

    Thread Starter g4ry

    (@g4ry)

    Okay, I’ve got new code I’m happy with:

    // sanity check that start date < end date
    $startTimestamp = strtotime( $_POST['EventStartDate'] );
    $endTimestamp 	= strtotime( $_POST['EventEndDate'] );
    if ( $startTimestamp > $endTimestamp ) {
    	$_POST['EventEndDate'] = substr_replace( $_POST['EventStartDate'], substr( $_POST['EventEndDate'], -8 ), -8 );
    	$endTimestamp 	= strtotime( $_POST['EventEndDate'] );
    	if ( $startTimestamp > $endTimestamp ) {
    		$_POST['EventEndDate'] = $_POST['EventStartDate'];
    	}
    }

    This is slightly cleaner than the previous because properly set start and end times only get tested once, rather than twice. Incorrectly set start and end times get first tested if dates only need to be fixed, then it gets tested again to see if the time-of-day needs to be fixed too.

    I tested it with these pairs of start and end date/times:

    All day event:
    2011-08-08 18:00:00 (start)
    2011-05-08 18:00:00 (end)

    2011-08-08 18:00:00 (start)
    2011-05-08 13:00:00 (end)

    2011-08-08 18:00:00 (start)
    2011-05-08 21:00:00 (end)

    All entries resulted in valid entries where “start time < end time” on the first try without any revisions, and all-day events properly started at 00:00:00 and ended at 23:59:00.

    Thread Starter g4ry

    (@g4ry)

    After thinking about it, there is still potential for problems with this fix. For example, if the event is not an all-day event and the original start and end times were this:

    2011-05-10 10:00:00 (start)
    2011-01-01 08:00:00 (end)

    the modified code will fix it to this, which is still invalid:

    2011-05-10 10:00:00 (start)
    2011-05-01 08:00:00 (end)

    The end time is still before the start time. So after fixing the YYYY-MM-DD portion, the revised time needs to be checked again to see the end time is after the start time. Repeating the original test after the modified test should be a good final fix for that.

    // sanity check that start date < end date
    $startTimestamp = strtotime( $_POST['EventStartDate'] );
    $endTimestamp 	= strtotime( $_POST['EventEndDate'] );
    if ( $startTimestamp > $endTimestamp ) {
    	$_POST['EventEndDate'] = substr_replace( $_POST['EventStartDate'], substr( $_POST['EventEndDate'], -8 ), -8 );
    }
    $endTimestamp 	= strtotime( $_POST['EventEndDate'] );
    if ( $startTimestamp > $endTimestamp ) {
    	$_POST['EventEndDate'] = $_POST['EventStartDate'];
    }

    I haven’t tested this code yet, but will report back later on what I find.

    Thread Starter g4ry

    (@g4ry)

    Okay, I think I’ve figured out why this bug occurs only for brand-new, unrevised posts.

    Being as lazy as I am, for all-day events I just set the “Start Date / Time:” drop-down selection to the date of my event and let the program validate the “End Date / Time:” for me.

    This bug seems to occur because the function “addEventMeta( $postId )” sets the “EventEndDate” for all-day events first, then it validates that “start date < end date” second. So in other words, it sets the 23:59:00 time for all-day events first, but then this gets re-written back to 00:00:00 when it later validates that the event end date should be later than the start date.

    Current code, lines 856-861 in the-events-calendar-class.php:

    // sanity check that start date < end date
    $startTimestamp = strtotime( $_POST['EventStartDate'] );
    $endTimestamp 	= strtotime( $_POST['EventEndDate'] );
    if ( $startTimestamp > $endTimestamp ) {
    	$_POST['EventEndDate'] = $_POST['EventStartDate'];
    }

    Line 860 should be changed to this so it preserves the time at 23:59:00 or whatever it was before, and the validation only changes the YYYY-MM-DD portion of the event’s end date:

    $_POST['EventEndDate'] = substr_replace( $_POST['EventStartDate'], substr( $_POST['EventEndDate'], -8 ), -8 );

    I think this should fix it. I’ve been looking directly at the MySQL “wp_postmeta” table to first detect the bug and see if the above fix works and all seems okay now.

    vectyr, it says on the wp_nav_menu reference page that the function will fallback to an old menu if the ‘theme_location’ parameter is not set and the function has problems with the ‘menu’ parameter:
    http://codex.wordpress.org/Function_Reference/wp_nav_menu

    So depending on how your theme is written, adding the ‘theme_location’ parameter might fix the problem. This should be the correct code–see the reference page for more info:
    <?php wp_nav_menu( array('menu' => 'main-menu','menu_class' => 'main-menu', 'theme_location' => 'primary' ) ); ?>

    Also, is ‘main-menu’ the correct slug name for your menu? Maybe try passing the menu’s ID number instead since that’s what the function first looks for. Or try passing the menu’s regular name (I assume it’s “Main Menu”), since that is a third way the function tries to get the correct menu.
    <?php wp_nav_menu( array('menu' => 'Main Menu','menu_class' => 'main-menu', 'theme_location' => 'primary' ) ); ?>

    I don’t know if it’s documented in the FAQs, but this behavior is documented in the code. It limits the amount of events shown on a calendar date based on the value set by:
    Dashboard > Settings > Reading > “Blog pages show at most” XX “posts”

    Increase this number to get more events shown on a date. Of course, increasing this number is going to increase the number of posts shown in other areas of your blog (such as those shown in the “News” category), but that’s just the way the developers decided to write the code.

    Also, if a date has more events than what is shown on a calendar date, the date number turns into a link. Hovering your mouse over the date will show all the events on that date. Depending on your theme, the date should be a different color than the other dates too; if not, then you can set it to do so through your style sheets.

    Thread Starter g4ry

    (@g4ry)

    Here’s the pastebin link: http://pastebin.com/VCdzaT1y

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