8000 fix search not working by hugomassing · Pull Request #515 · filebrowser/filebrowser · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

fix search not working #515

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Aug 22, 2018
Merged

fix search not working #515

merged 2 commits into from
Aug 22, 2018

Conversation

hugomassing
Copy link
Contributor

Closes #484

Fix search not working because the path was in lower case and resulted in a 404 when clinking on the search result.

This is a quick fix while a better solution is found for the fuzzy search / case insensitive search problems described in #252 and #415.

@hugomassing hugomassing mentioned this pull request Aug 21, 2018
Closed
@eine eine requested a review from hacdias August 21, 2018 15:34
@eine eine force-pushed the master branch 2 times, most recently from e7f4486 to 69a3f85 Compare August 22, 2018 00:30
@eine
Copy link
Contributor
eine commented Aug 22, 2018

@hugomassing, can you please rebase this PR on top of master? Note that http/websockets.go is now located at lib/http/websockets.go.

@hacdias
Copy link
Member
hacdias commented Aug 22, 2018

Thanks @hugomassing. Could you just rebase, as @1138-4eb said?

@eine eine mentioned this pull request Aug 22, 2018
Closed
@hugomassing hugomassing force-pushed the fix/search branch 2 times, most recently from 5ae59ed to d6b8c1c Compare August 22, 2018 14:40
@hugomassing
Copy link
Contributor Author

Looks good now :)

@eine eine merged commit d16352b into filebrowser:master Aug 22, 2018
@eine eine removed the in progress label Aug 22, 2018
@eine
Copy link
Contributor
eine commented Aug 22, 2018 •
edited
Loading

Thanks @hugomassing! 👋

Just a note for future contributions: I ran gofmt lib/http/websockets.go on top of your commit in order to remove some whitespaces.

@ChrisGet
Copy link

I have just installed this great piece of software using the install script method:
curl -fsSL https://filebrowser.github.io/get.sh | bash

Version is 1.10 but I still have the search issue with results being all lower case so the links are not found. How can I include the fix as stated above?

@eine
Copy link
Contributor
eine commented Sep 18, 2018 •
edited
Loading

Hi @ChrisGet, v1.10.0 was released on 2018-08-16, and this fix was added on 2018-08-22. So it will be available in the next release.

If you want to have it now, you need to build filebrowser from sources. See https://github.com/filebrowser/community, build and development.

Alternatively, you can use docker image filebrowser/filebrowser:latest, which is always built with the latest commit in branch master. So, the fix should be already applied there.

@ChrisGet
Copy link

@1138-4eb Thanks for your response. Do you have any idea when the next release will be published?

I have tried using the install files build_all.sh but I am hitting problem after problem with installing go, rice, and everything else.

I have managed to install docker. I am on Debian 8.10 Jessie. How do I use that docker image that you referred to? I have no experience with docker I'm afraid.

Thanks.

@ChrisGet
Copy link

@1138-4eb Sorry I found the documentation. I'll try the docker method. Thanks.

@eine
Copy link
Contributor
eine commented Sep 19, 2018

Sorry I found the documentation. I'll try the docker method. Thanks.

Let us know if you have any problem with it. The image should be automatically downloaded, so you just need to run a container.

Do you have any idea when the next release will be published?

That is actually hard to reply at now. If you have a look at https://github.com/filebrowser/filebrowser/commits/master, you will see that, indeed, we released v1.10.0 a month ago because we were going to introduce some breaking changes (#506). Therefore, the next release should be v2.0.0, according to https://semver.org/. However, golang just released version 1.11 (#530), which introduces some changes about how packages/dependencies are handled: https://github.com/golang/go/wiki/Modules#semantic-import-versioning:

(...) In contrast, a package that has opted in to modules must include the major version in the import path for any imported v2+ modules)
There are two ways to release a v2 or higher module version. Using the example of creating a v2.0.0 release, the two options are:

  • Update the go.mod file to include a /v2 at the end of the module path. Tag the release with v2.0.0.
    • To avoid confusion with this approach, consider putting the v2.. commits on a separate v2 branch.
    • If instead you have been previously releasing on master and would prefer to tag v2.0.0 on master, that is a viable option, but consider creating a v1 branch for any future v1 bug fixes.
  • Alternatively, create a new v2 subdirectory (e.g., my/module/v2) and place a new go.mod file in that subdirectory. The module path must end with /v2. Copy or move the code into the v2 subdirectory. Tag the release with v2.0.0.
    • This provides greater backwards compatibility. In particular, Go versions older than 1.9.7 and 1.10.3 are also able to properly consume and build a v2 or higher module created using this approach.

This is yet to be solved in #496.

At the same time #532, so it is difficult to know when will other breaking changes be done.

Meanwhile, we might cherry-pick some commits after v1.10.0 (#508, #514, this and #531) and either:

  • Apply them on top of tag v1.10.0 as hotfixes (v1.10.1).
  • Rebase/reorder master branch and tag/publish a new release (v1.10.1) just before the breaking changes.

The first option is not desirable, because we would have a bunch of duplicated commits, really close to each other. But, the second one requires to rebase the master branch.

@hacdias , @Equim-chan , any ideas?

@hacdias
Copy link
Member
hacdias commented Sep 19, 2018

@1138-4eb I have as a rule of thumb not to force push to master and I believe it's a best practice so we shouldn't rebase it.

How would we do the first one?

@eine
Copy link
Contributor
eine commented Sep 19, 2018

How would we do the first one?

We can either cherry-pick or:

git checkout -b tmp origin/master
git rebase -i v1.10.0
# Remove the commits we don't want to keep in `v1.10.1`.
git tag v1.10.1
git checkout master
git branch -D tmp
git push origin v.1.10.1

@eine eine mentioned this pull request Nov 21, 2018
Closed
hacdias pushed a commit that referenced this pull request May 11, 2019
@hugomassing
fix: search case sensitiveness (#515)
5946883 
Former-commit-id: 7d86ecccd2095be6bf7db6fa4b93e226cb590661 [formerly c6e3db510232dad7f175ede09481dd3c14cac26c] [formerly cf4dfe6c7ce811d489292a0896b4de46a89bfdc0 [formerly d16352b]]
Former-commit-id: bfa8e15160d458a77c9a1e5cea759d214716dbdd [formerly 74fa0134bc42399b0f3a6627791efed6f5176fa6]
Former-commit-id: 04d04ac91ad7047afc541d5c43e69f81fae54f2a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@hacdias hacdias hacdias approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Searched filename in UPPER CASE is found but result is lower case, thus file not found :(
4 participants
@hugomassing @eine @hacdias @ChrisGet
0