Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Incorrect redirect after clearing Private Messages (Conversations)

edited December 2010 in Vanilla 2.0 - 2.8
I have Vanilla 2.0.16 installed to directory
When I delete (clear) conversations (I am pressing button Delete Conversation). Dialog box pops up and I press OK. Then It redirects me to instead of So I get 404 error after deleting conversation, because it redirects me to /forum/forum/... instead of /forum/...
How to solve this? Is it bug or not?


  • Options
  • Options
    Solved it.
    In class.messagecontroller.php if function Clear() line:
    $this->RedirectUrl = Url('/messages/all');
    change to:
    $this->RedirectUrl = Gdn::Request()->Url('messages/all', TRUE);
  • Options
    TimTim Operations Vanilla Staff
    Hm. That shouldn't need to happen. Url() is @Todd's baby, maybe he has some ideas

    Vanilla Forums COO [GitHub, Twitter,]

  • Options
    Yep. This is reported bug. The problem existed also when deleting thread but that one was solved a while ago. However, problem with messages persisted.
  • Options
    edited March 2011
    So - running 2.0.17 code three months later, and the redirect still appears to be not working. Is this fix going to be in the next release?

    I'm running Vanilla in a folder /foo When deleting a private message (conversation) I get redirected to /foo/foo/messages/all - the folder gets doubled up. When looking at what "Url(...)" gives, it includes the /foo and I gess the AJAX handler adds the http://domain/foo prefix to that too.

    The above suggested fix works for me. I guess it gets around the problem by passing the AJAX handler a full (external) URL to the messages page, complete with domain, and that stops the JS AJAX handler from adding its own path on.
  • Options
    LincLinc Detroit Admin
    Issue is filed here: Added notes from this discussion.

    Thanks for the extra info, @judgej. I'm reticent to just throw the 'TRUE' on the end to send it with domain rather than fixing whatever the core problem might be with the ajax handler.
  • Options
    edited March 2011
    I tried following it through to see what was happening, but concluded in the end that since I did not know which was correct: the JS side adding the path or the server side adding the path, I just went for the solution here. I've also not followed up why I'm not seeing this problem elsewhere - perhaps this is just one last remnant of relative AJAX URLs that has not been changed?

    TBH, full URLs everywhere they are used dynamically are a fine way to approach this kind of issue in my experience. It is only when URLs (and root paths) get embedded in logfiles and content that it becomes a problem, since it makes the application much less portable.

    It not as though people constantly move their applications around, but to support staging areas and pre-production/test instances, it needs to be easily relocatable to new paths and domains, with a full copy of live data.
  • Options

    I tried your method above... but could only get it to work by changing it to:
    `public function Clear($ConversationID = FALSE) {
    $Session = Gdn::Session();

      // Yes/No response
      $this->_DeliveryType = DELIVERY_TYPE_BOOL;
      // Clear it
      if (is_numeric($ConversationID) && $ConversationID > 0 && $Session->IsValid())
         $this->ConversationModel->Clear($ConversationID, $Session->UserID);
      //$this->InformMessage(T('The conversation has been cleared.'));
      $this->RedirectUrl = Url('/messages/all', TRUE);
      echo "<br />Please Wait...";
      header('Location: index.php?p=/messages/inbox');`
Sign In or Register to comment.