MokoConsulting/MokoGitea
1
0
Fork 0
Code Issues 142 Pull Requests Releases 90 Wiki Activity

feat(admin): configurable default landing page from site administration #240

New Issue
Closed
opened 2026-05-30 17:07:57 +00:00 by jmiller · 1 comment
jmiller commented 2026-05-30 17:07:57 +00:00
Owner
Copy Link
Copy Source

Summary

Add an admin setting to configure the default landing page for the MokoGitea instance. Currently the home page always shows the explore/repository list. Admins should be able to choose what visitors see when they hit the root URL.

Proposed options

  • Explore (current default) — the repository explore page
  • Specific Organization — redirect to a specific org's page (e.g. /MokoConsulting)
  • Login page — redirect unauthenticated users directly to the login page
  • Custom URL — redirect to any internal path (e.g. /MokoConsulting/MokoGitea/wiki)

Behavior

  • Unauthenticated users: respect the configured default page
  • Authenticated users: optionally redirect to their dashboard instead (existing behavior with LANDING_PAGE = dashboard)
  • The setting should be configurable from Site Administration without editing app.ini

Current state

Gitea already has a LANDING_PAGE setting in app.ini (home, explore, organizations, login, or a custom path). This feature would:

  1. Expose that setting in the admin UI (Site Administration > Settings)
  2. Add the "specific organization" option with an org selector
  3. Make it changeable at runtime without restarting the server

Files to investigate

  • modules/setting/server.go — where LANDING_PAGE is parsed
  • routers/web/home.go — the Home() handler that uses the landing page setting
  • routers/web/admin/config.go — admin config page
  • templates/admin/config.tmpl — admin config template

Created by @MokoBot - Claude Opus 4.6

## Summary Add an admin setting to configure the default landing page for the MokoGitea instance. Currently the home page always shows the explore/repository list. Admins should be able to choose what visitors see when they hit the root URL. ### Proposed options - **Explore** (current default) — the repository explore page - **Specific Organization** — redirect to a specific org's page (e.g. `/MokoConsulting`) - **Login page** — redirect unauthenticated users directly to the login page - **Custom URL** — redirect to any internal path (e.g. `/MokoConsulting/MokoGitea/wiki`) ### Behavior - **Unauthenticated users**: respect the configured default page - **Authenticated users**: optionally redirect to their dashboard instead (existing behavior with LANDING_PAGE = dashboard) - The setting should be configurable from Site Administration without editing app.ini ### Current state Gitea already has a `LANDING_PAGE` setting in app.ini (`home`, `explore`, `organizations`, `login`, or a custom path). This feature would: 1. Expose that setting in the admin UI (Site Administration > Settings) 2. Add the "specific organization" option with an org selector 3. Make it changeable at runtime without restarting the server ### Files to investigate - `modules/setting/server.go` — where LANDING_PAGE is parsed - `routers/web/home.go` — the Home() handler that uses the landing page setting - `routers/web/admin/config.go` — admin config page - `templates/admin/config.tmpl` — admin config template --- *Created by @MokoBot - Claude Opus 4.6*
jmiller commented 2026-05-30 17:08:32 +00:00
Author
Owner
Copy Link
Copy Source

Implementation Plan

Current state

Gitea already has full LANDING_PAGE support in app.ini:

  • modules/setting/server.go:30-38 — defines LandingPage type with options: home, explore, organizations, login, or any custom path
  • modules/setting/server.go:312-323 — parses the setting from config
  • routers/web/home.go:51-53 — redirects unauthenticated users to the configured landing page

What is missing: exposing this setting in the admin UI so it can be changed at runtime.

Implementation

1. Add to admin config panel

  • File: routers/web/admin/config.go — add LandingPageURL to the template data
  • File: templates/admin/config.tmpl — add a form section under Server settings with:
    • Radio buttons: Home / Explore / Organizations / Login
    • Text input for custom path (e.g. /MokoConsulting or /MokoConsulting/MokoGitea/wiki)
    • Optional org selector dropdown for the "specific organization" option

2. Admin config POST handler

  • File: routers/web/admin/config.go — handle the POST to update setting.LandingPageURL at runtime
  • The setting change takes effect immediately (no restart needed) since the home handler reads setting.LandingPageURL on every request

3. Persist to app.ini (optional)

  • Write the change to custom/conf/app.ini so it survives restarts
  • Or store in a new system_setting table row (Gitea already has this pattern for some runtime settings)

Scope

This is a small feature — approximately 3 files to modify, no migration needed. The core logic already exists; it is just a UI gap.

@MokoBot - Claude Opus 4.6

## Implementation Plan ### Current state Gitea already has full `LANDING_PAGE` support in `app.ini`: - `modules/setting/server.go:30-38` — defines `LandingPage` type with options: `home`, `explore`, `organizations`, `login`, or any custom path - `modules/setting/server.go:312-323` — parses the setting from config - `routers/web/home.go:51-53` — redirects unauthenticated users to the configured landing page **What is missing**: exposing this setting in the admin UI so it can be changed at runtime. ### Implementation **1. Add to admin config panel** - File: `routers/web/admin/config.go` — add `LandingPageURL` to the template data - File: `templates/admin/config.tmpl` — add a form section under Server settings with: - Radio buttons: Home / Explore / Organizations / Login - Text input for custom path (e.g. `/MokoConsulting` or `/MokoConsulting/MokoGitea/wiki`) - Optional org selector dropdown for the "specific organization" option **2. Admin config POST handler** - File: `routers/web/admin/config.go` — handle the POST to update `setting.LandingPageURL` at runtime - The setting change takes effect immediately (no restart needed) since the home handler reads `setting.LandingPageURL` on every request **3. Persist to app.ini** (optional) - Write the change to `custom/conf/app.ini` so it survives restarts - Or store in a new `system_setting` table row (Gitea already has this pattern for some runtime settings) ### Scope This is a small feature — approximately 3 files to modify, no migration needed. The core logic already exists; it is just a UI gap. --- *@MokoBot - Claude Opus 4.6*
Sign in to join this conversation.
Labels
Clear labels
breaking-change
Breaking API or behavior change
 ci-cd
CI/CD pipeline changes
 config
Configuration changes
 dependencies
Dependency updates
 deploy-failure
Deployment failed
 docker
Docker/container changes
 documentation
Documentation changes
 good first issue
Good for newcomers
 health-check
Repo health check result
 help wanted
Extra attention needed
 mokostandards
Related to MokoStandards framework
 pending: testing
Feature implemented but not yet tested with documented proof
 priority: critical
Must fix immediately
 priority: high
Important, fix soon
 priority: low
Nice to have
 priority: medium
Normal priority
 push-failure
Git push operation failed
 security
Security vulnerability or hardening
 size/l
200-500 lines changed
 size/m
50-200 lines changed
 size/s
10-50 lines changed
 size/xl
500+ lines changed
 size/xs
< 10 lines changed
 standards-drift
Deviates from MokoStandards
 standards-update
MokoStandards compliance update
 status: blocked
Blocked by dependency or decision
 status: in-progress
Actively being worked on
 status: needs-review
Awaiting code review
 status: on-hold
Paused intentionally
 status: wontfix
Will not be addressed
 sync-failure
Sync or mirror failed
 tech-debt
Technical debt and TODO/FIXME items
 type: bug
Something isn't working
 type: bug
type: chore
Maintenance, dependencies, cleanup
 type: enhancement
Improvement to existing feature
 type: feature
New functionality
 type: refactor
Code restructuring without behavior change
 type: version
Version bump or release
 upstream
upstream
Inherited from upstream Gitea
 work-in-progress
Draft or incomplete work
bug
Something is not working
 chore
Maintenance and housekeeping
 documentation
Documentation improvements
 enhancement
Improvement to existing functionality
 feature
New feature or request
 pending: dependency
Blocked by another issue or external dependency
 pending: deployment
Tested and approved, awaiting deployment to production
 pending: design
Needs UI/UX or architecture design before implementation
 pending: documentation
Feature works, needs documentation/wiki update
 pending: feedback
Awaiting feedback or decision from stakeholder
 pending: review
Implementation complete, awaiting code review
 pending: testing
Feature implemented but not yet tested
 priority: critical
Must fix immediately
 priority: high
Should fix soon
 priority: low
Nice to have
 priority: medium
Fix when convenient
 refactor
Code restructuring without behavior change
 roadmap
Planned feature or enhancement tracked on the roadmap
 scope: client
Client-specific work
 scope: dolibarr
Dolibarr modules and customizations
 scope: infrastructure
Server, CI, backups, monitoring
 scope: joomla
Joomla templates and extensions
 scope: waas
MokoWaaS platform
 security
Security vulnerability or hardening
 status: blocked
Waiting on external dependency
 status: duplicate
Duplicate of another issue
 status: in-progress
Being worked on
 status: needs-review
Ready for review
 status: wontfix
Will not be addressed
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
jmiller (Jonathan Miller) moko-deploy (Moko Deploy Bot)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MokoConsulting/MokoGitea#240
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?