[Barry]

Hi Thorsten,

Posting code directly into the forum is indeed problematic – but you can certainly share links to code hosted on Pastebin, Gist or some similar service.

It’s difficult to advise you partly because I can’t find your events page to see what’s happening for myself (any solution is likely to depend on actually seeing the structure of the page and existing theme stylesheet rules).

As your theme is injecting these extra tags inappropriately, would it be possible for you to either reinstate the [raw] [/raw] “shortcodes” (I think you said in your last post that was the theme-provided workaround for this sort of situation) or otherwise reach out to the theme author and ask how this feature can be turned off?

[Barry]

You’d probably need a sprinkling of CSS 🙂

It’s difficult to advise you based on a screenshot alone, however, as your theme’s existing CSS rules (and how specific they are) will affect the solution. Can you link to a live example?

[Barry]

Hi ironandsteel,

You can simply use the existing WordPress API for this, you don’t need to work through our own functions if you need something beyond what they provide. Please see:

* get_post_thumbnail_id()
* get_the_post_thumbnail()
* wp_get_attachment_metadata()

Hope that helps!

[Barry]

Hi beerfests, we can certainly leave this open for a while – if you’d also like us to provide our list of trusted freelancers/independent developers please just let me know.

Thanks!

[Barry]

Hi!

It looks like there may be a conflict with another theme or plugin. Can you try deactivating all other plugins, ensuring The Events Calendar and Events Calendar PRO are up-to-date and then switch to a default, unmodified theme such as Twenty Twelve?

If the problem disappears under those conditions, ie search works as expected, then reactivate everything one component at a time, checking at each stage to see if the problem has returned.

This should help to isolate which if any component is interfering – we can then take things from there.

Thanks!

[Barry]

Can you try this snippet instead?

[Barry]

Hi blueduck: can you confirm if you are referring to week view?

[Barry]

Yes: at a high level, you can use the tribe_events_single_event_meta filter which gives you access to the final chunk of HTML used to display the meta data – which you can then change at will.

Finely grained access to individual components is also possible via the tribe_get_meta filter (callbacks can optionally receive the meta ID to help identify which piece of meta data exactly they are looking at, in addition to the HTML segment) and similarly so for tribe_get_meta_group – which relates to a group of meta fields, such as the “Details” or “Venue” sections.

We also have some information about the meta walker, which puts this all together, over in our tutorials section:

Tribe Meta Walker: An Overview

Last but not least, if you really want to build a custom look and feel you could simply strip out the single-event.php template’s call to tribe_events_single_event_meta() and build things up exactly how you would like them to appear with your own code (which of course can leverage our own template tags).

I hope that gives you a few ideas!

[Barry]

You could try adding a snippet like this one to your theme’s functions.php file?

[Barry]

OK, so today is 10 December: if we want to show all events in list view from 8 December onwards we could form a URL like this:

example.com/events/upcoming/?tribe-bar-date=2013-12-08

Then all events from 8 December onwards will be listed.

So, one approach could be to dynamically generate such a URL and use that as the point-of-entry to your calendar … alternatively you might catch requests to the main events page and redirect them to that same crafted URL.

Do either of those ideas help here?

[Barry]

Sorry, my reply was back-to-front. You want to use .com and that is how WordPress is set up. So, if you clear your license key and re-register it you will basically be good to go (and can simply stop using the .com.au domain).

[Barry]

You can certainly change the domain name for your license key: visit our license keys management page and clear the existing domain, then re-register the key using the WordPress site/domain you want to use.

Remember that right now it seems accessing your .com.au domain merely loads the same page from the .com version of the site – it’s basically an alias – but the actual site URL remains the .com address. If the .com.au domain is what you want to use then you will need to set up WordPress accordingly.

Hope that helps!

[Barry]

On taking a quick look at the iCal feed on your site the actual iCal data itself looks fine to me. Does this happen with all events / can you provide an example of an event where this fails?

I can certainly see entries that contain the city and what looks to be the postal code – and also the event title – so I’m not sure why you are experiencing this.

[Barry]

Sure: I’ll go ahead and close this thread now but you can of course contact us about this again at any point should that be necessary.

Thanks!

[Barry]

I’m very sorry for the delay, first of all. For some reason I haven’t been receiving notifications for this thread in particular, please accept our apologies.

I’m not sure why this problem with our enqueued stylesheets not adopting the correct URL scheme would occur – we’re not enqueuing scripts in a particularly different way to, for example, a default theme like Twenty Twelve.

That said, looking at the sample page you provided I see that the full-calendar-pro-style-css and tribe_events-calendar-pro-style-css are indeed now being served via HTTPS, at least on that page. Have you resolved this / did you find and fix the root cause?

[Author]

Posts