[Barry]

Hi Muriel,

No worries – we’re here to help.

You can manually create new users via WordPress’s user admin screens. You can also, if you like, allow users to register for new accounts without manual intervention.

and is there the possibility that the new event not published automatically?

There is indeed 🙂

If you visit the Events → Settings → Community admin screen you can modify the default status for submitted events.

I hope that helps!

[Barry]

I see, well that definitely shouldn’t happen!

Do you also have Events Calendar PRO activated when you try this? Have you attempted to run it with only the cleanup plugin, The Events Calendar, Events Calendar PRO and a default theme in place?

As I don’t see the same issue locally I’m inclined to think a conflict may be getting in the way of things – and really there are no other tools we can offer you to help with the cleanup process.

[Barry]

Just to clarify, do you mean the plugin does nothing at all/you get an error when you try to activate? Or that when you hit the Merge Duplicate Recurring Events button the page instantly reloads without accomplishing anything?

[Barry]

Hi Sylwia,

Does this only impact ticket products – or are you finding that there are problems with all your products, even where they aren’t related to events/ticketing?

Can you point me toward a live example to better help me visualize the issue?

Thanks!

[Barry]

Hi!

I note you already tried deactivating all other plugins and reverting to a default theme, but I see you are using a caching plugin and sometimes extra work is required to eliminate the effects of caching even after you have deactivated the plugin in question.

Right now for instance if I visit the champagne event you referred to I see this in the source:

This Quick Cache file will auto-expire (and be rebuilt) on: Feb 9th, 2015 @ 3:21 pm UTC

So it is effectively “frozen in time” – which of course is essentially the aim of caching. All that to say, are you positive you aren’t simply hitting up against page caching here (does clearing the cache resolve this)?

[Barry]

Hi Dave,

We don’t actually provide technical support here in pre-sales.

If you do have a license, please login and post in our PRO forum – one of the team will be only too happy to help. On the other hand, if you don’t have a license and are using only our core plugin you can still seek support over here.

Thanks!

[Barry]

Hi vonpipper,

I’m sorry you’re experiencing difficulties.

While I’m not sure which version you updated from, I suspect the problem may be the one detailed here:

theeventscalendar.com/release-events-calendar-pro-3-5-2-hotfix

Can you read through that blog post and try out the duplicate cleanup plugin it links to? Note that if there are a very large number of duplicates it may need to be run multiple times.

I hope that helps!

[Barry]

Hi rebatch,

I’m sorry you’re hitting up against difficulties.

As a sidenote, feel free to upload screenshots to your own WordPress site (or to a service like Dropbox/Droplr, etc) and simply paste the link or links in here 🙂

I do see the problem when I look at your site – yet I can’t replicate locally. I do note, oddly enough, that you have some recurring events and one – “Office closed” seems to be being counted as if it were taking place the previous day (hence boosting those counts from 3 to 4).

Indeed if I hover over that event, it very strangely suggests it runs from Feb 23 to Feb 22 which of course shouldn’t happen.

What I’m wondering is, why would this happen? I wonder if you are in a position to run through our standard troubleshooting steps in case this is the result of a conflict.

If that doesn’t initially reveal a conflict, please repeat and prior to reactivating any other plugins (or your theme) delete the recurring event in question and recreate them – all without anything else running which might impact on the event creation process – and see if the problem is resolved then.

It would also be great if you could provide your system information, as found in the Events > Help screen. Thanks!

[Barry]

Hi – sorry to hear you are hitting up against difficulties.

So to summarize, where are you embedding these shortcodes and in which view are you finding they do not work – can you point me to a live example?

Are you finding it’s only these particular Pure Theme shortcodes that fail, or are you also hitting problems with others such as the standard [gallery] shortcode that ships with WordPress?

Thanks!

[Barry]

Hi Massound – anything is possible!

This is certainly customization territory – but the following docs will point you in the right direction (it really boils down to working with roles and capabilities in WordPress):

• http://codex.wordpress.org/Roles_and_Capabilities
• http://codex.wordpress.org/Function_Reference/register_post_type#Arguments (note the section on capabilities, note also you can modify these even after The Events Calendar has already registered the post type)

I hope that helps 🙂

[Barry]

OK – so best I can tell all of those views are using the default events template.

The important thing to note is that the default events template doesn’t stand alone – it assumes that your theme follows convention and includes a header and footer template (which are pulled in from your theme).

With that in mind, I think the discrepancy in what you are seeing is due to something in your theme’s header.php template which isn’t something we can control directly.

My recommendation here – if you wish to remove elements from the header in photo view is to edit that template (possibly by creating a child theme, but that’s up to you) and wrap it in a conditional statement, something like this:

<?php if ( ! tribe_is_photo() ): ?>
    <!-- your theme's code used to generate the title/breadcrumbs -->
<?php endif ?>

That will stop those elements from being generated whenever the view is photo view: the reason we’re not explicitly testing for month/list view is that we know there is no such problem there.

Does that help at all?

[Barry]

Hi Saha,

There are a couple of things that come to mind – I’m not completely sure which might be the best fit for your scenario – or if possibly both might apply.

The first is simply if you edit an individual order and set it to “complete”. If the order contains a large number of tickets then the process will take longer simply because all those tickets – which are stored as custom posts in the database – need to be generated.

The second is that when an order is completed the ticket email is also dispatched. In the above scenario that shouldn’t add too much time on by itself, because we’re only talking about a single email, but if you bulk complete a lot of different orders then the time it takes to dispatch the email is going to be multiplied by the number of orders and of course the generation of ticket objects in the database still needs to take place.

So, the problem could amount to a timeout triggered by the volume of tickets and/or emails that are being dispatched.

There are a few ways we could help to mitigate this kind of problem – particularly where a number of tickets fail to generate – but it would take some re-engineering to do so. I’ll certainly log this for further consideration, though.

I wonder: might autocompleting orders help to alleviate things (I appreciate that may not be viable, depending on your payment model etc but it could be worth considering)?

That way, the need to do bulk status changes would be removed and it may help with at least a proportion of your sales.

[Barry]

Hi Marc,

Rather than change things at server level would it work for you to change your WordPress timezone setting (via Settings → General)?

[Barry]

Hi Paul,

Sorry to hear you are experiencing difficulties.

Can you provide a little more detail? When I visit /events/ (at the URL you provided when you opened this topic) the page seems fine and I’m not sure I’m picking up on any differences following a refresh.

If there is still a problem can I also ask that you run through our standard troubleshooting steps in the first instance in case there is a conflict at work?

Thanks!

[Barry]

Hi Austen,

If things are working as they should you should not see any expired events on the first page of a list-type view.

It’s important to note, though, that until an event has ended it is still regarded as current (ie, if it is 9am and you have an event that started yesterday but doesn’t finish until 10am today – it is current up until 10am).

Is that what you are experiencing? If not, can you point me to a live example of what you are facing?

[Author]

Posts