Forum Replies Created
-
Posts
-
Awesome to hear that did the trick. That’s an awesome idea on the “Posted Date” column…hadn’t hear dit before. The way we’re gauging what will go in future releases is largely based on the Feature Request thread we’ve got going here (https://theeventscalendar.com/support/forums/topic/events-calendar-pro-feature-requests/). If you mention this in that thread it’ll be a vote for the feature and will lead to it being discussed internally here as we plot future releases.
Let me know if you need anything else, too. Otherwise have a great weekend.
Thanks for confirming, Jessica. We’ll do everything we can to get this figured out for you guys. Apologies for the inconvenience in the interim.
That’s an awesome looking site, Krzysztof. Thanks for sharing. So cool to see our plugin being used on sites worldwide!
Thanks for confirming, L – that’s a neat feature request and I’ll be interested to hear how the devs would consider implementing it. Thanks for that!
Shawn: for #1, you should be able to change the start date in grid view under your general WordPress settings (Settings -> General). Whatever you set for the broader WP install will apply to the calendar as well.
Your vote for #2 is confirmed heard 🙂 since a few folks have requested this so far I suspect it’ll make it into the codebase sooner rather than later.
Hey Frank. I believe I responded to your email about this already, right? You should be able to change it under Settings -> The Events Calendar by selecting a different template option from the dropdown list that appears. Let me know if that isn’t what you were aiming to do and I can take another look.
Hey Joshua. Thanks for the purchase; happy to help here.
On #1: This was a known issue in an earlier release but should be fixed with the 2.0.3 update. Are you still having problems even after updating both Events Calendar + Events Calendar PRO? Let me know if so and I can get a dev to take a look here.
On #2: I think I understand your issue here, and it’d seem to me like you could control this in either list.php or events.css. If you did a template override (saving a new ‘events’ folder to your theme directory; copying over the file you want to change; and modifying the copied file here) any changes you made wouldn’t be overwritten when the next plugin update releases.
Hope that helps. If you need anything else or have any follow-ups, just let me know.
Hey Steve. Thanks for the feedback. As with any bug, we find it a more productive use of everyone’s time to spend development resources chipping away at the bug in the plugin code itself rather than fixing them individually for users on a one-off basis. That way everyone can get the new code quicker and it’s a smoother experience for everyone. As this particular issue was one that just came to a head since the start of this week, it’s not something we’ve discussed anywhere but the forum (though if you browse past threads you’ll see it has been an active bit of discussion). That being said, I do apologize wholeheartedly for the inconvenience. If you are unhappy with the plugin or it’s functionality, feel free to send me an email (rob at tri.be) and I can get a refund processed for you.
Shawn: Thanks for the words. I think the issue here is that you edited this on a post-by-post basis, rather than going into Events -> Organizers on the admin sidebar and changing it in the saved entry. It’s creating duplicates because the system cannot understand that the change you’re making should be saved to the existing entry (though this will change in a future release). In the interim, changing the saved organizer data – then applying that one organizer to all your events, and deleting the now-unnecessary duplicates – should get you where you want to be without any loss of data. Hope that helps…let me know if I’ve misunderstood the request here and I can adjust my response accordingly.
Thanks for the update, Jason. We reviewed this today with the dev team and are having trouble identifying what could be the cause here…but we’re still on it and actively discussing. Just a heads up so you know we’re working towards a resolution.
Hi Jessica. Weird; this is the first I’ve heard of this issue and you are correct in that it doesn’t seem JetPack, Disqus or GA would be the conflict here. I’ve asked our developer Jonah to chime in on this – so he can comment directly over the next day or so.
One thing I may suggest in the interim would be to play around with different permalink structures and see if that could be an issue. We have heard a few reports of sites having issues when pretty permalinks were not enabled. Any chance that could be at play here?
No prob. Glad to see we’re all set here. If anything else comes up, let me know and I can look into it.
Hey Greg. Thanks for the note. They actually should be doing this by default; you’re experiencing something different on your end? Any chance you’re running a pre-WP 3.2 release?
Excellent to see this is working relatively well for everyone. If anybody else has issues going forward, just let us know.
Hey Scott. Sorry that it took me a little while to get back to you on this. When you say “instead of going through ‘Add New’,” do you mean adding the plugin or adding events on a case by case basis? Either way it shouldn’t have much impact…I’ve been testing that method you noted in my QA (sending the plugin up via FTP, overwriting the old build if prompted) and it worked fine.
Still having any issues on this? Let me know if so and we can keep digging into it for you.
Hey Sam. I talked this over with the dev today and we’ve fixed it. APM wasn’t using WP’s internal plugins_url() function previously out of a desire for the flexibility of embedding it in plugins and/or themes as we tend to do. It’s now using plugins_url() , which itself has a bunch of stuff going on to account for Windows installs. There’s also a filter on the the plugin url called tribe_apm_url for those times where we might need to modify the URL to account for unorthodox usage (ie embedded in a theme).
We’ve updated the external reference for ECP trunk and 2.1 branch to point to APM 1.0.7. The nice part is that you can just install APM through the WP.org plugins directory and it’ll take precedence over the bundled one. Let me know if you have any issues with this.
