[Barry]

Hi Bastien,

a) The hover box disappear as soon as your mouse quit the blue line, which makes it more of an informational box than a go-to box

Yes, in a sense; it is sometimes possible to keep it open and move your mouse pointer over it, but that isn’t really the intent – it exists really as a box that displays some extra information when you mouse over the event entry itself (and that should also answer your second point/question).

You can see the same thing on our demo site by way of reference.

Does that help?

[Barry]

I’m not honestly sure, Bastien, but I’ll move this thread across to our Facebook Events forum so our expert for that add-on can assist.

[Barry]

Hi Bastien,

The plugin tries to calculate the approximate centre region based on your venue locations – but it may fail under some circumstances. Note also that it stores the result of its calculation for a period of slightly less than 2 hours (by default at least) as it’s a fairly expensive calculation to perform repeatedly, so it can at times lag behind your actual venue data. Similarly, if you are using a caching plugin its possible that what is being served has effectively been frozen in time.

What you are describing though, a location near Cameroon, sounds suspiciously close to a longitude/latitude of 0° 0° (the ‘centre’ of the world) and makes me wonder if your venue’s geolocation data is correct.

I can’t actually view your site right now as it seems to be behind a ‘coming soon’ or maintenance page – but I wonder if you could share an export of your venue data (via WordPress’s regular export tool), perhaps as a private reply? Then I could look and see if there is a problem with the actual data.

Along the same lines, if you see a nag message within the admin environment or on the Events → Settings screen offering to fix geolocation data, do try following through with that.

[Barry]

Hi Kevin, if you look at the following part of that URL query you can see that it’s basically looking for events with the keyword ‘Search’ somewhere in the title or post content:

tribe-bar-search=Search

And indeed the word searching can be found in amongst the copy for the single event that is listed.

This can happen when a type of script called a polyfill removes our placeholder text reading ‘Search’ and replaces it with a new piece of text, saying the same thing but added as the actual field value. Traditionally this is done for cross-browser compatibility reasons and ideally the script will clean up before any submissions are made.

My guess is that your theme or a plugin you are using adds this polyfill script and for some reason it isn’t cleaning up after itself … whether that’s a bug with that particular script or something else is breaking it / causing an error earlier on I can’t really say.

I can’t be absolutely sure that’s what is happening as I do note that when you opened the thread you marked down having tried deactivating all other plugins and switching to a default, unmodified theme – normally I would expect those steps to resolve an issue like this – so with that in mind can I just double check and confirm that you did in fact run through those steps and ask you what the outcome was?

Ideally we’d be able to narrow the problem down to a script enqueued by another plugin or by your theme and take action from there but, of course, if that isn’t the problem we can investigate other angles.

[Barry]

Are you still using 3.2? I wonder if this might actually be related to a known bug that we solved in 3.3, albeit taking a slightly different form. To test this theory out (if you are indeed still on 3.2) can you try adding the following fairly close to the top of your wp-config.php file:

define( 'TRIBE_MODIFY_GLOBAL_TITLE', false );

Does that impact on this at all?

[Barry]

Sorry to hear the problem is back.

Can we return to an earlier point in the troubleshooting process though, and deactivate all other plugins and switch to a default theme (like Twenty Twelve) and try to determine from there if you are facing a conflict?

I’m not sure that we ever categorically determined whether this happens only with your theme or if there is something else impacting / a wider problem.

[Barry]

Just a note first of all that it’s best to share code via Pastebin, Gist or some similar service – right now, unfortunately, the forum doesn’t do a great job of formatting code and indeed can strip elements out (of course we hope to remedy this in the near future) – so we can rarely be sure if we are seeing a complete snippet and it can, additionally, be pretty hard to read.

If what you’ve outlined has worked in the past for you and represents what you are trying to achieve then all I can say is, change the post types/taxonomies appropriately and give it a try! On our side I’m afraid we can’t offer further support for a customization like this and you’d really need to pursue it yourself/in tandem with your developers.

Sorry we can’t offer more – and I’ll now go ahead and close this thread. If there is anything else we can help with please don’t hesitate to create a new thread or threads as needed.

Thanks – and good luck!

[Barry]

We’re certainly not shrugging it off – and would be happy to help at any point if you do update to the latest version. We do already have this on our issue tracker as something in need of attention and I should perhaps have made that clearer earlier in the thread: we do strive to make our plugin behave as a good citizen of the WordPress environment and we have admittedly fallen a little short here.

Once again, feel free to reach out to us at any point, but since it sounds like you are comfortable with using an earlier version of the plugin at least for the time being I will go ahead and close this thread.

Thanks!

[Barry]

Very strange – sorry to hear that the update didn’t resolve this after all.

Thanks also for trying the step of deactivating all other plugins – at this point, since it seems you may be facing a quite different problem – can I ask you to repeat that and at the same time switch to a default, unmodified theme (like Twenty Twelve) and see if the problem persists under those conditions?

[Barry]

I’m tending to think the path of least resistance would be to customize (or build an equivalent of) the widget you are using. Essentially though you could use register_taxonomy_for_object_type() to tell WordPress that regular WP categories should also be used for events.

This may or may not be sufficient in itself, depending on how your widget is performing its queries (if it is strictly querying for posts rather than posts of any type it may not by itself do what you want).

I’m also unsure if you mean that you would want this specific category term to be automatically populated whenever you save an event or if you would be manually assigning. The former is definitely possible but would take a bit more legwork.

Ultimately, I think this pushes the bounds of what we can help with, but exploring the WP codex – starting with the function I referenced above – is probably a good way to start here.

[Barry]

The system info came through – sometimes posts with system info are for some reason treated as spam and need to be manually recovered by a team member, so it may not appear at first to have been posted.

I don’t actually see anything in there to help me replicate this; I’ve tried under a few conditions and can’t recreate locally.

It will be VERY difficult for me to disable our plugins and try a default theme. Is it possible for you to look into this witout me doing that?

I can appreciate that – perhaps as an alternative you could create a test environment (even if that is a new WordPress installation living in a subdirectory) and start with nothing beyond WordPress, a default theme and our own plugins and see if you can replicate there, thus avoiding impact on your live site.

You could then basically build up to the same stack of plugins/themes as on your live site and see if that allows you to reproduce and by process of elimination uncover any conflicts.

Is that possible?

[Barry]

That’s basically the sort of avenue you would need to take – and you would probably be interested in adding a comparison against the corresponding EventStartDate and EventEndDate fields from the postmeta table.

Great that you made a feature request, though – it’s definitely one we’ll look into.

[Barry]

Hi Simone:

If I visit the URL provided when you opened this ticket I see a message telling me I should visit another site. If I follow that link I can find a calendar but it does not look like ours.

Can you confirm where I should go to see this / if indeed you still need help?

Thanks!

[Barry]

Happy to hear they helped!

[Barry]

We can’t really provide generic step-by-step instructions for every single SEO plugin (and indeed for the various SEO features baked into many themes), simply because the extent, naming and purpose of any filters/hooks they provide varies hugely.

With that in mind it is best to work with the author of your particular SEO plugin. On our side, we certainly have a number of functions you might find useful to help detect if a request relates to an event view, for example:

* tribe_is_month()
* tribe_is_list_view()
* tribe_is_event_query()

These could be useful building blocks when paired with filter functions specific to your SEO solution.

Hope that helps!

[Author]

Posts