Forum Replies Created
-
Posts
-
Thanks Matthew, but the post you reference appears to be outdated for 3.6.
There is a function in tribe-templates.class.php called event_date_to_pubDate that changes the pubDate in RSS feeds.
I was able to comment out the function. How can I achieve this without modifying my plugin files?
With more digging, I just found that your CSS is tied to these microformats. So, when I clean up the extraneous and non-functional structured data tags, now I have to go in and alter the CSS that was referencing those classes. I think your CSS should reference the structural tags, not the semantics like this.
Actually, this structured data problem is far wider than just the mini-calendar. Each of your calendar views has problems here. (month, week, day, photo, list, map)
In all of those, you are tagging both “hfeed>hentry” and “vcalendar>vevent” in the opening tags for events, yet for many of them, you aren’t displaying any of the required fields for those items.In many cases on these calendar views, you should be picking one or the other. For example, on the month view, your hcalendar tags for each item are done nicely, then are followed with hfeed>hentry for the same items with none of the required fields displayed.
It looks like I need to filter the tribe_events_event_classes function to remove the hentry and vevent tag for the mini-calendar list. (Thought your plugin should implement this directly, since you are putting out microformat tags with no or insufficient content in the mini calendar.
How would I accomplish this to add the filter only for the mini-calendar widget? Obviously that same function gets called in the regular part of the post, and that does need the hentry/vevent tags.
The mini calendar generates lots of errors in Google webmaster tools (thousands of errors, in the case of our site, since the mini-calendar appears often on our pages).
If you have a site in webmaster tools that has TEC loaded, look at the structured data tab. That will tell you if the hatom/hcalendar tags are being parsed correctly.Looks like you are checking this with Firebug. Do a view source directly in Chrome, Firefox or IE. All three browsers will show the faulty /ical/ URL in the source. I can see pretty clearly that Googlebot is pickup up the same URL as well.
Are you rewriting those URLs in jquery, such that Firebug would pick it up? I suggest you “fetch as googlebot” on one of your pages in webmaster tools to see what googlebot is seeing. Clearly the three browsers are seeing the /ical/ URL.
To be clear, the code did fix my problem as well.
My point about wp-config.php is that plugins should not have to modify that file to function properly. Other plugins don’t modify that file and your plugin didn’t need to modify that file a few weeks ago. Definitely not optimal for maintainability when the plugin starts messing with core files.
I assume that you can load this constant elsewhere, namely in one of the plugin files. That seems to make a lot more sense.
Our host supports turning on and off the object cache. That had no effect on this problem.
Adding TRIBE_MODIFY_GLOBAL_TITLE did seem to work on my site. I do hope that an edit to wp-config.php is not the permanent solution here.
I ended up rolling back to 3.1 as well. It was seriously messing with our Google search results. I didn’t come across the recurring event errors, but that might be because I don’t have and current recurring events setup 🙂
Hopefully tri.be can come up with a fix relatively soon.
Cool. I’m glad that your support folks are receptive and responsive. I do have to say that your development team needs to figure out a better way to QA the product before it releases. I’ve encountered quite a few nasty bugs in 3.0 and 3.1 that should never have seen the light of day if you had a reasonable set of test cases set up.
The post today about your new EDD plugin leads me to believe that Tri.be is more enthusiastic about spending dev time working on something new, rather than perfecting what you are already shipping, which clearly still needs some work.
Sorry to sound critical, but this has been an unusually buggy plugin, escpecially givent it’s cost.
From what I can tell this is the case. All of the recurring events whose initial event date have passed are appearing this way.
Snippet doesn’t work for me. After implementing the snippet, the original URL gets 301’d to the URL for the first event in the series, then it looks like it gets 301’d to that wrong URL a second time.
Related to this issue is that whatever magic you are trying to do to create the recurring event instance leaves the get_permalink function returning the incorrect value. I use Yoast SEO to output opengraph tags, but if you track how that plugin works, it is ultimately using the get_permalink function from WP. Your plugin needs to return the correct permalink for get_permalink() on instances of recurring events.
