Forum Replies Created
-
Posts
-
Yes you could do this – our themer’s guide, technical docs and this tutorial on template overrides could be helpful here.
If you are comfortable with HTML and a smattering of PHP you should be good to go … the only possible fly in the ointment, if you are targeting the upcoming events list page only, is that we have a known bug relating to the is_upcoming() function whereby it can return true on pages other than the upcoming events list page (our reference #18136).
Again totally possible but it’s sufficiently detailed work to be something I can’t really offer support for, beyond highlighting a few possible avenues:
- Swapping out the call to TribeCommunityEvents::formCategoryDropdown() contained in the event-form.php template with your own custom logic
- You could “cheat” and use a little Javascript magic to check a default category (and even to hide it, such that all submitted categories are implicitly placed in a “Community” category in addition to any others that might be selected)
- Very likely you could enforce a policy where all community events are taxonomized in a certain way by using an appropriate filter or action to hook the event form submission
There are definitely routes to let you achieve what you want here, however it’s beyond the level of support we can offer to go into any more depth with this.
Hi Chad – we fully appreciate that this is less than ideal and we are working hard to fix it; unfortunately it is looking as if this a larger problem than at first anticipated.
For that reason the fix is unlikely to be available for the next monthly maintenance release and I’m afraid we can’t offer up a timetable for any releases beyond that.
From the sounds of things the temporary workaround I posted on Oct 18 isn’t working for you here? (It doesn’t anyway rectify the underlying problem, but in most cases it should allow you to edit affected events.)
Hi S. I’ve written a plugin that could be useful here – you can read more and download it from my blog. Important things to note:
- It’s brand new, so back-up before you first put it to work
- By default it runs once a day and removes up to 100 events at a time, so in a case like yours it might be a few days before everything is cleaned up
- This is something I cooked up by myself, it is not an officially supported plugin and no one is going to offer up any level of official support for it here
With all that said, it might come close to fitting your needs 🙂
Right – I guess that’s my point: the .po file needs to be compiled into a .mo file otherwise WordPress cannot use your translation.
So probably, even though you have changed the .po file, WordPress is loading the existing .mo file and for that reason you will not see your changes.
There’s a good overview of this stuff on the Codex – I have minimal experience of making translations so that will probably be a more useful guide than any advice I can provide 🙂
So here’s the thing: if you don’t specify a display type (via the eventDisplay argument) then it is treated as if you set displayType to upcoming.
Also, whether you deliberately set the display type to “upcoming” or allow it settle on this by default, the value of start_date is overriden and set to the current date.
Does that give a better understanding of what’s happening here?
Can you clarify what you mean in respect of the Eventbrite Tickets part of the puzzle – do you mean if someone creates a new event (or edits an existing one) and they register it with Eventbrite you want certain Eventbrite-specific fields to be pre-populated?
Right, well I think what Joey was saying was that for any custom queries that you may wish to build WP_Query could be a better choice than get_posts() (which may be used internally by The Events Calendar). Apologies if I misunderstood you there.
Hey Nick,
I’m afraid I can’t really comment on why get_posts() might have been preferred to directly instantiating and working with a WP_Query object in the code you looked at, though personally speaking I wouldn’t really see it as a massive inefficiency: it’s a small and compact function after all and takes care of setting a few default parameters, so one might even say it adds to the readability of the code.
In fact, it’s also totally possible to inspect the value of the max_num_pages property – get_posts() itself uses WP_Query so you could grab a reference to that object and look at its properties after the query has run if needed – thankfully WordPress is pretty flexible that way 🙂
Regarding meta queries – if you are writing some custom code using WP_Query then you would follow the guidelines documented for this in the codex – there are certainly snippets lying around the forums and in our docs and tutorials though.
What is it that you want to do?
Assuming it makes the next monthly maintenance release then, well, it shouldn’t be more than one month away – however I can’t give any absolute guarantees here, unfortunately.
@angel – thanks for breaking your question out into a separate thread, that will make it easier to manage as otherwise the scope of your combined questions is pretty huge.
We admittedly don’t have much in-depth documentation on this stuff, but often this level of customization is the preserve of experienced devs who might find it superfluous in any case. That said, I’ll make a note of your interest in more documentation covering this particular arena and if possible and we feel there is enough demand to warrant it then I guess we may look at putting it in place 🙂
Most if not all of what you want is possible – again I can’t realistically cover it all here, but let’s take a straightforward example to show how this kind of thing might be tackled.
Thinking about deleting the description field (both of you mentioned the need to delete a field) perhaps we could look at that as an example of how you might go about this kind of customization. It’s particularly interesting since it is a required field.
The first thing I would do is look in the Community Events documentation which links to a new user primer – this contains information on Community Events related template overrides.
Armed with this information we see that it is possible to override event-form.php. Looking inside this file, around lines 43-48 we can see the code that generates the description field. Let’s go ahead and remove it.
Now this is where some knowledge of WordPress and its API comes in (in other words, some of what I’m covering here is not specific to The Events Calendar or Community Events): when a post is inserted programmatically it normally must contain some content (the description) or else an error is thrown.
Happily this can be overridden and the error suppressed, simply by the appropriate use of filters and hooks and some timely manipulation of posted form data. Here’s just such an example of some code that you might place in your theme’s functions.php file to achieve this:
In summary, pretty much everything you want to do is a real possibility but at least for the time being you will need a good knowledge of PHP and WordPress plus the time to spend researching how The Events Calendar and Community Events work. Once again I will make a note of your interest in further learning resources here.
You may also be interested in the concepts presented in this tutorial:
http://creativeslice.com/tutorials/gravity-forms-events-calendar-submissions/
That relates specifically to integration with Gravity Forms (and may be a tad out of date), but at a high level there are some conceptual nuggets of gold in there that might be of value to you.
At this point, we’re looking at incorporating some changes in the next maintenance release that ought to help you out here.
Hi Jason: the only shortcode I am aware of (available with Events Calendar PRO) is tribe-related-posts which may not be what you are looking for, unfortunately.
