Subdir Support in Wiki #11938

@snoweuph commented on GitHub (Oct 31, 2023):

I created a Fork, in which I will work on this: https://github.com/snoweuph/gitea

@snoweuph commented on GitHub (Oct 31, 2023): I created a Fork, in which I will work on this: https://github.com/snoweuph/gitea

GiteaMirror commented

@snoweuph commented on GitHub (Oct 31, 2023):

Okay, First Problem I was able to PinPoint is that:
wiki.go#findEntryFile calls tree_blob_nogogit.go#GetTreeEntryByPath, which prunes subdirs.

The Function GetTreeEntryByPathhas quite some calls, so It should probably be not modified.

Next step for me is to replace the call to that function with a custom Helper Function for testing, to find out, wich other things I might need to change

After I found all things I might need to change, im going to create a list of changes that I think need to do, and ask how to do them best

Edit: I think instead of a helper, I should modify the: wikiContentsByEntry Function (wiki.go)

@snoweuph commented on GitHub (Oct 31, 2023): Okay, First Problem I was able to PinPoint is that: `wiki.go#findEntryFile` calls `tree_blob_nogogit.go#GetTreeEntryByPath`, which prunes subdirs. The Function `GetTreeEntryByPath`has quite some calls, so It should probably be not modified. Next step for me is to replace the call to that function with a custom Helper Function for testing, to find out, wich other things I might need to change After I found all things I might need to change, im going to create a list of changes that I think need to do, and ask how to do them best **Edit:** I think instead of a helper, I should modify the: `wikiContentsByEntry` Function (wiki.go)

GiteaMirror commented

@snoweuph commented on GitHub (Oct 31, 2023):

Updating the loop in tree_blob_nogit.go like this, results in the Pages not throughing an Error, but I dont know if it has any other problems, that it brings with itselve.

for i, name := range parts {
	if i == len(parts)-1 {
		entries, err := tree.ListEntries()
		if err != nil {
			return nil, err
		}
		for _, v := range entries {
			if v.Name() == name {
+				if v.fullName == "" {
+					v.fullName = relpath
+				}
				return v, nil
			}
		}
	} else {
		tree, err = tree.SubTree(name)
		if err != nil {
			return nil, err
		}
	}
}

Renaming a site though with that change, results in the path beeing escaped, and the file moved by that.

@snoweuph commented on GitHub (Oct 31, 2023): Updating the loop in `tree_blob_nogit.go` like this, results in the Pages not throughing an Error, but I dont know if it has any other problems, that it brings with itselve. ```diff for i, name := range parts { if i == len(parts)-1 { entries, err := tree.ListEntries() if err != nil { return nil, err } for _, v := range entries { if v.Name() == name { + if v.fullName == "" { + v.fullName = relpath + } return v, nil } } } else { tree, err = tree.SubTree(name) if err != nil { return nil, err } } } ``` Renaming a site though with that change, results in the path beeing escaped, and the file moved by that.

GiteaMirror commented

@olivierlambert commented on GitHub (Nov 29, 2023):

Hey there!

Also very interested by your work. Hopefully your PR will be merged soon 👍

@olivierlambert commented on GitHub (Nov 29, 2023): Hey there! Also very interested by your work. Hopefully your PR will be merged soon :+1:

GiteaMirror commented

@shamefulCake1 commented on GitHub (Jan 17, 2024):

Is there progress on this issue planned any time soon?

@shamefulCake1 commented on GitHub (Jan 17, 2024): Is there progress on this issue planned any time soon?

GiteaMirror commented

@bucovaina commented on GitHub (Oct 17, 2024):

Also a gentle question if there is any planning around this issue, would be nice to have!

@bucovaina commented on GitHub (Oct 17, 2024): Also a gentle question if there is any planning around this issue, would be nice to have!

GiteaMirror commented

@snoweuph commented on GitHub (Oct 17, 2024):

In a few Months I will have some time for contributing to FOSS again, but I wont contribute it here, but instead to the forgejo upstream, because I switched. Now that Go Git support is dropped, contributing this will be a lot easier.

@snoweuph commented on GitHub (Oct 17, 2024): In a few Months I will have some time for contributing to FOSS again, but I wont contribute it here, but instead to the forgejo upstream, because I switched. Now that Go Git support is dropped, contributing this will be a lot easier.

GiteaMirror commented

@ilf commented on GitHub (Oct 17, 2024):

@snoweuph: Thanks for creating this issue. Thanks for working on a solution. And thanks for the PR at https://github.com/go-gitea/gitea/pull/27900.
I don't understand why you closed this issue and marked it as completed?
It's okay to withdraw your PR. It's okay you want to stop contributing to this project.
But other people are interested in this issue in this project. Can't you just leave it open - for others?

@ilf commented on GitHub (Oct 17, 2024): @snoweuph: Thanks for creating this issue. Thanks for working on a solution. And thanks for the PR at https://github.com/go-gitea/gitea/pull/27900. I don't understand why you closed this issue and marked it as completed? It's okay to withdraw your PR. It's okay you want to stop contributing to this project. But other people are interested in this issue in this project. Can't you just leave it open - for others?

GiteaMirror commented

@snoweuph commented on GitHub (Oct 17, 2024):

No, because im the author and thus sadly cant unsubscribe, others that want it here can open up a new issue or follow to forgejo, when I've done it there

@snoweuph commented on GitHub (Oct 17, 2024): No, because im the author and thus sadly cant unsubscribe, others that want it here can open up a new issue or follow to forgejo, when I've done it there

GiteaMirror commented

@snoweuph commented on GitHub (Oct 17, 2024):

Simply now that forgejo switches from being downstream to its own project, I'm switching over as well with my PR issue, and my planned contribution list.

@snoweuph commented on GitHub (Oct 17, 2024): Simply now that forgejo switches from being downstream to its own project, I'm switching over as well with my PR issue, and my planned contribution list.

GiteaMirror commented

@snoweuph commented on GitHub (Oct 18, 2024):

Sry, misread the part about closing as completed, looks like the android app didnt gave me the option to close as something specific, just to "close", corrected that and closed it as not planned. The reasons not to keep it open are described in the other messages

@snoweuph commented on GitHub (Oct 18, 2024): Sry, misread the part about closing as completed, looks like the android app didnt gave me the option to close as something specific, just to "close", corrected that and closed it as not planned. The reasons not to keep it open are described in the other messages

GiteaMirror commented

@lunny commented on GitHub (Oct 18, 2024):

Simply now that forgejo switches from being downstream to its own project, I'm switching over as well with my PR issue, and my planned contribution list.

The fork continues to cherry-pick commits on a weekly basis but does not contribute back upstream. While our MIT license permits this, I believe this behavior doesn’t fully align with the collaborative spirit of open source. They frequently criticize the project, even as they continue to cherry-pick its commits.

I’d like to keep this issue open, even if you’re no longer using Gitea, as it could benefit other users who are looking forward to this feature. However, if you’d prefer not to have it reopened, I can create a new issue instead.

Moderator Edit: There is a broad statement included in here, which doesn't mean to apply to an entire group, and is meant to reference a small group of specific individuals. The Gitea project has received contributions from individuals that have contributed to both projects.

@lunny commented on GitHub (Oct 18, 2024): > Simply now that forgejo switches from being downstream to its own project, I'm switching over as well with my PR issue, and my planned contribution list. The fork continues to cherry-pick commits on a weekly basis but does not contribute back upstream. While our MIT license permits this, I believe this behavior doesn’t fully align with the collaborative spirit of open source. They frequently criticize the project, even as they continue to cherry-pick its commits. I’d like to keep this issue open, even if you’re no longer using Gitea, as it could benefit other users who are looking forward to this feature. However, if you’d prefer not to have it reopened, I can create a new issue instead. Moderator Edit: There is a broad statement included in here, which doesn't mean to apply to an entire group, and is meant to reference a small group of specific individuals. The Gitea project has received contributions from individuals that have contributed to both projects.

GiteaMirror commented

@snoweuph commented on GitHub (Oct 18, 2024):

please create a new Issue.
and to the licenses: I prefer my code to be GPL

@snoweuph commented on GitHub (Oct 18, 2024): please create a new Issue. and to the licenses: I prefer my code to be GPL

GiteaMirror commented