Forum Replies Created
-
Posts
-
Just wanted to note that I can reproduce this as well with 3.0+ activated. The problem is not specific to PRO as I can duplicate with just the free events calendar activated.
I did a bit of digging around and back tracing. The problem’s coming from the fact that the plugin is being too aggressive in overwriting the query. The initial issue comes from the fact that during the query executed from the wp_link_query() function, The Event Calendar’s setDisplay() method from the-events-calendar-class.php returns “month” instead of false or something else. From there a whole series of things trickle down because the query is being treated as an events query and stuff that shouldn’t gets overwritten.
I wrote a small plugin that works around this issue – https://gist.github.com/jkudish/0d71bd3a0f7748a3f912. This is a huge hack, so run it at your own risk, and no guarantees from me that it’ll work. It’s up to Tribe to fix the issue properly.
Not a trivial fix either since I’m sure a lot of how the queries revolves around this.
Hi Kyle,
One thing I noticed, is that when the page first loads, all the fields are visible and then they get hidden. I suspect you might have some javascript that for some reason is hiding those fields. Since you’ve already disabled all the other plugins to rule out a conflict there, I think it may be a conflict with your theme. Worth trying it out with Twenty Ten or Eleven just to rule that as the cause or not, then you’ll be one step closer to diagnosing the issue.
Also, just want to note that it’s definitely not a database related issue relating to previous plugins.
Cheers
JoeyGlad that fixed the issue for you Beth. Just want to chime in here, that we’ve filed this is a bug that we’ll fix in an upcoming release of Community Events.
Hey John,
Can you explain a little better what is exactly that you’re trying to do, and more importantly, if you can share the code for what you’ve done thus far, that would allow me to see how we can be of further help. I did play around with a few of our template tags just now and had them in a custom page template and it was working mostly right as far as I could tell…
Cheers
JoeyHi Demitri,
Throw this into a small plugin or into your functions.php file: https://gist.github.com/2269019 and make sure to replace the “not-in-this-category” on line 19 with the category slug you want to exclude.Cheers
Thanks a lot for doing that extra work and finding a solution, Andy, much appreciated by us and the community!
We’re going to give this a review and if everything’s okay we’ll put the fix in 2.0.5 which is scheduled for release pretty soon.
Andy, is there a particular name you’d like us to use when we credit you in the changelog/contributor list? Otherwise I will just use your username “afragen”. Let us know!
By the way, using the event’s occurrence timestamp, is probably a pretty good unique ID to use 🙂
Thanks again
JoeyGood catch Jonah.
FWIW, I’ve also fixed the original gist at https://gist.github.com/1964698
Hi James,
Two different un-related issues here:
— There’s an error in our tribe_create_venue() and tribe_update_venue() functions, they should call TribeEventsAPI::createVenue() and TribeEventsAPI::updateVenue() respectively instead of TribeEventsAPI::createEvent() and TribeEventsAPI::updateEvent() – I am going to patch that for 2.0.5 which is our next release. Feel free to patch your own installation in the mean time.
— Your ID, ParentID, Campus and Type arguments are invalid and could cause a conflict when passed to the function (chiefly ID which is a valid argument for the wp_insert_post function but only used for updates). You yourself linked to the list of valid arguments, so please base your arguments on that list. I am assuming that those 4 extra arguments are custom fields/metadata you are trying to add to the venue? If so, you will need to use update_post_meta() [http://codex.wordpress.org/Function_Reference/update_post_meta] to save that data, something like this: https://gist.github.com/2009346
Hi Jen,
Thanks for sharing that. After reviewing the issue on your site, I tried to recreate it locally and sure enough it did the same thing for me. I’ve identified this is a bug on our end and will need to investigate it further in order to find the right solution and implement it. Once I do, it will become part of the next release. If possible and simple enough, we’lll update this thread with the solution but no guarantees on that end though.
Cheers
JoeyHey Corey,
My best suggestion for you is to take a look at a page you want to duplicate (e.g. one of your regular pages), open up firebug or chrome developer tools (anything that can inspect the markup/elements) and take a look at what markup/divs exist there and then port those over to the event pages using either of the two techniques I’ve mentioned thus far.
Unfortunately since this is considered customization of the plugin, there’s only so much support we can offer up. We’ve given you the tools, but can’t do the work for you 🙂
That being said, let us know if we can help out in any other way or point you in the right direction. Alternatively, you may look at hiring someone to help you out [if you’re interested email [email protected] and we can refer some names your way]
Best of luck,
JoeyHi Corey,
As promised, I took a look at the site. This type of problem unfortunately happens when a theme is poorly coded or makes assumption about what should appear on a certain page. In this case, the theme you are using is basically overriding the queries and templating functions of our plugin. Unfortunately, there is little we can do to prevent that, but that’s why we have the “Default Events Template” that Rob suggested. As witnessed, switching to it does make our calendar and other view work properly.
As you pointed out though, the calendar now spans full-width instead of remaining within the “box”. That’s because the theme is relaying on some divs in the markup to make the layout work.
In the plugin settings there’s 2 fields for inserting markup before/after the calendar, so I put in and respectively there (with the credentials you gave us). I basically used the full-width template to look-up/view source and determine which divs were necessary for the layout to work. There’s a few other divs you may want to insert in there if you want the white box around the calendar, but you got you headed in the right direction.
Another alternative if you need further customization or if you want to modify the plugin’s markup directly, you can use template overrides, see: https://theeventscalendar.com/?qa_faqs=what-are-template-overrides-and-how-do-i-do-them
Unfortunately, there’s only so much we can do to help our users with theme integration (especially when the theme doesn’t follow proper standards), but we do have the tools necessary to make it work (such as the before/after markup fields and the template overrides)
Hope this helps
JoeyHi Jen,
Your comment makes perfect sense actually, and it didn’t make much sense for us to strip shortcodes there anyway. I’ve just committed the removal of strip_shortcodes() in the truncate function to our development codebase, so do expect that in a future release.
Cheers
Hi all,
I was able to duplicate this issue locally by:
a. setting up a recurring event on the 31st of every month
b. setting a default timezone in my theme’s functions.php file with date_default_timezone_set(‘America/Montreal’); [the problem appeared with any timezone that I put in there]While I was able to identify this is a bug, I wasn’t able to find an immediate solution for it. So I’ve now logged it in our system to be reviewed for the next release (or possibly the one after the next). In the mean time, the easy fix would be to search your other plugins and themes and remove the date_default_timezone_set() function wherever it’s being called. WordPress handles timezones internally so other plugins or themes don’t have a compelling reason to change it. That being said, it’s still a bug so we’ll have to fix it.
Cheers
Hi Joe,
Correct me if I am wrong, but could you not do the following:
— Install 1.3.3 on the new site (and disable 2.0.x temporarily)
— Migrate your old database to the new site
— Deactivate 1.3.3 and reactivate 2.0.x
— It should prompt you to upgrade your eventsDid you try that? Did it not work?
Let us know!
