Url rewriting issue + performances issue in month view

Home Forums Calendar Products Events Calendar PRO Url rewriting issue + performances issue in month view

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #56228
    Grégory
    Participant

    Hi.

    I’m here today with two problems (sorry ^^).
    Tested with TwentyTwelve, no other plugin, no other event CPT, no template overwrite.

    Url rewriting issue.
    How to reproduce:
    – activate url rewriting in settings.
    – go back in front-end and type this address in your browser address bar http://example.com/?tribe_events_cat=TERM_SLUG&eventDisplay=month&post_type=tribe_events (of course with a real domain and a real term slug).
    – the address is not rewritten with http://example.com/TAXO_SLUG/TERM_SLUG/

    Performances issue in month view (too many queries).
    How to reproduce:
    – In a month template, paste this at the bottom of file (footer, whatever):
    – Simply display the month view in front-end.
    In my case, I reach about 220 queries for the entire page o_O (about 57 for the “upcoming” view). The problem is quite simple in the end (but not the solution):
    – 1 day = 1 TribeEventsQuery::getEvents().
    – 1 TribeEventsQuery::getEvents() = 5 or 6 queries.
    – do the math for an entire month.
    So far I haven’t found any real solution, it’s out of my reach, only a quick fix which can be useful if you display very few events: http://pastebin.com/ENMnYR8v (I’ve altered 2 methods only, look for the string “//// Changes start here”).

    Cheers.
    Greg

    #56288
    Grégory
    Participant

    Edit : oops, my php code has been kicked ^^
    “- In a month template, paste this at the bottom of file (footer, whatever):” echo get_num_queries().’ queries. ‘;

    #56643
    Casey
    Participant

    Gregory,
    Thanks for reaching out with these issues. It’s my understanding that URL rewriting will only occur with pasted URLs if the URL is using standard WordPress query params. Since we’re using custom query params in that URL, WordPress won’t rewrite it.

    Regarding the performance issue, are you noticing sluggishness with the page loading? Could you give me a link so that I could take a look and get an idea for how many events you have, page load time, etc?

    Just let me know and I’ll see what I can find. Thanks so much!

    #56674
    Grégory
    Participant

    Hi Casey, thank you for your answer.

    OK for the URL rewriting, I’ll take a look myself, there must be a way, they simply are taxonomy term and post type parameters after-all (if we forget the eventDisplay parameter).

    Regarding the excessive amount of queries, I can provide you an url but I think it won’t help much: the site is in its development phase, so not really online (but reachable from outside). It is on my personal server (on my NAS), which is quite slow. So this information won’t be relevant imho. I only can say the month view is a bit slower than the others. So far, I have less than 10 events per month.

    BTW, I found something else yesterday: in an organizer page, the “default view” setting is not applied. For example, even if I’ve set the “month view” as the default view, I land on the list view anyway when I visit an organizer page.
    I don’t know if it’s a bug or done on purpose, but here is my “fix”: http://pastebin.com/1DC2hfYW

    Tell me if you still want an access the site.
    Thank you.

    #56702
    Grégory
    Participant

    Hi again.

    $wp_query in a taxonomy page:
    https://www.dropbox.com/s/79vc9mtdlfey0ua/Screenshot%202013-07-24%2000.25.42.png
    Don’t you think there’s something wrong here?
    /the-event-calendar/lib/tribe-event-query.class.php:
    http://pastebin.com/zsrCxXbg
    Simply get rid of all of it, it’s useless, WP is already doing this itself (and it messes with the url rewriting).
    Or, if I correctly understand the first comment, “eventCat” was the old slug of the taxonomy. In that case:
    http://pastebin.com/tDRQLQKG

    Done, the “WordPress won’t rewrite it” problem is solved. You’re welcome.
    See you.

    #56902
    Casey
    Participant

    Gregory,
    Thanks for the insight regarding the URL rewrites. I’m not sure how widely requested that functionality is, but please suggest this feature on our User Voice page and we can see if others are wanting something similar.

    Regarding the number of queries being performed, I’m going to open up a ticket and pass this information on to our developers for them to investigate further. I’ll keep you posted.

    Thanks!

    #56906
    Grégory
    Participant

    Thank you Casey.
    (even if it’s not a functionality request, but a bugfix)

    Regards.
    Greg

    #56907
    Casey
    Participant

    Yeah, that’s a good point. I’ll have them take a look at that as well. Thanks!

    #57366
    Timothy Wood
    Participant

    Hey Greg,
    Just wanted to let you know that we are looking into the additional queries for month view. Originally it was a big concern for soaking memory with the queries for this view and it looks like there are a few stragglers and ways to optimize additionally. I have a meeting with our other devs to approach this in a unified manner and make sure we have all dependencies being accounted for in any adjustments we make.

    Cheers,
    Tim

    #57381
    Grégory
    Participant

    Hi Tim,

    Thank you, and to all the team for your hard work.

    If I have enough time before the end of my project and if the things are not getting better before that, maybe I’ll take a look to it. For my client needs I had to do a special administration page with the events displayed by month and venue (screenshot: https://www.dropbox.com/s/85i2e10escyhw9g/Screenshot%202013-07-26%2021.44.21.png ). The whole page uses only 27-28 queries to display a month (for the other months I use ajax, way faster, but it works without it). The basic idea is to launch only 1 query to get all events in a month, and use a single loop to print them all (and filling empty cells). Maybe I can use a system quite similar for the front-end month view. Now, if we have lots of events… I don’t know which way is the better. Maybe there’s something to do with the integrated plugin cache system (I didn’t use it, not enough time to learn how it works, and I didn’t feel I needed it in this case).

    Anyway, your dev team is in a better position than I am to know what to do (and I’m not a hight skilled developer either).

    Regards,
    Greg

    #57441
    Grégory
    Participant

    Hi there.

    I just found something interesting.
    – Main events page (example.com/events/month/), month view: 8 events, 83 queries.
    – Category archive (example.com/category/foobar/month/), month view: 5 events, 247 queries.
    – Tag archive: not tested. I probably messed something, I have a 404 ^^ (I don’t use them).
    – Organizer page (example.com/organizer/john-smith/month/), month view (yes, I managed to find a way to have the views on organizers page): 3 events, 78 queries.

    So, there’s something about the category archive here… :s

    Cheers.
    Greg

    #58314
    Rob
    Member

    Hey Gregory. You raise a great point here, and I’m sorry this slipped through the cracks. We have been looking into this since this initial exchange and know that – even though you never got a reply here – we are actively looking into this. If we can do anything else or if you have additional feedback on this point don’t hesitate to let us know at pro /a/ tri.be. Cheers and thanks again for your support.

    #979720
    Support Droid
    Keymaster

    This topic has not been active for quite some time and will now be closed.

    If you still need assistance please simply open a new topic (linking to this one if necessary)
    and one of the team will be only too happy to help.

Viewing 13 posts - 1 through 13 (of 13 total)
  • The topic ‘Url rewriting issue + performances issue in month view’ is closed to new replies.