Skyhawk Site Modernization Roadmap

Purpose: This is the living plan for completing the modernization of Skyhawk.org while preserving the historical content that has accumulated over decades.

The site is approaching content maturity. The principal remaining work is no longer creating large amounts of new historical content. It is bringing the presentation, navigation, contribution workflows, privacy controls, and content management structure into a form that can be maintained reliably for years without constant reconstruction.

---

North Star

Modernize incrementally. Design globally. Preserve history.

Skyhawk.org will not be rewritten merely because portions of the existing HTML are old. Content that works, displays correctly, and remains maintainable will be preserved. Modernization effort will be concentrated where it improves usability, maintainability, privacy, contribution workflows, or long-term reliability.

The objective is a website that eventually reaches a stable state where normal Drupal security and compatibility maintenance can occur without repeatedly redesigning the site or rediscovering how custom pieces work.

Operating Rules for AI Agents and Maintainers

READ THIS BEFORE CONTINUING SITE MODERNIZATION WORK.

This section controls how work on the Skyhawk site is to proceed. Its purpose
is continuity: understand the current premise, preserve completed work, move
forward linearly, and prevent a new AI session or maintainer from repeating
work that has already been completed.

1. This is a working relationship, not a friendship exercise.
   Concentrate on the site, the evidence, and the task at hand.
2. Understand the premise before expanding the work.
   Discuss narrowly first. Ask questions when necessary to understand the
   premise. Do not expand scope, propose additional solutions, or infer new
   goals until explicitly requested.
3. Do not create side projects.
   Work on the current problem and current phase. An interesting adjacent
   problem is not authorization to pursue it.
4. Use the word "hero" accurately.
   Reserve it for a person who actually did something heroic. Do not use it
   as a generic label for banners, images, page sections, layouts, or other
   design elements.
5. Respect requests for limited answers.
   When a Yes/No answer is requested, answer Yes or No. Otherwise ask the
   necessary question or state the relevant limitation without broadening the
   discussion.
6. Ask before writing code.
   Discussion, diagnosis, and agreement come first. Do not produce a single
   letter of executable code until coding has been authorized.
7. Once authorized, code in one complete working block at a time.
   Make that block as expansive as necessary to perform the agreed step,
   including reasonable pre-flight checks, backups, verification, and
   rollback protection. Then stop and wait for its actual output before
   writing the next code block.
8. There is one established two-block exception.
   When an A2-side audit or other large operation creates a timestamped report
   that must be transferred to the local Windows computer, the A2 block and
   its local PowerShell transfer block are one logical workflow. The transfer
   block may therefore be supplied with the A2 block when needed.
9. For those report workflows, exit A2 correctly.
   The A2-side code should finish its work and verification first. When
   practical, the final command of the outer SSH shell workflow is
   exit. If the work is enclosed in a Bash subshell
   ( ... ), the SSH exit must occur after the
   closing parenthesis, not inside it.
10. The local report-transfer block has a standard job.
    From the local Windows PowerShell prompt it locates the specific/newest
    timestamped report on A2, downloads it to
    C:\Users\genea\Downloads\Website, verifies that the local
    file exists and is nonzero, and reconnects with
    ssh -a A2.
11. Proceed linearly and avoid retrograde motion.
    Do not redo, replace, reopen, or redesign completed work merely because a
    different approach is possible. Return to completed work only when new
    evidence demonstrates a defect, dependency, or conflict that actually
    requires it.
12. Read this roadmap before acting.
    Check the current working phase, completed work, architectural decisions,
    and decision log before proposing or executing another step. Do not rely
    solely on conversational memory.
13. Preserve established architecture.
    The canonical global CSS, legacy compatibility layer, reusable squadron
    architecture, and other decisions recorded on this roadmap are the
    starting state. Do not unknowingly recreate retired CSS, retired themes,
    or superseded implementations.
14. VMA-131 is the current modernization prototype.
    Complete and validate the present VMA-131 phase before using the model to
    modernize additional squadron pages. Lessons from VMA-131 should become
    reusable architecture rather than a growing collection of page-specific
    patches.
15. Separate diagnosis from modification.
    When the cause of a problem is uncertain, inspect first. Prefer a focused
    read-only audit over speculative changes. Use the audit result to choose
    the next modification.
16. Back up before consequential changes.
    Preserve the relevant current files, configuration, or node content before
    modifying them. Verification should be part of the same authorized step.
17. Downloaded scripts are ZIP files.
    When scripts or script bundles are supplied as downloadable artifacts,
    package them as ZIP files rather than loose plain-text script downloads.
18. Record significant decisions here.
    After an architectural decision, verified milestone, change of working
    phase, or important workflow discovery, update this roadmap so continuity
    survives changes of conversation, AI model, maintainer, or memory.
19. Do not mistake motion for progress.
    The objective is a finished, maintainable Skyhawk site. Prefer fewer,
    reusable mechanisms over accumulating exceptions, patches, duplicate CSS,
    or work that creates another maintenance obligation.

Continuity rule:
A future AI agent or maintainer should be able to read this page, determine
what has already been accomplished, identify the current working phase, and
continue forward without repeating the archaeological expedition that produced
the present architecture.

Guiding Principles

• Drupal owns the content. Important operational information should live in Drupal entities, fields, taxonomy, Views, Webforms, and configuration wherever practical.
• Custom code is minimized. Drupal core and established contributed functionality are preferred over purpose-built modules where configuration can accomplish the same job reliably.
• Skyhawk-specific code lives outside contributed projects. No permanent Skyhawk customization should be stored inside Bootstrap Barrio or another contributed theme/module where an update can overwrite it.
• One canonical global CSS source. Site-wide Skyhawk CSS is maintained under the custom skyhawk_site_fixes module rather than under a contributed theme.
• Global CSS should be conservative. Site-wide rules provide the shell, typography baseline, responsive safety, navigation, and Drupal integration. They should not dictate the internal design of every content page.
• Legacy content gets compatibility, not punishment. Old HTML that still works should not be rebuilt merely for ideological purity. Legacy-specific CSS should be isolated to content that genuinely needs it.
• Modern content uses reusable patterns. New squadron pages, memorials, directories, and other modernized sections should use common Drupal structures and reusable design components.
• Privacy by design. Personal contact information should not need to be published simply to permit communication. Drupal routing and controlled forms should replace exposed email addresses wherever practical.
• Human workload matters. SDOs, editors, contributors, members, and administrators should enter only information that the system cannot determine automatically.
• Back up before mutation. Significant migrations and structural changes require a recoverable backup and verification step.
• One controlled change at a time. Changes should be broad enough to accomplish a meaningful task but verified before the next structural change begins.

Current Architecture Decisions

Theme

The live site uses Bootstrap Barrio. The abandoned skyhawk_barrio project has been retired from the live web tree and Drupal configuration.

Skyhawk CSS

The canonical site stylesheet is:

web/modules/custom/skyhawk_site_fixes/css/skyhawk-global.css

Custom Skyhawk CSS previously scattered through contributed Bootstrap Barrio, the abandoned custom Barrio theme, and older site-fix files has been consolidated into this location.

The next CSS objective is to separate genuinely global behavior from legacy compatibility behavior and reusable modern page-family behavior.

Contact and Privacy

The public contact workflow uses Drupal Webform. Public email addresses are being removed where forms and private routing can perform the same function.

Contact-form notification routing remains in controlled test mode while SDO assignments are reviewed.

SDO Directory

Skyhawk units and SDO assignments are maintained using Drupal taxonomy and Drupal user references rather than a custom routing module.

Super SDO reviewers can maintain the directory through Drupal. Revision history records changes.

Modernization Classes

The site-wide census will classify existing content into practical groups. These categories may be refined after the census.

Class 1: Modern / Native Drupal

Content already using maintainable Drupal structures and responsive presentation. These pages normally require little or no structural work.

Class 2: Legacy but Harmless

Older HTML that remains readable, responsive enough, and operational. These pages should generally be left alone except for safe global improvements.

Class 3: Legacy Layout-Dependent

Pages relying on fixed-width tables, extensive inline formatting, obsolete markup, or other structures requiring compatibility CSS. These pages receive a deliberate legacy compatibility layer rather than uncontrolled global exceptions.

Class 4: Modernization Candidates

Content whose usefulness justifies conversion into reusable modern Drupal presentation and management patterns. Squadron pages are the first major family in this category.

Reusable Page Families

The census will determine the final list. Expected families currently include:

• Squadron / unit pages
• Memorial and remembrance content
• Journal presentation
• Aircraft / BuNo galleries
• Research and data-heavy Views
• Reunion content
• Association information and administration

A page family should receive dedicated CSS or Drupal structure only when multiple pages genuinely share that design or behavior. We will not create a permanent stylesheet for every individual node.

Squadron Modernization: Phase 1

VMA-131 Diamondbacks is the prototype for the modern squadron-page model.

The objective is not to create a unique VMA-131 exception. The objective is to learn from VMA-131 and produce a reusable squadron structure that can gradually be applied to other units.

The emerging squadron structure includes:

• Unit identity / hero presentation
• Key unit facts
• Section navigation
• History
• People
• Stories
• Aircraft
• Photos
• Remembrance
• Research and source material
• Contribution workflow
• Access to preserved legacy records where appropriate

Members should be able to contribute photographs through the established contribution workflow. Stories, corrections, questions, and historical information should use the Association contact workflow with the relevant unit preselected where practical.

Verified Squadron-Page Foundation

Status: Verified on VMA-131.

The first reusable modern squadron-page implementation has been visually verified in Drupal/Barrio.

• Page-wide horizontal scrolling has been eliminated.
• Squadron content now remains inside the Drupal/Barrio content boundary.
• Large headings wrap within the available content area.
• The five-unit facts row remains contained.
• Squadron navigation remains inside the page and wraps rather than forcing horizontal scrolling.
• The preserved historical VMA-131 / VMA-132 record remains available inside the modern presentation.

Architecture decision: reusable squadron layout must use parent-relative sizing such as width:100% with appropriate max-width constraints. Viewport-relative container widths such as 92vw are not to be used inside Drupal/Barrio content containers.

The reusable squadron stylesheet is:

web/modules/custom/skyhawk_site_fixes/css/squadron.css

VMA-131 remains the first implementation and testing ground. Future squadron modernization should reuse this family structure rather than create independent node-specific CSS.

CSS Architecture Goal

The intended long-term structure is conceptual rather than filename-driven:

1. Global foundation: safe site-wide layout, responsive media, navigation, typography, Drupal shell, and administration.
2. Legacy compatibility: targeted rules for old HTML structures that genuinely need intervention.
3. Reusable modern families: styling shared by modernized content families such as squadron pages.

The exact file organization will be determined after the site-wide census. We will not create unnecessary stylesheet fragmentation merely for organizational appearance.

Site-Wide Census

Status: Complete. The Drupal content/layout census was generated on August 16, 2026.

This census is intended to guide gradual modernization. The classifications are structural indicators, not judgments about historical importance or editorial quality.

Site Totals

• Total Drupal nodes: 46,995
• Published: 46,993
• Unpublished: 2
• Nodes with body content: 410

Structural Classification

Class	Nodes	Meaning
Modern / Native Drupal	46,642	Structurally suitable for modern Drupal presentation or already using maintainable markup.
Legacy but Harmless	89	Older markup exists, but the content does not currently show strong layout dependency.
Legacy Layout-Dependent	48	Presentation relies significantly on tables, inline styles, fixed dimensions, old attributes, or similar compatibility behavior.
Modernization Candidate	216	Structurally complex content in a reusable or high-value family where gradual Drupal modernization is likely to provide meaningful benefit.

Structural Features

• Nodes containing HTML tables: 315
• Nodes containing inline style attributes: 233
• Nodes containing fixed pixel widths: 24
• Nodes containing explicit minimum widths: 1
• Nodes containing nowrap behavior: 2
• Nodes containing legacy HTML tags: 115
• Nodes containing legacy presentation attributes: 316
• Nodes embedding stylesheet link tags: 1
• Nodes embedding style blocks: 10
• Nodes already containing Bootstrap grid structure: 0
• Nodes containing recognizable Skyhawk custom classes: 2
• Nodes showing a modern custom-page wrapper: 1
• Nodes with more than 50,000 body characters: 96
• Nodes containing more than 15 images: 53

Detected Content Families

These groupings identify likely reusable modernization patterns. They are working categories and may be refined as representative pages are reviewed.

Family	Nodes
General Content	45,956
Journal	644
Squadron / Unit	261
Aircraft / BuNo / Gallery	114
Association / Administration	13
Research / Historical Data	4
Reunion	3

Canonical CSS Findings

• Canonical stylesheet: web/modules/custom/skyhawk_site_fixes/css/skyhawk-global.css
• Size: 1,143 lines / 29,304 bytes
• !important declarations: 328
• min-width rules: 9
• overflow-x:auto rules: 3
• Broad non-frontpage body-field horizontal scrolling: Detected and scheduled for architectural review.

Leading Modernization Candidates

This is not an automatic work queue. It is a short list of structurally significant pages that may provide reusable lessons.

Node	Family	Type	Page	Score
144	Squadron / Unit	article_unit	VMA-121	80
354	Research / Historical Data	article	A-4 Skyhawk Production History	80
417	Squadron / Unit	article_unit	Vietnam Carrier Depolyment Timeline	79
122	Squadron / Unit	article_unit	VA-192	75
106	Squadron / Unit	article_unit	VA-106	74
120	Squadron / Unit	article_unit	VA-164	74
90	Squadron / Unit	article_unit	VA-43	70
92	Squadron / Unit	article_unit	VA-45 / VF-45	70
5	Squadron / Unit	article_unit	VA-15	69
114	Squadron / Unit	article_unit	VA-144	67
147	Squadron / Unit	article_unit	VMA-131 and VMA-132	67
119	Squadron / Unit	article_unit	VA-163	66
124	Squadron / Unit	article_unit	VA-212	64
10	Research / Historical Data	page	A-4 Skyhawk Production	63
93	Squadron / Unit	article_unit	VA-46	63
104	Squadron / Unit	article_unit	VA-94	63
88	Squadron / Unit	article_unit	VA-34	62
158	Squadron / Unit	article_unit	VMA-225	61
162	Squadron / Unit	article_unit	VMA-311	61
72	Squadron / Unit	article_unit	VA-12	60

What the Census Means

The site should not be converted wholesale. The census supports a gradual model:

1. Leave modern/native and harmless legacy content alone unless there is a practical reason to change it.
2. Move genuinely legacy-dependent presentation rules out of broad global scope and into targeted compatibility behavior.
3. Use VMA-131 as the first reusable squadron modernization model.
4. Apply lessons from representative pages to page families rather than creating node-by-node exceptions.
5. Continue recording architecture decisions and migration progress on this roadmap.

Census Reports

Detailed TXT and JSON census files are retained in the server modernization workspace for future analysis and comparison.

Migration Method

1. Inventory first.
2. Identify common structure.
3. Define reusable Drupal/content patterns.
4. Correct global CSS where a global correction is appropriate.
5. Isolate legacy compatibility behavior.
6. Modernize one representative page or family.
7. Verify desktop, tablet, and phone behavior.
8. Document the result here.
9. Repeat gradually for the next useful content family.

What We Are Trying to Avoid

• Customizations hidden inside contributed themes.
• Multiple competing global stylesheets.
• Page-by-page CSS exceptions when a reusable rule is possible.
• Large custom modules when Drupal configuration can do the job.
• Publishing personal email addresses simply to make routing work.
• Rebuilding functioning historical content solely because its HTML is old.
• Changing multiple unrelated systems before verifying the previous change.
• Undocumented one-off fixes that future maintainers cannot understand.

Definition of “Done”

Skyhawk.org should eventually reach a state where:

• Historical content is preserved and accessible.
• New contributions have clear Drupal-managed workflows.
• Routine editors can maintain content without editing raw HTML.
• Personal information is protected appropriately.
• Global CSS is stable and predictable.
• Legacy compatibility rules are contained.
• Modern page families are reusable.
• Skyhawk customization is isolated from contributed-project updates.
• Backups and architecture are understandable to the next maintainer.
• Drupal upgrades can be treated primarily as maintenance rather than redesign projects.

Current Working Phase

Phase: VMA-131 reusable squadron-page completion.

The site-wide census is complete. Global and legacy CSS have been separated. The reusable squadron-page width architecture has been established and visually verified on VMA-131. Current work should continue linearly on VMA-131 presentation and content-management behavior before applying the model to additional squadron pages.

Decision Log

• 2026-08-16: Established explicit operating rules for AI agents and maintainers so modernization work remains linear, completed work is not duplicated, coding requires authorization, report-transfer workflow is preserved, and significant decisions remain documented across AI sessions and maintainers.
• 2026-08-16: Visually verified the VMA-131 reusable squadron-page foundation. Page-wide horizontal scrolling is eliminated, content remains within the Drupal/Barrio container, and parent-relative sizing is now the standard for future squadron modernization.
• 2026-08-16: Established VMA-131 as the first reusable modern squadron-page implementation. Squadron CSS now lives in the Skyhawk custom module, is attached through Drupal, and uses parent-relative layout widths instead of viewport-relative container widths.
• 2026-08-16: Began separating global responsive CSS from legacy compatibility behavior. The census-derived legacy compatibility population now preserves legacy layout behavior only where it is structurally justified.
• 2026-08-16: Completed the first site-wide Drupal content/layout census and recorded the structural classifications and reusable content families in this roadmap.
• 2026-08-16: Retired the abandoned skyhawk_barrio theme from the live site and configuration.
• 2026-08-16: Consolidated Skyhawk global CSS under skyhawk_site_fixes.
• 2026-08-16: Agreed that modernization will proceed incrementally, beginning with VMA-131, while architecture decisions are made from site-wide evidence.
• 2026-08-16: Established this Drupal page as the living modernization roadmap and decision record.

Next Action

Run the read-only Drupal site census, classify the content, identify common structures and high-risk legacy patterns, and add the resulting summary to this page before restructuring the global CSS further.