Month View – Add text before or after the calendar

[jwhouse]

I have the problem reported elsewhere in which the “next month” and “previous month” links do not work. Until we solve the problem, we would like to place a disclaimer on the page to help visitors understand what they see. I’m new to EC Pro. Is there a quick way to add such a disclaimer?

I tried adding a text widget to a sidebar using Widget Logic to put that only on the three relevant pages. Is there an equivalent to is_page(‘slug’) to test for “I’m on the slug page.”

Or maybe there’s a setting in one of the screens to enable adding “before” or “after” text to the month view of each Event Category.

I’m using two Event Categories: ‘Dinner is Served’ and ‘Events’. There are three relevant pages: http://www.jwhouse.org/calendar/, http://www.jwhouse.org/calendar/category/dinner-is-served/, and http://www.jwhouse.org/calendar/category/event/.

[Barry]

I’m sorry you’re experiencing this issue.

Yes, there is a conditional that might be helpful and that is tribe_is_month() – you might alternatively use the setting we provide in the Events → Settings → Display admin screen which lets you add some content to show above event pages.

To the problem at hand, I visited your site and a common reason for this problem (a lack of body_class support in themes) doesn’t seem to be the problem. Instead, I notice that when I try to page forward a month the tribe date field is populated with “2014-02-06” (Feb 6) and that value takes precedence over the requested month.

I’m not sure why that is, but it would be well worth running through our standard steps and deactivating all other plugins and switching to a default, unmodified theme – then checking if the same problem still takes place. Please note if you are using a caching plugin you should take especial care when troubleshooting to ensure it has been fully deactivated (refer to the plugin vendor’s instructions – basically though, deactivating a caching plugin, if you have one, does not guarantee that all of its effects will instantly stop).

Let us know!

[jwhouse]

tribe_is_month() didn’t help. I think i’ts a timing issue. I’m guessing that Widget Logic is looking to decide whether to include the widget before tribe_is_month() is ready to give an answer.

Events > Settings > Display worked perfectly. I just added the disclaimers to the “before” and “after” boxes. I didn’t try that because I thought those boxes were for adding text to individual events, not for month or list view pages. You might want to change “Add HTML before event content” to “Add HTML before calendar content”. I might not have misunderstood then. 🙂

Regarding the underlying problem of the “next” and “previous” buttons not working… I will do the experiment with deactivating plugins. But changing out Builder to a vanilla theme is painful. Sidebar settings get trashed when you deactivate and then reactivate a Builder child theme. Let’s hope I can find a plugin conflict that is causing the problem. I’ll report back in when I’ve done those experiments.

[jwhouse]

I did the debugging work on our dev site at dev.jwhouse.org. That is running Events Calendar, without the Pro add on. Results: Deactivated all plugins. Problem still there. Changed theme to Twenty Thirteen. Problem was NOT there. So it is some kind of theme conflict. I will cross post these results on the iThemes Builder support forum.

Builder does use the body-class() function properly. You can see a bunch of “tribe-” classes in the page source. Please have a developer take a look and see if they are well-formed for your purposes. Let me know if you would like credentials to the dev site to look at what’s behind the scenes. Example page to look at: http://dev.jwhouse.org/calendar/category/dinner-is-served/

[Barry]

I’m glad you got the notice up 🙂

Yes, troubleshooting on a dev or testing site is by far preferable if you can also replicate the problem there. Just to clarify, yes, I was commenting that the body_class() issue (which commonly causes something similar to what you are experiencing) does not seem to be the problem here – instead it seems to be that something is causing the date field in the Tribe bar to be populated.

I think the best thing at this point would be to see if the team over at iThemes can think of anything, but please do post back here with the results of that (even if there is nothing further they can do).

Thanks!

[jwhouse]

iThemes asked for default-template.php, which drives those pages. It looks like the action is in tribe_get_view(). That might be the next thing they ask for. I’m guessing I should look at the api doc for that. What if they want to see the source?

[jwhouse]

Continuing the conversation… Here’s my latest post to the iThemes forum.

From a recent response from Modern Tribe… What might be causing he date field in the Tribe bar to be populated? By that they mean that if you open the “Find Events” box, you’ll see an “Events in” box. Before clicking on a “next month” link, that is empty. After clicking, it populates with today’s date. Their question below is “How is that being populated?”

—
Yes, troubleshooting on a dev or testing site is by far preferable if you can also replicate the problem there. Just to clarify, yes, I was commenting that the body_class() issue (which commonly causes something similar to what you are experiencing) does not seem to be the problem here – instead it seems to be that something is causing the date field in the Tribe bar to be populated.

I think the best thing at this point would be to see if the team over at iThemes can think of anything, but please do post back here with the results of that (even if there is nothing further they can do).

Thanks!
—

[Barry]

What if they want to see the source?

That’s no problem at all, it would be appreciated though if you could do so discreetly (via a private reply mechanism if they have it or by email – or even just suggest they email us at pro (at) tri (dot) be and we would be more than happy to cooperate).

Thanks!

[jwhouse]

This reply is private.

[Barry]

This reply is private.

[jwhouse]

This reply is private.

[Barry]

I’m really sorry – there are some glitches in the forum software right now that mean some of our replies are unintentionally being marked private and are not visible to the original poster – but let me quote my previous reply:

I’m sorry to hear that – but on our side this is not something we’ve seen many reports of (in fact I’m not sure I’ve seen this exact issue reported at all before now) so it does seem like something that is specific to this one theme. Of course, we’re more than happy to cooperate with iThemes to the best of our ability should that be necessary.

[Barry]

Just updating this thread to ensure I see your replies (you can ignore this post!).

[Barry]

It’s been a while without any update: for that reason, I will close this thread out (and hopefully you found some resolution). If you need further help though, with this or anything else, please don’t hesitate to create a new thread – thanks!

[Author]

Posts