Papa-Kind-Treff – Project Context

Updated: 2026-08-07

Summary

Papa-Kind-Treff is a PHP-based platform for fathers. Core areas are local events, appointments, and meetups, a community forum, member profiles with optional child information, and a moderation/admin area.

Key Product Decisions

Main navigation remains intentionally compact: Home, Event Search, Community.
Events is the primary product term across the UI.
Secondary wording is used only in SEO and explanatory copy.
The community is hierarchical: categories -> boards -> threads -> posts.
Moderation is separated from the normal community frontend.
Location features are important for local discovery.
The existing events logic remains active for now, but future growth should move toward a broader listing, place, and occurrence model.
Site admins get a dedicated system section for global operating and service flags.

Account / Member Area

Profile menu currently contains Profile, Children, Events, Places & Events, Community, Settings, Logout.
SiteOwner additionally gets the area Profile Levels.
Children can be created, edited, and deleted.
If a birth date is set, age is calculated automatically and updated later when needed.
Account email is encrypted application-side and addressed through a separate HMAC lookup hash.
Profile address can be completed via address search or browser-based location import.
The Events area is limited again to real own events and event participations.
The Events area now also provides a manual ICS export and a personal subscribable calendar feed for all own events and event participations.
The Events area is now separated in the UI into My Events, Calendar Sync, and Expired Events so that active events, calendar tasks, and past items stay clearly separated.
Inside My Events, the Create New Event button now lives directly in the upper tab row; the previous participation box is now labeled Registered Events and also includes a direct link to Event Search.
Places and event-like entries were moved for now into a separate member-area section Places & Events.
Inside Places & Events, users can create permanent places and time-limited event-style entries.
New places and event-style entries stay in a pending state until an admin approves them for publication.
Change and deletion wishes for published places and event-style entries always run through a reasoned moderation request.
Pending new places and event-style entries can already be used as location suggestions for events while they are still under review.
Duplicate submissions for places and event-style entries should be blocked server-side at least by name and address.
The Events input flow should stay as simple as possible and therefore only shows fields relevant for real scheduled events.
Own events now only require title, date, and the with children choice; the description is optional.
Event locations now support the modes place from database, event from database, or custom.
When a database-backed place or event is selected, the address and category are taken directly from that source entry.
Database-backed event locations now use a real select field instead of free text; place from database only shows places, while event from database only shows currently active event-style entries inside their valid date window.
Inside the own-event form, valid until and recurrence are hidden.
When an own event uses a database-backed location, address and category are shown as informational values and are not edited directly.
The own-event form now offers direct links into creating a new place or a new event-style listing.
After that intermediate step, the user returns to the own-event form with the previous event input restored and the newly created place or event-style listing already selected.
When event from database is selected, the event date must fall inside that source event's valid date window.
Categories in the member area are handled via a search input with existing suggestions and automatic creation when needed.
Own events support an optional description, a clear with children yes/no field, optional capacity, an optional image, and either a database-backed location or a custom address.
Profile Levels is an owner-only area for community levels and the overview of system levels.
Community levels are now editable through system_settings.community_levels_json and currently carry the rights highlight helpful replies and apply for forum admin.
Inside Profile Levels, the owner can additionally search users and manually increase community points with a required reason.
Profile Levels also includes a list of users who reached at least the rank Pillar of the Fathers Community within the last 30 days.
System levels remain separate as the roles Forum Admin, Site Admin, and SiteOwner.
System-level assignment in Community Admin now runs through user search instead of raw user IDs; site admins remain limited by the existing role rules.
Categories no longer live under System, but in their own member-area section Categories; that area only shows newly created categories and merges them into existing database categories through a suggestion field.
New categories remain visible there until an authorized user confirms them or merges them into an existing category.
Community levels can now additionally carry the rights for category handling as well as place and event approvals.

Technical Frame

custom front controller in public/index.php
templates under partials/
business logic under src/App/
global frontend mainly via public/assets/js/app.js and public/assets/css/app.css

New Expansion Stage: Listings and Places

New table base: listing_places, listings, listing_occurrences, listing_prices, listing_benefits, listing_categories
Goal: later distinguish between own event, partner offer, general place, and editorial event entry
Google is not integrated productively yet; the system is only being prepared for it via settings and data fields

Deferred To-dos

Large calendar-provider integrations should be added later in addition to the ICS feed, starting primarily with Google and Microsoft/Outlook.
The target model is no reverse sync, but a user-side OAuth login through Papa-Kind-Treff followed by a direct calendar connection or event synchronization at the respective provider.

Maintenance Note

Whenever one of these files changes, the matching files in Internal/de/ and Internal/en/ must be kept aligned.
The root README.md acts as the startup document for new chats and should be reviewed alongside major context changes.

6.6 KiB Raw Blame History Unescape Escape