Forum Replies Created
-
Posts
-
Hi, Angela;
It does indeed look like something is going wrong with the certificate. Could you try replacing the line that reads `wp_remote_get($url)` with `wp_remote_get($url, array( ‘sslverify’ => false )` and see if that solves your problem? Let us know, and we’ll know better how to proceed from there. Thanks!
Yes, going either direction should cause the same effect (not 100% sure on this, but darn close to).
Hi, Bob!
I’m the lead dev on The Events Calendar and would love to help you get this figured out. I want to make sure I understand your last post: There is a row (or more) in the wp_cms_term_taxonomy table that has a term_id that doesn’t match any of the term_ids in the wp_cms_terms table? If so, ignore the rest of this post and let me know. Otherwise…:
The way WordPress works, every term/category MUST have a unique slug (regardless of whether it is an events category of a post category). When you create a new Events Category that has the same name/slug as an already existent Post Category, WordPress simply assigns that term to the same already-existing category name, and in the process, the same slug as well. What this means is that both the Event and Post category are tied to the same name and slug indefinitely (notice, you change one’s name/slug, and it will change the other’s—go ahead, try it!). If, however, you create an Event category and assign it the same name BUT a different slug from the Post Category, it will create an entirely new linked name and slug (meaning the two categories will forever NOT be tied together).
I am 95% sure this is a WordPress thing and not an Events Calendar thing (though I will investigate further to confirm). How should WordPress have been designed to handle it? It should allow multiple slugs to share the same name as long as they’re from different taxonomies and it should NEVER link two categories to the same name/slug just because it already exists.
What does it all mean for you? Probably when one of the categories was first created, it either had a different name or a different slug from the other one, and thus they were not tied together and also forced to not share a slug. If you don’t mind them having the exact same name and slug forever, the problem should be able to be fixed by deleting one of them, and then creating a new one with the exact same name and slug as the other, thus making two categories that are linked to the same name and slug (and will forever be so). If you don’t want to delete one, or have a problem with them being linked indefinitely, then there isn’t much else you can do other than assign a different slug to one of them.
Let me know if that all makes sense to you and if it helps you to find a solution to your problem. Good luck!Hi, John!
It looks like the issue may have had something to do with a file that we were initially planning to use for the plugin that we no longer need to use. Our inability to recreate makes it hard to tell if the problem will *actually* be solved in the next release, but I’m about 90% confident that it will solve your problem. Our release should be coming soon, but let us know if you need the fix in the next couple of days and we can communicate via e-mail to try and solve your problem in the short term pre-release.
Thanks! I’m glad you’re enjoying using The Events Calendar and Community Events.Hi, Henry!
My guess is that the problem is, as you say, Google has already indexed the pages and is continuing to do so. My suggestion is to put the following code in your theme’s functions.php file: https://gist.github.com/2763669
It should stop google from indexing the day-views.
Let us know if that works for you, or if you need any other help. I hope you enjoy working with The Events Calendar!Hi, Javier!
After looking at the code at http://j3webworks.com/blog/wordpress-make-posts-expire-or-auto-delete, I noticed that there is probably a way to get it to work for events (not just normal posts). If you see line 42 of that example code (the add_meta_box function), if you change the fourth argument from `post` to `tribe_events`, the meta box should start showing on the events pages (and not normal post pages). While I haven’t tested this out, I believe it should work. Keep us posted, and I hope you’re enjoying working with The Events Calendar!
Hi Jesse!
Currently, there is a way to reach the date view from the URL as a query string:
`/events/?eventDisplay=day&eventDate=10-05-2012`
which would show the date May 10th, 2012.
Sorry for the tardiness in my response! I hope it isn’t too late to be able to help you with your website. Enjoy The Events Calendar!Great, thanks ,Jason.
Try this code, and let me know if it suits your needs. Basically I took Jonah’s code and added a bit that says “if events are being queried (along with other stuff), and we are on one of the above pages, only show events that have been assigned a post category.” It shouldn’t affect your regular events pages (but let me know if it seems to).
https://gist.github.com/2380344I hope that helps; good luck!
Yup, looks like this one slipped through the cracks. Sorry about that, Ken! You should definitely see this fixed in the next go around.
Hi, Jason! My name is Paul, I’m a dev working on The Events Calendar.
Could you show us the code you currently have inserted in your functions.php file (if it is changed from what Jonah originally showed you), and I might be able to help you refine it into exactly what you need.
Thanks!
Unfortunately there is not a good way to hide all but one instance of a recurring event; they all are recognized as separate events. You should at least be able to limit the number of posts returned (so you don’t have a list of hundreds of events, if that is how many recurrences there are) by using the posts_per_page attribute in your query. Not sure if that helps to solve your problem at all. Sorry I couldn’t be of more help! :-\
Hi, Michael.
Is the issue that the recurring events are linking to a single event? Or is the problem that it is showing every instance of recurring events, when you want it only to show one instance?
Hi, Ken. Yeah, it looks as though editing the core of the plugin is your best bet here (it is likely I might have done what you said). I don’t think a fix for this bug will make it into our next update, so you might have to edit by hand if you upgrade, but I can guarantee it will almost definitely make it into the release after that. Sorry I can’t have the fix included sooner!
Hi, Ken.
Option one seemed to be a fix that worked on my end… Hmm, it’s possible that you may have inserted other spurious whitespace around the options (spaces, tabs). You might consider doing a var_dump() and trying to figure out what whitespace is there, because I can almost guarantee that is the issue (e.g. it might be “none \r\n”). Try dumping the variable and seeing if you can tell what might be its current value including whitespace and then try the first option a few ways. Good luck, keep us posted!
– Paul
– Paul
