Skip to content
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.

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

Subdir Support in Wiki #27858

Closed
8 tasks
snoweuph opened this issue Oct 31, 2023 · 16 comments
Closed
8 tasks

Subdir Support in Wiki #27858

snoweuph opened this issue Oct 31, 2023 · 16 comments
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@snoweuph
Copy link

snoweuph commented Oct 31, 2023

Feature Description

This Feature Request is about Support for Subdirectories in Gitea Wiki.
This Issue/Feature Request is inspired by: #823 and This Issue on Codeberg

As far as I understand, the Goal of this Request is included in #823, but because of the Other Things in that Feature-Request, its having Slow Progress.

Advantages

I think Support for Subdirectories is a Great Feature, because:

  • It allows More Complex Structures, while keeping them Sorted
  • It helps to bring structure into a Wiki
  • It would work with a lot of Tools Out of the Box like: Obsidian and Logseq
  • Its how most Bigger Wikis are Structured, Examples: Gitea Docs, Godot Wiki

What its About

This Feature Request is only about minimal needed subdir support, meaning:

  • Files Can be Put in Subdirectories
  • Files In Subdirectories can be normally Visited
  • Files In Subdirectories can be normally Linked in Markdown to
  • Subdirectories are shown in the Pages View.
  • Files Renamed in Sudirs stays in them. (API support for Subdirs)
  • / in File names is interpreted as Path/folder

Nice To Have

  • Subdirectories are shown in the Pages View of the Wiki
  • When changing / creating a wikipage-name, there's an info about Subdirectories and allowed characters, if there's an / in the name

Other Information

I am Interested in Contributing this Feature myself, so I'm also creating this Feature Request, to only have the Focus on the minimum I wish to Contribute, without having to worry about some Extra Features, which some might want, others not, and still need decision on how to be executed. (speaking bout #823)

@snoweuph snoweuph added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Oct 31, 2023
@snoweuph
Copy link
Author

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

@snoweuph
Copy link
Author

snoweuph commented 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
Copy link
Author

snoweuph commented 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.

@olivierlambert
Copy link

Hey there!

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

@shamefulCake1
Copy link

Is there progress on this issue planned any time soon?

@bucovaina
Copy link

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

@snoweuph
Copy link
Author

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.

@ilf
Copy link

ilf commented Oct 17, 2024

@snoweuph: Thanks for creating this issue. Thanks for working on a solution. And thanks for the PR at #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?

@snoweuph
Copy link
Author

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
Copy link
Author

snoweuph commented 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 snoweuph closed this as not planned Won't fix, can't repro, duplicate, stale Oct 18, 2024
@snoweuph
Copy link
Author

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

@lunny
Copy link
Member

lunny commented 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.

@snoweuph
Copy link
Author

snoweuph commented Oct 18, 2024

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

@lunny
Copy link
Member

lunny commented Oct 19, 2024

I think we can just follow #823 . Anyway, thank you for your contributions.

@ilf
Copy link

ilf commented Oct 19, 2024

I think we can just follow #823 . Anyway, thank you for your contributions.

The original post sais why #823 is much more than this issue:

the Goal of this Request is included in #823, but because of the Other Things in that Feature-Request, its having Slow Progress.

@lunny
Copy link
Member

lunny commented Oct 20, 2024

I think we can just follow #823 . Anyway, thank you for your contributions.

The original post sais why #823 is much more than this issue:

the Goal of this Request is included in #823, but because of the Other Things in that Feature-Request, its having Slow Progress.

Yes, I updated #823's content, some content was inspired by this one.

@go-gitea go-gitea locked as resolved and limited conversation to collaborators Jan 15, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants