Forum Replies Created
-
Posts
-
Hmm, ok. When you opened the ticket you noted that you tried switching to a default, unmodified theme and had turned off all other plugins: did the problem still persist under those conditions (including with the above change in place)?
I believe some work may also have been done in relation to comment support with our 3.3 release – so that could be worth checking out if you haven’t already done so.
Hi Matthias,
I’m afraid right now that is not supported (at least not ‘out of the box’). We would indeed need a different structure to support this sort of pattern and we are considering such a change – right now though I’m afraid it’s simply not something we can support.
Hi wihac,
We’re sorry for any confusion. Right now (and for quite some time now) we’ve had a message on the forum homepage as follows:
We generally require 24-48 hours (during the workweek) to hit new threads. The forums are not monitored on weekends. Please be patient when posting and know we’ll get to your issue as quickly as we possibly can.
If you feel that isn’t sufficient we’re definitely open to your feedback – and of course if you found a statement suggesting a different level of service somewhere else on the site we would definitely like to know so we can review and modify or remove it.
Thanks!
Hi wggb,
This sounds suspiciously like a bug we thought we had quashed in this release. To help me replicate though can I ask you:
* To post a copy of your System Information, as found the the Events → Help admin screen
* Confirm if this happens with no other plugins and only a default, unmodified theme such as Twenty Twelve running
* Let me know if this happens wherever the widget is deployed or, for instance, just on the home pageThanks – and sorry for the inconvenience.
Hi Bastein,
Just to avoid confusion, when you refer to the “Events” category is this a distinct taxonomy that you have set up, or is it a regular WordPress category called “Events”, or something else?
Thanks!
OK, if you’re happy sticking with 3.0.3 that’s fine – but do bear in mind we can only offer very limited support for older versions of the plugin.
I also, somehow, misread your initial post – but since this is centred on a custom query of yours I think we could knock out the filter that adds an additional join (within our code) temporarily while your custom query runs, if that’s of interest? It could then be restored to allow normal operation elsewhere.
Hi M,
This is almost certainly a conflict with your theme or another plugin and my guess would be both our code and that of the other component are essentially trying to perform a similar database query operation on the same table.
The only thing that makes me doubt that is that you noted you had tried deactivating all other plugins and switching to a default theme … can you confirm if that did or did not resolve this? Any workaround (not that I can guarantee providing one) would really hinge on knowing with which item them conflict is occurring.
OK, so it sounds like a conflict. If you reactivate everything one-at-a-time, testing at each stage, can you isolate anything in particular (your theme, another plugin) that is responsible for this?
We’re here to help as best we can.
For a problem like this, however, I don’t think we can realistically do a great deal in the short term. We’re certainly not ignoring the issue – we just have to be realistic about the scope of the problem and how quickly we can bring development resources to bear on this.
It’s also worth noting that for the overwhelming majority of our customer base this is not a problem they are hitting up against – and in the process of delivering support we regularly visit many sites using our code every day: many of these use the calendar widget, have a not insignificant number of events in their calendar but are not experiencing anything like 12 second load times.
Clearly it is a real and valid problem for you and I’m not suggesting otherwise – I simply wanted you to understand our perspective on this. Regarding action you can take right now to help with this, have you enabled query caching and have you considered making use of a caching plugin?
Great question: I think that could be the basis of a worthy feature request, if you are game to make one:
Right now I think implementing this is a little beyond what we can help you with – but I’d imagine it’s possible to intercept and modify the query used for searches with some WP know-how and good use of filters.
Hi florianubr,
I’d imagine that’s possible but I’m not sure how many of our users would need such a feature – but you could certainly post a feature request:
Beyond that I’m afraid this is really a customization that you’d need to drive forward by yourself.
I can imagine it would be frustrating to say the least. We’ll certainly address it as quickly as we can, but realistically it will not be before the very next maintenance release – as we need to deliver other fixes as an immediate priority (not to play down the importance of this particular bug, which is valid indeed, but to give you a sense of how quickly a solution may become available).
This holds especially true on the sidebar widget, where in our implementation no event data is being rendered until you click through the cal to the “Day” view.
That’s definitely a valid point: there are further optimizations to be made, for sure.
This isn’t unfortunately something we can turn out over night, though and – to give some background as to our decision making processes here – there are a number of possible changes on the cards that might impact on further work in this regard, including altering the way recurrence data is stored and potentially enrichening the amount of information offered by the calendar widget, which we need to factor into our workflow and scheduling as of course we wouldn’t want to conduct a piece of work to optimize the calendar widget, only for it to be annulled by a separate change.
At this time then the big takeaway would be: we’re aware of performance issues in relation to the number and nature of some queries and are interested in and actively considering changes – but for now working through this with caching both front-end and at query level is probably the best strategy for mitigating any adverse impact.
