OAuth Redirect to blog archives, not wp-admin (NOT FIXED)

Home Forums Ticket Products Eventbrite Tickets OAuth Redirect to blog archives, not wp-admin (NOT FIXED)

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #965729
    Jeremy
    Participant

    Hey. Kinda crap that you guys have a problem and you close the topic about the problem.

    I just updated the plugin on my production site and lost my eventbrite integration. Yesterday I sold over $4000 in tickets. We are in our high-sales period. And what happened with the update? Stuff broke.

    When I “authorize” eventbrite, it goes to an archive, NOT, back to WP-Admin. Yes, I changed to the 2015 theme to make sure it wasn’t a theme issue. Yes, I flushed permalinks. Please, I need help. I’m losing money right now.

    #965737
    Jeremy
    Participant

    So you know:

    I have four plugins on my site, three of them are yours. I turned off the other one. No fix.

    I switched to 2015. No fix.

    I cleared my cache. No Fix.

    I flushed rewrites. No Fix.

    I’m an experienced WP developer. I know how this stuff works. I don’t know why you’d make such a major change to a plugin in a point update without any warning. With all the WP security issues we’ve had this month everyone is hyper-focused on keeping updated. This is a major change to handling of API authorization and this is obviously not well tested.

    #965741
    Jeremy
    Participant

    So if I go to:

    http://camps.bonanzaed.com/tribe-oauth/eventbrite/?code=

    It redirects to home.

    If I go to that URL with the code in it, it gets a “content not found” error:

    http://camps.bonanzaed.com/tribe-oauth/eventbrite/?code=X

    Likley, the regex that reads the querystring isn’t working.

    #965890
    Geoff
    Member

    Hi Jeremy,

    Let me start by saying sorry that the other thread was closed. We do close threads that have been marked Resolved or that have been inactive for more than two weeks as a means of keeping the forums organized and it appears that thread hit the threshold there–my apologies! We certainly didn’t intend to shut you out or blow you off and I’m sorry if it came across that way.

    Thanks for detailing the steps you’ve taken so far. It’s definitely helpful to know that you’ve taken the preliminary steps of testing for conflicts and flushing permalinks. Those are definitely the first two steps I would have recommend trying before we got any deeper.

    I haven’t been able to replicate the issue on my end, but I do see in the related thread that the issue was able to be resolved by validating the plugin locally, then pushing the local database to the server. I’m going to create a ticket in our system for our developers to look into this more thoroughly, but I hope that the the solution in other thread will work for the time being.

    Thanks for your patience here while we figure this out!

    Geoff

     

    #965905
    Jeremy
    Participant

    I am unable to bring my site to a local environment. I saw that was a suggested solution but that is not a viable solution for all of us.

    What I could do is manipulate the database with the returned authorization code if it is stored in a settings hash, but I don’t know how it looks. All I know is I’m loosing hundreds of dollars per hour right now and I need a solution ASAP.

    I’ve followed all the to-do’s you guys suggest. But I need help now.

    Can you please arrange to send me a working, older, version of the plugin?

    #965907
    Jeremy
    Participant

    And why do you need to replicate the issue on your end when I’ve provided a link to my site and proved the issue is live? What do you need from me to help you mimick a failing environment?

    #965917
    Geoff
    Member

    Hi Jeremy,

    Thanks for following up. I definitely hear you and recognize the urgency here. You’re in the middle of a high sales period and we want to make sure you’re back up and running as well.

    Since this is the second report we’ve seen on this issue, we’re definitely taking it seriously and are actively looking into it. Having you jump on this quickly and start the troubleshooting process in advance helped a ton and has allowed us to expedite the process for finding a way to fix this.

    The reason it’s important for us to try to recreate the issue on our end is that it allows us to see if the issue still exists in a completely stripped down environment. We do put the plugins through heavy testing prior to releasing them, so if we aren’t able to mimic the issue on our end, we certainly want to start looking at what the discrepancies are between environments. It’s not to suggest that you’re doing anything wrong or that the issue doesn’t exist — it’s a helpful process of elimination that can pinpoint the best starting place to shipping a fix.

    I’ve been looking at this issue with a couple of our developers. While we don’t see anything right off the bat in the code that would create this scenario and we haven’t been able to replicate the issue when testing in multiple environments, we want to make sure we cover all our bases here. Would it be possible for you to outline the specific steps you’re following to authorize the plugin once it has been installed and activated? We’re wondering if the steps you’re taking here differ from our in any way, so please give us as much detail as you can.

    I totally understand you are looking for a solution now and we’re going to do our best to do right by you here and address this as quickly as possible. In the meantime, you are welcome to try downgrading Eventbrite Tickets to a version that predates the API update (3.9.1 and below) by heading to your account here on this site and downloading that version under My Account > Downloads. I do want to note that this could have issues of its own since the API in that version is no longer supported by Eventbrite. If you do go this route, please downgrade your versions of The Events Calendar and The Events Calendar PRO as well to make sure they are all in sync.

    Thanks again for you patience and cooperation here while we work on this.  Getting this nailed down with you is a priority and I want to make sure we do right by you here.

    Cheers,
    Geoff

    #965924
    Jeremy
    Participant

    Believe it or not, I got it working.

    First off, a few things:

    I’m shocked that a point-release featured such a major change. I know that Eventbrite pushed their API update when they did, and I know, as a long-time user of this plugin that I know that the old API creditialing was a pain, but us developers know to watch major releases for major changes. A warning to license holders would’ve been nice. I would’ve held off an update until my major sales period was over.

    Other things were changed too. For instance, the tickets iframe positioning function. These are the kind of changes that should have warnings associated. There are developers that build sites that rely on things staying the same by their plugin dev. Part of my chaos today, once I finally got EB authorized, was finding where the heck my tickets went! Last year, when I built this site, I moved them to the top using your knowledgebase articles. So, I thought stuff was still broken until I accidentally scrolled down and saw them in their default spot. This is something that shouldn’t’ve changed. And I posted separately that the knowledgebase is still out of date. I found the fix by delving into code.

    I’m using WPSuperCache, one of those most common caching for WP sites, and although I deactivated it AND reset permalinks, rules added to the .htaccess by the plugin perpetuated after it was deactivated. One of those rules was the source of issue.

    I deactivated WPSUPERCACHE, then deleted the .htaccess from the root, then rebuilt permalinks, then did the authorization.

    So the problem was a caching issue. The steps outlined above are a for-sure way to delete all the caching-related rewrites.

    #966049
    Geoff
    Member

    Hi Jeremy,

    Nice job getting this to work! I’m really sorry that the issue popped up in the first place, but I am certainly glad to hear it boiled down to clearing cache.

    I appreciate your feedback on how the Eventbrite Tickets changes were communicated. We certainly felt we did everything we could do notify any existing plugin owners about the significance of the change–from the upgrade notice and instructions for reauthorizing the plugin to our release notes–but that doesn’t mean we couldn’t have done better. If you have any specific ideas for what else we could have done to communicate the significance of the changes outside what we did, I’d love to hear them and see how we can use that feedback to improve our future releases. I know we’re working on a significant release to all our plugins in the near future, so your thoughts would be welcome.

    Thanks for detailing the steps you took to resolve the issue. This is super helpful. I want to make sure we’re good here, so please let me know if you have any other questions here and I’d be happy to help. I’d also be happy to issue you give you a free license if you’d like one–just email us at [email protected] and I can process that for you.

    Cheers,
    Geoff

    #966057
    Jeremy
    Participant

    Please note it did not come down to clearing the cache.

    It came down to deleting the .htaccess file and then rebuilding a fresh .htaccess. The cache wasn’t the issue, rewrite rules installed by WPSuperCache was an issue. Perhaps a bugfix will be adding a more robust rewrite rule, as well as noting caching systems can interfere in documentation.

    Also, I read patch notes. There was no mention of the function name change for tickets output. So my tickets box moving problem was not communicated in patch notes.

    I don’t need a free license. Thanks for the offer.

    #966066
    Jeremy
    Participant

    Developers, are, in general, trained to handle major releases with more caution than point-releases.

    I’m going to run a major WP overnight, like when 4.2 released. I’m going to turn off caching and monitor for error. Point releases are easier to manage, and less risky.

    I know Eventbrite’s updated API pushed this update faster than you may have planned, but I think its risky to tie extension releases to the core release. If you need to make a major release to aa extension, push the core version to a major number too. It will give me the heads up that “hey, stuff might break” and “don’t do this during high traffic”.

    I know I was frustrated yesterday, mostly because I was losing money, but also because I wouldn’t have run that update had I known there was such a big risk of major stuff breaking.

    More than anything, I’m most annoyed that the function for the EB tickets box name changed (on a point release). It wasn’t in the notes, as I mentioned above.

    #966087
    Geoff
    Member

    Hi Jeremy,

    Nice follow-up here! I see you’ve marked this thread as Resolved, so I’ll go ahead and close it, but I do certainly appreciate the feedback. I’m sharing your thoughts here with the team and will use them to help us with future releases.

    In the meantime, thanks again for reaching out. We’re here to help if you need anything else, so please feel free to start a new thread if anything comes up.

    Cheers,
    Geoff

    #988020
    Leah
    Member

    Hello,

    Thank you again for bringing this issue to our attention. We’re happy to say that we have added a fix for this into our upcoming version 3.11 release. Keep an eye on your Updates page for the new version. If you have any trouble with the update (or are still seeing this problem after you update) please start a new thread and we’d be happy to help out.

    Thank you for your patience while we got this release ready to go!

    Best,
    Leah
    and the rest of The Events Calendar team

Viewing 13 posts - 1 through 13 (of 13 total)
  • The topic ‘OAuth Redirect to blog archives, not wp-admin (NOT FIXED)’ is closed to new replies.