sendMessage, massmessage and sysmessage are POSTed to directly, bypassing
admin.php's central csrf_verify(). Add csrf_verify() (after the admin access
check, via the shared GameEngine/Admin/csrf.php) and csrf_field() in their
forms (Newmessage.tpl, massmessage.tpl, sysmessage.tpl; the mass/sys templates
have both a prepare and an execute form).
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The post-delete admin-log block referenced variables that were never defined
($admid/$adminID/$medalid/$uid), so on PHP 8.1+ (mysqli throws on error) the
malformed INSERT raised an uncaught mysqli_sql_exception → HTTP 500 after the
medal was already deleted. Use the correct ids ($admid from session, $uid from
POST), look up the target player's username (escaped), and redirect to the
sanitized $uid.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
editAli, delAli, medals, delallymedal, delallymedalbyaid, delallymedalbyweek
and deletemedalbyweek are POSTed to directly, bypassing admin.php's central
csrf_verify(). Add csrf_verify() (after the admin access check, via the shared
GameEngine/Admin/csrf.php) and csrf_field() in their forms (playermedals.tpl,
editAli.tpl, delAli.tpl, delmedal.tpl, allymedals.tpl, delallymedal.tpl).
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The alliance/editAli/delAli pages are linked all over the admin panel
(?p=alliance&aid=, ?p=editAli, ?p=delAli) but were never in
admin_validated_page()'s whitelist, so admin.php fell back to search.tpl and
the pages never showed. Add them to the whitelist plus switch cases for the
breadcrumb (the templates resolve $aid/$alidata themselves from $_GET, like
editSitter/editPassword).
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
editVillageOwner, renameVillage, editBuildings and editResources are POSTed
to directly, bypassing admin.php's central csrf_verify(). Add csrf_verify()
(after the admin access check, via the shared GameEngine/Admin/csrf.php) and
csrf_field() in their forms (editVillage.tpl, village.tpl, editResources.tpl).
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
addTroops and addABTroops are POSTed to directly, bypassing admin.php's
central csrf_verify(). Add csrf_verify() (after the admin access check, via
the shared GameEngine/Admin/csrf.php) and csrf_field() in their forms.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
On the rally point incoming tab, the number of an incoming unit type is never
revealed: it is always shown as a "?". When that stack is smaller than the
defender's rally point (gid 16) level, the "?" is rendered in solid black
bold, matching original Travian behaviour (e.g. rally point level 20 and an
incoming 19 praetorians shows a bold "?"). The eyesight artifact still reveals
which troop types are present (0 for the absent ones). Scope: village
attacks/raids only.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Extract the per-branch defender target resolution and battle-environment
setup into two private helpers: resolveVillageTarget() and
resolveOasisTarget(). Each returns the target owner (tribe/alliance), map
info, conquest flag and the battle parameters (wall, armory/blacksmith
tech, residence, siege masonry); the village helper also returns the
evasion inputs. Both are read-only (no DB writes).
The foreach body keeps handleEvasion(), buildDefenderUnits() and
buildAttackerUnits() as explicit, ordered calls, so the village and oasis
branches are now symmetric orchestration.
Behaviour-preserving. The building/tech reads now run inside the helper
before handleEvasion(); they read buildings and technology only (never the
troops handleEvasion() may move), so the result is unchanged. A few
dead locals are dropped (playerunit, wallgid, w; the redundant
DefenderUnit/def_ab re-inits).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>