Trip order, consistent everywhere

One ranking field the client edits — honored on every page of balionline.hu

Master summary — the gist in 30 seconds

TL;DRThe client can already set each trip's order in the CMS, but the website shows trips in several places and only some of them obey that order. The plan: make every trip list obey the one ranking field.

Input: one 'ranking number' per trip (already editable by the client). Output: the same, correct order on the collection page, the menu dropdown, the homepage and the trip planner — instead of today's mismatch.

Why this mattersA travel agency lives or dies by which trips are seen first. If the order is right on one page and random on another, the client loses trust and the best trips get buried. Fixing it once, at the source, means the client controls the whole site by editing a single number.

flowchart LR
  R["Ranking #<br/>(client edits once)"] --> A["Collection page<br/>obeys it ✅"]
  R -.broken.-> B["Menu dropdown<br/>ignores it ❌"]
  R -.broken.-> C["Homepage / planner<br/>ignores it ❌"]
  A --> G(["Goal: every<br/>surface obeys R"])
  B --> G
  C --> G

1 · What the client actually wants

TL;DRSet a trip's order once in the CMS and have it stick everywhere on the site.

Input: the client drags/sets a rank number on a trip. Output: that trip moves to the right spot on EVERY list, not just one.

Why it mattersDani already did the hard part — he built the editable ranking field. The remaining job isn't 'add ordering', it's 'make the ordering already there actually apply everywhere'. That reframing keeps us from over-building (no new plugin needed).

flowchart TD
  C["Client sets rank<br/>in CMS"] --> Q{"Does each list<br/>read the rank?"}
  Q -->|today: only some| Bad["Inconsistent order"]
  Q -->|after fix: all| Good["Same order everywhere"]

2 · How the site is actually built

TL;DRbalionline.hu is Dani's hand-built WordPress: custom PHP that queries a 'utazas' trip type — no page-builder doing the ordering for us.

Input: the 'utazas' custom post type + custom page templates. Output: trip lists rendered by PHP WP_Query loops, each of which decides its own sort order.

Why it mattersBecause each list is its own little query, ordering is NOT centralized — that's exactly why some lists drifted out of sync. The fix has to touch each query (or a shared helper) and point them all at the same ranking field.

flowchart LR
  PT["CPT: utazas<br/>(10 trips + 3 soon)"] --> Q1["Query A:<br/>collection page"]
  PT --> Q2["Query B:<br/>nav dropdown"]
  PT --> Q3["Query C:<br/>homepage / planner"]
  Q1 --> V["Each sorts<br/>independently"]
  Q2 --> V
  Q3 --> V

3 · The fix, in one idea

TL;DRFind every place trips are listed and make each one sort by the ranking field — same field, same direction.

Input: every trip-listing query on the site. Output: each query's 'order by' set to the ranking field (ascending), with a stable tiebreak.

Why it mattersOne source of truth beats per-page hacks. Once all queries read the same field, the client's single edit propagates site-wide, and future trips behave automatically. We deliberately reuse Dani's field instead of bolting on a plugin that would fight his code.

flowchart TD
  S1["Locate the ranking<br/>field (ACF / meta / menu_order)"] --> S2["Find ALL trip<br/>listing queries"]
  S2 --> S3["Set each: order by<br/>ranking ASC"]
  S3 --> S4["Verify order matches<br/>on every surface"]

4 · Getting in safely (it's live)

TL;DRThe site is in production and the admin is locked behind a cPanel firewall — so: back up first, whitelist in via cPanel, change, verify, done.

Input: the balionline.hu cPanel/FTP access. Output: a full backup, then careful edits to Dani's template, then a rollback path if anything looks off.

Why it mattersEvery change is instantly public on a real agency's booking site. Backing up first and keeping edits reversible is non-negotiable. We also stay inside the files Dani deploys so his next update doesn't silently wipe the fix.

flowchart LR
  CP["cPanel login"] --> WL["Whitelist IP<br/>past cPGuard"]
  WL --> BK["FULL backup<br/>(files + DB)"]
  BK --> ED["Edit queries"]
  ED --> VF["Verify all<br/>surfaces"]
  VF --> RB{"Looks right?"}
  RB -->|no| RR["Roll back"]
  RB -->|yes| DONE(["Ship"])

5 · One thing I checked and corrected

TL;DRThe ranking discussion isn't in the WhatsApp chat — I searched it exhaustively — so the field's exact name comes from the code, not the chat.

Input: 'it's in the chat'. Output: verified it isn't (≈650 msgs Mar–Jun + both Google Docs swept), so we read the truth from the live code instead.

Why it mattersPlanning on a wrong assumption wastes a real instance's time. The core intent you gave me directly is enough; the precise field name is a code lookup, which is more reliable than memory anyway.

flowchart TD
  A["Belief: details<br/>in WhatsApp"] --> B["Exhaustive search"]
  B --> C["Not found"]
  C --> D["Source of truth =<br/>the code + your brief"]

6 · Where this hands off

TL;DRThis is the explore step. Next: a fresh chat does the technical spec (find the field + all surfaces), then a third executes the change.

Input: this HANDOFF bundle. Output: Instance 2 writes a concrete checklist after reading the live code; Instance 3 makes the change with a backup.

Why it mattersSplitting explore → spec → execute keeps each step honest and cold-context-resumable, so nothing gets lost if a session breaks.

timeline
  title Planning chain
  Explore : You are here : intent locked
  Tech-spec : find field + all surfaces : write checklist
  Execute : backup : fix queries : verify live

Full technical handoff (HANDOFF.md) →Copy-paste prompt for Instance 2 →