[B.]

Hi Brian. Thanks for the reply. You were definitely on to something.

I had checked the Default Content area previously, but went back and tried changing the default State & Country (only 2 fields to have default data) to have nothing selected. They were previously set to CA & USA (figured it would save client a bit of time).

This appears to have done the trick. The ‘Unnamed Venue’ is no longer created if we don’t add anything to the Venue section when creating a new event.

I also checked this on an older Dev site running TEC/ECP 3.11.x. It looks like on previous versions, the default State & Country we had set were ignored for new events so the ‘Unnamed Venue’ issue did not come up. So not sure if something changed for the v.4.x plugins, but we’ll just leave these blank for now.

I’m guessing it wasn’t intended to allow only part of the Default Address (like State & Country) to be pre-populated?!?

Thanks again for the help.

[B.]

Just wanted to note that I see the same exact behavior on standard desktop view for the tooltips. Assuming same markup for tooltips is used for mobile clicks?!? Latest WP/TEC/ECP as of today (1/14/16). Hard to style as-is now.

[B.]

Perfect. Thank you.

I had a knew which file it should be in, but am not fluent in PHP so didn’t know how to code the proper function to strip the link out. Hopefully this might help others trying to lose the venue links.

So now would putting ‘Disallow: /venue/’ in my robots.txt be sufficient to stop those ‘pages’ from getting indexed? Or can they show up in any other URL structure?

Thanks again!

[B.]

Hi Cliff,
Thanks for letting us know about the incorrect directories. We did find a few, mostly in the mobile/media queries section. I may have noticed that in phone/iPad testing, but thought it was something deeper with those OS’s.

And do you know where the jQuery Smoothness styles are used in ECP? I tried disabling that stylesheet and didn’t see any obvious changes, but I’m wondering if it’s somewhere subtle or buried a bit that might not be obvious at first-glance.

Thanks!

[B.]

This reply is private.

[B.]

Hi Cliff,
Thanks for the very helpful reply. I looked at our settings, and yes we are using Skeleton styles (we have to choose 1, figured this would be lightest). But we definitely do not, and never have, used the Mini Calendar widget. We only use the Event List widget.

So I tried your ‘dequeue method’ to remove all of the styles instead of our filter. In ‘Core > Skeleton Styles’ I let it remove the main calendar-style. Then in ‘Pro > Skeleton Styles’, I had it remove the main calendar style as well as the 2 widget-calendar styles. Everything else is commented out.

This seems to get rid of all Tribe Event styles EXCEPT:
– the Datepicker (too long to port over to our master)
– and the JQuery Smoothness styles (what exactly does this one do???)

Then we enqueued our main combined & modified stylesheet to replace them.

Everything appears to look fine at first glance, and we finally got rid of those calendar widget stylesheets. I also hadn’t noticed that before it appeared to have been loading our main modified stylesheet twice, but this is now corrected as well.

Hoping this is a solid solution. I guess if you guys change classes/ids or other attributes, our stylesheet may break. Hopefully you won’t do this often!!!

I’ll post a link in a private reply to a test site that we had created in case you want to check it to make sure nothing obvious seems broken.

Thanks again!

[B.]

Hi, thanks for the reply. I checked another similar site and see the same thing. I am running latest versions of all software.

I’m wondering if something in the way we’re replacing the main stylesheets with our own combined & modified version may be causing this?!? Here’s the function we use to replace the TEC & ECP main stylesheets with our single combined version (compiled from both originals). I checked that file and did not see any @import lines, though, so it shouldn’t be bringing any additional sheets along.

// Replace Events Calendar 3.x CSS with our modified version
function replace_tribe_events_calendar_stylesheet() {
   $styleUrl = get_bloginfo('template_url') . '/tribe-events/tribe-events-full-modified.css';
   return $styleUrl;
}
add_filter('tribe_events_stylesheet_url', 'replace_tribe_events_calendar_stylesheet');

function replace_tribe_events_calendar_pro_stylesheet() {
   $styleUrl = get_bloginfo('template_url') . '/tribe-events/tribe-events-full-modified.css';
   return $styleUrl;
}
add_filter('tribe_events_pro_stylesheet_url', 'replace_tribe_events_calendar_pro_stylesheet');

Is there a filter that could be added to this function to just not load that file (or replace with our main ‘combined’ file)??

Thanks!

[B.]

Ahhh, so close but yet so far…

I’m guessing as it took a few years to get to this point it may be a while before we can successfully integrate. It’s a real bummer, as we have a bunch of sites that we need to update to latest WP/WPML/ECP/etc to be current, and in doing so we will break our ‘temporary’ Bing Translate solution. So the entire site EXCEPT calendar titles & descriptions will show in the alt language…

Thanks for the update.

[B.]

Hi Nico,
Thanks for the update. It’s very unfortunate that you don’t support the ‘Translation Editor’ method. It’s one of the 2 main ways that users can translate with WPML, the other being manually as you have it setup.

We certainly hope that TEC will continue exploring the Translation Editor method, as everything ‘appears’ to work correctly from the WPML interface standpoint when using this method. So not sure how ‘close’ it is to actually working, I suppose you would need to examine the database to see what is actually being stored. Then it may have more to do with the redirects, not sure.

I did switch my test site to the Manual Translation method temporarily as mentioned. Using this method would just require a bit more of a savvy user who could pay close attention to details to make sure everything was done correctly, especially when making updates to a translation. The Translation Editor method just simplifies the process a bit for the end user.

Let us know if the Translation Editor method was tested at all, and explored as an option in integrating when the development was happening. Would be helpful to know if this is/was being explored, as we’ve been waiting many years for a decent integration.

Thanks!

[B.]

Hi Nico,
– Can you go to ‘WPML > Translation Management > Multilingual Content Setup > How to translate posts and pages‘ and let me know if you have it set to ‘Create Translations Manually‘ or ‘Use the Translation Editor‘?

We have always used (and definitely prefer) the ‘Use Translation Editor‘ option. There are a few advantages that make this method easier for our users.

As a test, though, I did try translating an event manually. When clicking the ‘Overwrite with English Content’ button, it did bring in the Title & Description content OK (which the Translation Editor did as well). But it didn’t bring in the proper meta data for the event details. It used today’s date and did not bring in the Venue information. When trying to add the venue information, I get a ‘Venue already exists’ message, as proper titles are not usually translated (in fact, most attributes of a venue would NOT be translated). But there is no drop-down to choose any venues.

It does appear to get the translated event to show, however. It’s just a bit clunky. If any info is changed for the event, the translation has to be updated manually with no default reference in the editor window. So a translator would either need detailed notes from whomever changed the event, or would need to keep a separate screen open with the English event and look for any obvious differences. Not ideal for a lot of users.

I think one of the big differences that I see, though, is that it looks like doing a manual translation does not present a translated slug when you switch languages. So ‘domain.com/event/happy-new-year/’ becomes ‘domain.com/es/event/happy-new-year/’. When using the Translation Editor, it would become ‘domain.com/es/event/feliz-año-nuevo/’. Maybe this can shed some light on why Translation Editor events are not showing up?!? Though showing the Spanish title as slug is standard behavior.

Let me know what you find out here.

Thanks!

[B.]

Hi Nico,
Thanks for the reply. I had already done the steps outlined in the ‘Setting Up..’ article.

But there are discrepancies on the ‘Creating Translations…’ article with what I see in WPML. I do not (and have never) seen the option to Copy/Overwrite from English in the Language pane. I have only the checkboxes to duplicate media items to the translation.

And clicking on the icon (blue +, pencil, etc.) takes me into the Translation Editor where I do the actual translations. In there, I am only presented with the title, description area, and category fields to translate. Those are the only fields that have needed to be translated, though, as it seems like most other field labels have been translated internally by the plugin.

So I’m wondering what method you have setup for translating in Multilingual Content Setup section of WPML? We have only ever used the ‘Translation Editor’ option, as it has many advantages over doing things manually. Do you have it setup to ‘Create Translations Manually’??

Before updating and trying to translate an event, viewing events when in Spanish mode would display with the same URL but just the ‘/es/’ appended before ‘/event/’. The event would display with the Title & Description in English, but most other fields (dates, field titles, etc.) in Spanish, again auto-translated by the plugin. Now, when trying to switch languages on an event page, it tries to use the Spanish title as the slug (producing a 404 error).

Hope this helps narrow down what may be happening. Let me know if you need any additional information. We’ve been using both ECP and WPML on multiple sites for many years now, so fairly familiar with both.

Thanks!

[B.]

It might be nice to see a functioning example of ECP + WPML, and know what workflow was followed. I imagine with the feature being touted so strongly in the upgrade notices, they must have seen it working on at least some sort of test site?!?

[B.]

OK, paste in plain (links are stripped out apparently when using the ‘link’ function):
https://theeventscalendar.com/support/forums/topic/solution-for-wpml-events-calendar-pro-recurring-events-compatibility/

[B.]

Ugh, sorry. Link to reference post was stripped out for some reason and no way to edit post. Hoping it sticks this time…

[B.]

Hi Brian,
OK, thanks again for the help. This seems to have done the trick. I may have even tried something like that, but an extra parenthesis or semicolon here or there does not work so well in PHP 😉 I wish I had time to learn, but there are only so many hours in a day and so many other things to stay on top of.

Hopefully this will hold up for a while. I’ll implement on the other sites we have.

Thanks!

[Author]

Posts