Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Facebook Sign In with Google Sign In with OpenID Sign In with Twitter
Support for Vanilla Forums Cloud product

In this Discussion

Follow Us


Incorrect redirect after clearing Private Messages (Conversations)

edited December 2010 in Questions
I have Vanilla 2.0.16 installed to directory http://mysite.com/forum/
When I delete (clear) conversations (I am pressing button Delete Conversation). Dialog box pops up and I press OK. Then It redirects me to http://mysite.com/forum/forum/messages/all instead of http://mysite.com/forum/messages/all. 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?

Comments

  • 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);
  • TimTim Lord of Servers Vanilla Staff
    Hm. That shouldn't need to happen. Url() is @Todd's baby, maybe he has some ideas

    Vanilla Forums Senior Developer [GitHub, Twitter, About.me]

  • 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.
  • judgejjudgej
    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.
  • LincolnLincoln Community Instigator Vanilla Staff
    Issue is filed here: https://github.com/vanillaforums/Garden/issues/#issue/582 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.

    Sr Developer at Vanilla Forums [GitHub, Twitter]

  • judgejjudgej
    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.
  • 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);
    
      $this->Render();
      echo "<br />Please Wait...";
      header('Location: index.php?p=/messages/inbox');`
    
Sign In or Register to comment.