Summary

1. Links change on signup - possibly not the case in @eiennohi's hopepage redesigns (need to check).
2. iPhone href - This is probably going to take some upgraded regex (it thinks the /p in the iphone link is telling it its one of our pages).
3. https://www.minds.com and https://minds.com.

@medworthy

Before logging in, the side bar displays links in example 1. However, when refreshing or returning to the Newsfeed section, example 2 is displayed (note that I have tested this with Quantum and Blink based browsers).

The iPhone href returns a blank page.

Also within the minds.com/p pages (ie. dmca, terms, contact, bill of rights etc.), at the top of the left sidebar, there is a similar href (which again, displays the title “IPHONE”) that links to the same URL as above.

I have also noticed that within the minds.com/p pages, some hrefs refer to URL’s that are prefixed with “https://www.minds.com/”, whilst other hrefs lack the www prefix (ie. “https://minds.com/”). This inconsistency looks unprofessional and needs to be resolved

Steps to reproduce

(How one can reproduce the issue - this is very important)

Platform information

Cross-platform web, tested Quantum and Blink based browsers by @medworthy

What is the current bug behavior?

(What actually happens)

What is the expected correct behavior?

(What you should see instead)

Relevant logs and/or screenshots

Please review the following Minds Help and Support post and the corresponding secondary Gitlab ticket.

Reference:

• Associated H&S Enquiry
  https://www.minds.com/newsfeed/1033073486049923072

• Group Based Table Of Contents
  https://www.gitlab.com/minds/front/issues/2132

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

/label ~"T - Bug" ~"S - Triage:new"

changed the description

changed the description

changed the description

changed the description

added scoped labels

assigned to @javanick

@javanick, @ottman, @jotto141, @xander-miller.
This fairly straightforward issue has not been updated in over a month now.

Why hasn't this been resolved within the amount of time that would be considered as being overly sufficient and what is going to happen with this issue (please provide an ETA for the resolution of this ticket)?

Just added some more labels to prioritize this. The footer is being reworked right now as you can see in https://minds.com/pro so it'll be addressed soon. @brianhatchet

closed

reopened

added scoped labels and automatically removed label

added scoped label and automatically removed label

added scoped label and automatically removed label

unassigned @javanick

mentioned in issue #2137

changed weight to 2

added scoped label and automatically removed label

added scoped label and automatically removed label

assigned to @benhayward.ben

changed time estimate to 2h

added 1 deleted label

added scoped labels and automatically removed label

added scoped label and automatically removed label

added scoped label and automatically removed label

changed the description

@javanick, take a look at number 3 here if you can (all the internal /p/ pages should be pointing to https://www.minds.com)

changed weight to 4

@benhayward.ben reported this card is more complex then it looks because there is 5 headers and some cleanup to properly handle the urls. Changing the time to 4 hours

changed time estimate to 4h

mentioned in commit f6b06f37

mentioned in commit 6b00179c

mentioned in merge request !702

added 3h of time spent at 2019-12-18

Did indeed, and the Regex was annoying to iron out but I'm happy with where it is now and the test coverage.

Now will likely take another half hour or so to mirror the links from production into the sandbox admin pages.

Had to make some regex changes as found a bug after setting up sandbox links to mirror production

added 1h of time spent at 2019-12-18

Took much longer than expected. Was running into race conditions with RegExp wherein when spec tested out showed:

expect(foo()).toBeFalsy() //passed
expect(foo()).not.toBeTruthy() //failed

Solution was to instantiate a new RegExp object every time the isInternalLink check is made.

@benhayward.ben this should not have even been done because the footer is getting redone in the new designs. @brianhatchet can you make sure bugs like this that are going to get fixed with new designs are not slotted anymore?

Do the changes extend to the newsfeed footer and everything else?

Not a huge problem because unless we're revamping the page system internally, this still fixes an issue that would remain on the new footer.

added 5h of time spent at 2019-12-19

added scoped label and automatically removed label

added scoped label and automatically removed label

assigned to @edgebal

added scoped label and automatically removed label

added scoped label

removed 1 deleted label

@benhayward.ben Moving this back to buddy review unless there's a reason you moved it to followup?

added scoped label and automatically removed label

added scoped label and automatically removed label

My apologies for not documenting on GitLab. Got some feedback to address (refactoring the regex)

added scoped label and automatically removed label

added scoped label and automatically removed label

added scoped label and automatically removed label

Simplified Regex and retested.

added 30m of time spent at 2020-01-03

added scoped label and automatically removed label

added scoped label and automatically removed label

Working OK on review site, but there's a merge conflict so it might need a re-test after it's fixed.

unassigned @edgebal

added scoped label and automatically removed label