HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Fix for wrong URL error

I noticed that in some circustances a wrong url error appears upon attempt to change the discussion author. I was able to fix this on my intranet as follows:

Change class.author selector.plugin.php line 24 (line# depends on the plugin version you use) from:

$Url = "/discussion/author?discussionid={$Discussion->DiscussionID}";

to:

$Url = url("/discussion/author?discussionid={$Discussion->DiscussionID}");

@R_J - would you PR it?

Comments

  • R_JR_J Admin

    I can surely do this, but here are some thoughts to this...

    1. Why should it be me? The repo is here and everybody with a GitHub account can do it. It is an easy fix and from my own experience I can tell that is damn satisfying to see your own name in the list of contributors. So anybody who reads this: GO! GO! GO! Hurry up to be the first! =)
    2. Such a small fix could be done very easily in the GitHub online editor.
    3. It should be backported to the 2.5. If I remember correctly, that is done by something git calls "cherry picking", but I'm not sure if this is the correct term and if this is also possible with the GitHub interface.
    4. If the plugin available here in the download section should be updated afterwards, there should be some people acknowledging that the GitHub version from branch 2.5 is working with Vanilla 2.5.1
  • rbrahmsonrbrahmson ✭✭✭

    Oh, there are reasons why it shouldn't be me...Most of what I do is in our intranet (no github) so I have never mastered it. I only use it as an external cloud backup of my public variants of the intranet work and found it challenging (at least on my window based machine), haven't figured out how to multiversion my own plugins. I am sure I could master it, but time is scarce...

    If this is too much effort I apologize and join you in calling everyone to race for the glory.

    BTW, this is marked as a Vanilla maintained plugin. Shouldn't it therefore work on 2.5?

  • R_JR_J Admin

    Browser + GitHub-Account = enough git for that :wink:






  • charrondevcharrondev Vanilla Staff

    Just because something is in the vanilla/addons repository does not mean that it is heavily used or tested on Vanilla cloud in the same scenarios that are found in open source installations. In this case @R_J submitted the fix rather easily directly through Github.

    As far as backports/releases go, this type of change could be backported to the previous release by doing the following locally, but we are very unlikely to accept backport pull request for something that never had an issue in our github repo, and didn't have discussion prior of why the change should be backported. But for doing so the process looks like the following:

    1. Get the short hash of the commit you want to backport by using git log. It can also be seen in the commits view a pull request on github. In this case it is 7699791
    2. Checkout the release/2.5 branch
    cd /my-repos/vanilla
    git checkout release/2.5
    
    1. Checkout a backport branch
    git checkout -b backport/605
    
    1. cherry-pick the commit
    git cherry-pick 7699791
    
    1. Make PR to release/2.5 branch.
  • rbrahmsonrbrahmson ✭✭✭

    Thank you for all the hints/advise. I will have to look at it more thoroughly after my current projects. Starred this so I won't forget.

Sign In or Register to comment.