1Footer documentation
GitHub Pages delivery and repair coverage
Publish real footer HTML and CSS on Pages, connect publishing access and review the bounded cloud adapter’s remaining migration-validation limits.
Last reviewed
Static delivery is available; general automation is unfinished
You can include an HTML/CSS export in your own Pages publishing workflow. A bounded static branch adapter is also deployed for existing authorized GitHub connections, and you can now save Pages publishing access in Integrations. Connected migration, navigation, pause and recovery validation are still in progress. Check the dated public result for your own website before treating delivery as verified.
This is build-time HTML delivery: the published page contains the footer links and CSS. It does not require a visitor-side fetch or Cloudflare proxy. The adapter does not add a dynamic server to GitHub Pages.
Check the repository and public URL
Actions workflows, Jekyll sources, organization repositories, hydrated framework exports and unsupported source layouts need another compatible delivery path. 1Footer will not switch your publisher or disable Jekyll to make a site fit this adapter.
- Use a repository owned by the personal GitHub account connected to your 1Footer workspace, with permission to read and write the publishing branch.
- Configure Pages to deploy from a branch, using its root directory or /docs. The publishing directory must contain .nojekyll and index.html.
- Use an HTTPS website origin that matches the website in 1Footer. The current adapter requires the site at the origin root; a project URL such as account.github.io/project/ is outside its scope.
- Keep the static site within the current limit of 80 HTML files, each no larger than 2 MB.
- Confirm that the public domain already serves the intended repository and has a valid HTTPS certificate. A repository connection does not configure DNS or provision HTTPS for you.
Choose the setup that is available to you
For the cloud workflow, open Integrations, choose GitHub Pages and select your website. Save the personal repository owner’s token with Pages read and Contents read/write access. 1Footer validates the account, encrypts access for that website and discovers the repository itself. Saving access does not change provider source or establish a verified footer. Existing pauses stay in place. The separate Netlify source-access form remains specific to Netlify.
For eligible existing connections, 1Footer can continue supported work through its cloud schedule without a local runner or per-migration AI prompt. Repository discovery can span several checks. Missing write access, ambiguous destinations, branch protection or a provider restriction can leave work pending or needing attention.
- Add the public domain to your existing 1Footer workspace and publish the intended footer. A saved draft is not a publication.
- For your own static publishing workflow, include the current exported HTML and CSS in each eligible page, following the server/build integration guide.
- Apply included and excluded page paths during generation. Republish your pages when the footer content or page rules change.
- Check the actual public pages after the Pages build completes.
What the bounded cloud adapter handles
Intentional pauses and excluded pages must remain without a managed footer. Unrelated website content and a private footer draft must remain unchanged. A healthy existing server, SDK or edge integration is not replaced just because GitHub access was connected.
| Step | Automatic work |
|---|---|
| Discover | Inspect connected owner repositories and confirm the Pages assignment for the website domain. |
| Prepare | Add the published footer HTML and CSS to eligible static pages according to their page rules. |
| Publish | Update the publishing branch only while its expected source revision and website binding still match. |
| Verify | Wait for the matching Pages build and compare public route HTML and stylesheet content with the current publication. |
| Maintain | Schedule later checks and retain progress for publication updates, pauses and supported repository migrations. |
| Recover | Reconcile uncertain writes and remove only tracked, unchanged owned fragments during supported cleanup. |
When the domain moves to another Pages repository
Keep the website, footer publication and page rules in the same 1Footer workspace. Configure the destination repository and its public domain through your normal website migration process, with matching connected write access and valid HTTPS.
1Footer can discover a supported replacement Pages repository for that domain, publish the current footer and verify its public output. It retains the previous installation separately for cleanup of known owned fragments. Destination delivery and old-source retirement have separate results.
Changed owned fragments, uncertain branch writes or revoked original access can prevent cleanup. 1Footer must reconcile those conditions before another write. It must not overwrite a newer source edit or claim that pending cleanup finished.
Check the actual public pages
A saved connection, source commit or successful Pages build is progress. Public HTTP verification establishes the response checked at that time; it does not replace browser navigation and visibility checks.
- Compare link labels, destinations and footer CSS with the latest published footer.
- View the initial page HTML and confirm the footer is usable with JavaScript disabled.
- Open a real included page and an excluded page, then navigate between them.
- Confirm there is one managed footer and that your website’s own legal or navigation footer remains intact.
- Read the latest dated delivery result and any separate original-source cleanup result.