TomboAhi

So I ran into another issue and this one seems to be a genuine bug and not a logic issue. It appears that if an offmonth/offdate is applied to an annual repeating schedule the startdate is offset by 1 day.

For example, today is 9/2 and the following logic should show both items, however only the first item shows.

[time-restrict-repeat type="annually" onmonth="August" offmonth="September" ondate="02" offdate="03"]
August 2 - September 3
[/time-restrict-repeat]

[time-restrict-repeat type="annually" onmonth="September" offmonth="October" ondate="02" offdate="03"]
September 2 - October 3
[/time-restrict-repeat]

If I modify the second item by removing offmonth/offdate it works.
If I modify the second item by changing the ondate to 01 it works.

Is my expection that the following logic to have something different show up for each month on an annual basis correct?

[time-restrict-repeat type="annually" onmonth="January" offmonth="February" ondate="01" offdate="01"]Shows On Jan 1 00:00:00 - Hides on Feb 1 00:00:00[/time-restrict-repeat]

[time-restrict-repeat type="annually" onmonth="February" offmonth="March" ondate="01" offdate="01"]Shows on Feb 1 00:00:00 - Hides on Mar 1 00:00:00[/time-restrict-repeat]

etc...

• This reply was modified 8 years, 2 months ago by TomboAhi.

I believe I figured out my mistake (it was a foolish one) so then my question would be, since I must include ondate/offdate, which of the two would you deem the better practice assuming I want it to show for the entire month and switch over at midnight between the last day of the month and the first day of the month?

[time-restrict-repeat type="annually" onmonth="July" offmonth="August" ondate="01" offdate="01"]
<strong>July</strong> Hey! It is July
[/time-restrict-repeat]

OR

[time-restrict-repeat type="annually" onmonth="July" offmonth="July" ondate="01" offdate="31"]
<strong>July</strong> Hey! It is July
[/time-restrict-repeat]

If this could be modified to leave out the ondate/offdate, we wouldn’t have to worry about leap years ;p

Thanks again.

• This reply was modified 8 years, 2 months ago by TomboAhi.

On a side note if you simply add…

teccc_add_text_color( 'Default', '#4b8308' );

…to your functions.php without doing the check, it will cause errors, not sure if it is expected behavior or not but just figured I’d let you know in case.

I threw that in and the color ‘Red’ does show up. I just modified what I put in my functions.php to:

/** The Events Calendar Category Colors Modifications */

if( class_exists( '\\Fragen\\Category_Colors\\Main' )) {

    teccc_add_text_color( 'Default', '#4b8308' );

}

And it works.

Andy,

Thank you and there is no need to add a feature request. It appears taht the solution to the problem is to simply ‘Hide’ the categories I do not wish to be affected by TECCC.

This is exactly what I was looking for, in case you wish to add it to an FAQ somewhere.

I am going to delete the issue I added to this thread and make a separate post for it.

.

Hi Andy,

Thanks for the response. I did see that link but was just wondering if there was a way to bypass text color all together, even if it was via code edits.

That said, what are the chances of having something like this in a future version?

Thanks

Any update?

Yep, it worked. I just didn’t want to modify the files without ensuring there wasn’t some dependency – site didn’t blow up and errors stopped flooding the logs. Thanks!

This thing is starting to use ridiculous amounts of memory. It used to run under PHP with a 32M limit, then I had to eventually up it to 48, then 64M. Now with 1.9.6 I get errors with 64M and had to up it to 72M.

Considering the history of needing to increase the PHP memory limit to run the plugin without errors, I am not sure there is a whole lot you can do to improve performance.

Its a great plugin with quirks that have been going on for years and increasing memory use for little return in features/functionality. For example what did 1.9.6 give me over 1.9.5 that required more memory? /boggle They don’t do a great job of updating their changelog either.

Yeah I did that and it works, though I am unsure why this theme and plugin only need more than 32M on this server and not the other. Anyway, thanks for your assistance.

`PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 30720 bytes) in /home/xxxx/public_html/wp-content/plugins/all-in-one-event-calendar1/app/helper/class-ai1ec-events-helper.php on line 743

PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 384 bytes) in /home/xxxx/public_html/wp-content/plugins/all-in-one-event-calendar1/app/helper/class-ai1ec-events-helper.php on line 1063

PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 384 bytes) in /home/xxxx/public_html/wp-content/plugins/all-in-one-event-calendar1/app/helper/class-ai1ec-events-helper.php on line 1063′

Here was the original ticket I opened regarding this 6 months ago, before you guys took over the plugin.

https://trac.theseedstudio.com/ticket/335

One other question, can I exclude things from view somehow?

Not sure how this could be marked as resolved without a response.

Event posting could be added – the problem is that with different calendar plugins doing things in different ways it makes it a bit complicated.

I would only support events that are an actual post type. I believe most of the popular event/calendar plugins use that method as it makes the most sense not to mention WP made it easier when they officially introduced post types. Now since they all can use different terminology for their post types, I would make that a setting that the user has to fill in. So using this calendar for example, I the user, would have to fill in the box stating that the post type is ai1ec_event.

Granted I am not a coder but I figure that would be the easiest route to take for your sanity sake