Repository navigation
Conversation
Smoke-test the tag the run actually pushed. It tested :latest, which metadata-action only emits on the default branch, so a tag-triggered or manual run would have failed against an image that does not exist. Also assert HUGO_CACHEDIR, working directory and uid, since all three are set in the Dockerfile specifically to override upstream defaults and nothing else would catch a regression. Bump build-push-action to v6 and add setup-buildx-action, matching vfb-status and vfbquery, which already publish into the virtualflybrain namespace with the same org secrets. Make the header say plainly that the image does not exist until this file is moved into .github/workflows/, and correct the description of Robbie1977/docsy-builder: it is a copy of docsy-example rather than a fork, and the Dockerfile on the branch that built the live image is floryn90/hugo:ext-alpine, not klakegg. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01X1AuLA5tHPwpD7Hp5utPkS
Feature/vfb nova theme
Hugo takes an flock on .hugo_build.lock at startup and waits for it indefinitely with no message, no error and no timeout. The observed symptom is a build that copies the static files and then stops: 66 files and 16 MB in the staging tree, a sleeping process at near-zero CPU, low RSS, and no further output. Reproduced exactly by holding the lock against an otherwise healthy build. The workspace is on NFS, where a lock left by an uncleanly killed build outlives the process that took it, so this recurs on its own. The lock also guards against a concurrent second build, which cannot happen here: the container is the only builder and Rancher runs it start_once. It protects nothing and fails invisibly. Clear any stale lock file as well, so nothing is left lying around now that Hugo no longer manages it. Verified: with the lock held, the build now completes rather than hanging. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01X1AuLA5tHPwpD7Hp5utPkS
…data A reviewer asked our chat assistant how many neurons are in the fly brain and it could not answer. The resolution bug is being fixed separately; this addresses the harder half, which is that the question has no single answer and we had nowhere authoritative to point. Two artefacts, one source of truth: - content/en/docs/Concepts/neuron-counts.md — the article. Why the question is under-specified, what each connectome VFB holds actually counted, what dense versus sparse reconstruction means, what flood-filling and proofreading still miss, and what people quoted before connectomics existed. - static/data/fly-neuron-counts.json — the same facts machine-readable, so VFBchat and the MCP can read the figures rather than each hard-coding them. Published at /data/fly-neuron-counts.json. Every figure was checked against its primary paper; two that could not be retrieved from the original are flagged verified:false rather than quietly included. Findings worth flagging to curators: - "~100,000 neurons" has no traceable primary measurement. It appears uncited in the papers that popularised it. - The three real non-connectome measurements disagree by 2.5x, two of them using the same technique. - FlyWire's own count moved 127,978 to 139,255 between preprint and Nature. A connectome count is a property of a release, not of a fly. - Nern et al. traced the optic lobe from part of the male CNS volume, so those two datasets are the same animal and must never be summed. - VFB DatasetImages counts are NOT neuron counts: the ratio to the published figure ranges 0.92 to 2.78 across our five datasets and does not run in a consistent direction. Also note get_term_info reports count:-1 for DatasetImages, which is the unavailable sentinel and not zero. Two knowledge-base curation items are recorded in the JSON: Bates2025 still cites only the preprint DOI (the Nature version of record is now PMID 42259917) in both Publications and Meta.Description, and Berg2025's Technique reads SBFSEM where the paper describes eFIB-SEM. Nern2024 needs no citation fix — its Publications field already carries the 2025 version of record; only the dataset id and label strings still read 2024. The data file is in static/ rather than data/ so it publishes at a stable URL with no change to hugo.toml. Hugo is not available in the environment this was prepared in, so nothing here alters the build configuration. Co-Authored-By: Claude Opus 5 <[email protected]>
…undamentals Add a verified reference on Drosophila neuron counts, as page and as data
static/data/fly-neuron-counts.json could never be served. /data/ on this site is routed the same way as /reports/, treating the path segment as a dataset id, so a static file there is unreachable no matter how the site is built. Verified: an existing page under a working namespace (/docs/concepts/nblast/) returns 200, while /data/fly-neuron-counts.json returns 404. That also made the article's intro line false — it told readers a machine-readable version was published at a URL that cannot exist. Removed. No functionality is lost. The operative copy of this data ships inside the VFBchat image at config/fly-neuron-counts.json and is read in process, precisely so a figure never depends on a fetch succeeding. There is now no published mirror and no drift risk between two copies: curators edit the repo file. The article page itself is unaffected and stays — /docs/concepts/ is a normal content namespace, and it is the URL VFBchat's reviewed-docs index points at. Co-Authored-By: Claude Opus 5 <[email protected]>
The previous commit's git rm was refused because the file had an uncommitted local edit, so it was committed as modified rather than removed. Deleted here. Co-Authored-By: Claude Opus 5 <[email protected]>
…ta-mirror Drop the data mirror: /data/ is a routed namespace, not free space
… build 0.16x has never finished a build of the full term corpus. Two runs on two machines each sat 17h+ with one thread in uninterruptible sleep on the 650k-file vfb/ directory, 500MB RSS and no page written, while the live term pages still carry generator: Hugo 0.122.0 from 2026-08-05. The site is metadata-bound, not CPU- or memory-bound: the NFS volume serves readdir+stat at 253/s. Hugo's per-page filesystem cost rose from 3.06 to 4.03 stats at v0.123.0 and is flat thereafter, which is ~49 min of extra I/O across 763k pages. Installs the release tarball on Debian: ghcr.io has no v0.122.0, and the extended binary is glibc-linked so Alpine is not a safe host. HUGO_VERSION is an ARG so raising it again is a one-line change once the corpus is sharded or the volume's btrfs metadata is pinned to SSD.
Pin the builder to Hugo 0.122.0, the last version that completes this build
Term pages generated at version 6 and earlier call Docsy's alert shortcode. vfb-nova does not ship it, and a missing shortcode template is a hard build error, so a single superseded file anywhere in ~763k pages aborts the run -- twice this week, at 93 and 38 minutes each. Same signature and rendering as Docsy's, plus .alert rules in compat.css using the theme's tokens so they are styled rather than bare. pageinfo is included pre-emptively: it is the other Docsy shortcode those pages are likely to use, and finding out the slow way costs another build.
process_term() removed only version-1 after writing a page, so a term absent from a single run's ID list kept its older file forever. The corpus still held _v6 pages with version at 9, in blog/ontologies/* and blog/releases/datasets alike, including one named _v6.md from a term with an empty short_form. Orphans are live pages: they are walked and parsed on every build, they can collide on URL with the current version, and ones predating the move off Docsy call shortcodes the theme no longer ships -- which aborts the build outright. Prunes once per group with a single directory scan instead of a stat per term per version. The per-term form would cost millions of extra syscalls across ~763k terms, and this corpus lives on an NFS volume serving a few hundred metadata ops per second. Net effect is one fewer stat per term than before.
The staged build has never completed. Both /src and /tmp are NFS mounts of the same Synology volume, so staging turns one write pass into write 763k, enumerate 763k staged, enumerate 763k live, read 763k, write 763k -- about four times the metadata work, against the one resource that is already the bottleneck. That volume serves readdir+stat at 253/s, because 187 GiB of btrfs metadata sits behind 128 MiB of page cache on a 6 GB appliance. On the 2026-08-14 run: Hugo 4h41m, then 75 minutes for the staging find alone, with the live find and the copy still ahead. The in-place build published every version of this site up to 2026-08-05. Keeps --noBuildLock and the stale-lock removal. The page-count gate goes with the staging tree; the 'published N pages' line the Jenkins step keys on now comes from Hugo's own summary rather than a find that costs 75 minutes. Accepted trade-off: during the build the site serves a mix of old and new pages. Nothing is deleted, so old fingerprinted assets remain on disk and old pages keep resolving until overwritten. Restore the staged version from git history once the corpus is sharded and the volume's metadata is cached.
Publish in place again, not via a staging copy
…d-prune Stop superseded term pages from aborting the build
Five layouts wrap their content in .page - every blog post, news item, release page, generated ontology term page, taxonomy list and tag list - but the class had no rule. Only .hero and .doc reserved space for the fixed 68px nav, so on everything else the breadcrumb and title rendered underneath the header. The hero figures counted pages in this site rather than data in the knowledge base. The largest tile read "indexed anatomy terms" but was .RegularPagesRecursive over /blog/ontologies: the generated term corpus across all 22 integrated ontologies, mostly NCBITaxon, and not a count of anatomy. It read as 763,268 against a real figure of 28,772. Take the figures from the content report instead. It is regenerated against pdb.virtualflybrain.org after every data release and injected into /blog/releases by the reporting pipeline, so the hero now tracks the data. The report is not in this repository, so a checkout without it falls back to the site-shape tiles rather than printing a constant.
…atomy Anatomical hero: real fly body with VFB CNS meshes
The Data section described the smallest datatypes best. LM was a single sentence and one FlyLight child page, though light microscopy is the largest body of data on VFB by number of source studies - around 120 of the 210 datasets. Connectivity, which is the reason most users arrive, had no page at all. Nothing carried a figure, so a reader could not tell whether a datatype meant ten images or six hundred thousand. Adds a vfb-figures shortcode over the same content-report partial the hero uses, so each page opens with the counts for its own modality and they track the data release rather than going stale in prose. - Data/_index: what integration means here, a routing table over the datatypes, provenance and citation, and the licence position. - Data/LM: the distinction between whole-pattern and single-neuron images, a collection table to match the EM one, how expression annotations are made and what they do not assert, and five routes in. - Data/connectivity (new): what an edge is and is not, the four kinds VFB holds, the eight contributing connectomes, why hb and fafb are excluded by default, and direction semantics stated explicitly. - Data/scRNAseq: all 24 datasets rendered as a table with cluster and gene counts, replacing a link to a TSV on GitHub. - Data/EM: figures, and a pointer to the new connectivity page. Publications are cited only where the citation was read back from the knowledge base; elsewhere the table links the dataset's own VFB page rather than carrying a reference that could drift.
…ound Apache-2.0 requires the notice to travel with the work. The flybody attribution was only an HTML comment in cover.html and a field in hero-geometry.json, neither of which a reader sees. It now sits in the footer legal row, sized down so it reads as a credit rather than navigation. Body silhouette opacity goes 0.22/0.05 -> 0.32/0.11 with a slightly larger point radius. At the original values it read as scattered dust rather than a fly, particularly on the light theme where the body colour is a muted blue-grey against near-white. Limbs stay dimmer than the torso so the outline still sits behind the CNS, which remains the subject. This helps but does not solve it: the silhouette is still diffuse, and the news card covers much of the body area on wide viewports. Making the fly actually legible is a shape and composition problem, not a brightness one.
…content-report-stats Reserve nav space on .page, and rebuild the Data section on the content report
FlyBase's March 2026 update restored NHGRI funding for the US-based teams; the foreign subaward supporting the Cambridge curation team was not restored. Both the home page notice and the news article still described the mid-2025 position, and the news article still pointed at a two-route arrangement that no longer exists - a European crowdfunding page and a US fee system 'to be set up soon'. There is now one annual contribution, open to labs anywhere, at a suggested GBP/EUR 200 or USD 250 per researcher. The old crowdfunding URL on philanthropy.cam.ac.uk now redirects to a login page, so it is dropped in favour of the Cambridge online store and the purchase-order address, both taken from the Contribute to FlyBase wiki page. The news article's date moves to the date of the FlyBase update rather than today, so the post is not passed off as newer than the news it carries; an alias keeps the old /blog/2025/06/11/ URL working. The home page notice was a Docsy panel hard-styled inline - #fe0 background, black border, red heading - which content-hooks.css then had to override. In light mode the heading came out as --signal #ffe406 on white and could not be read. It is now the theme's own .notice band, so the override shrinks to placement and both colour schemes work.
…-and-credit Credit the hero body model, and lift the silhouette out of the background
…h-2026 Update the FlyBase funding appeal to the March 2026 position
The notice stated that VFB depends on FlyBase for much of what it does. That misstates the position. VFB maintains the Drosophila anatomy, cell type and developmental ontologies itself; they are hosted on FlyBase's GitHub but edited by VFB. FlyBase curates the genetic reagents and literature. Corrected to describe that relationship accurately and to confirm that VFB's own funding is unaffected.
Search Console reports six pages under "Video isn't on a watch page". Comparing them against pages Google did index shows the verdict does not follow from page structure: two news posts built from the same shortcode, within 4% of each other on byte size, word count and iframe depth, split one indexed and one not. Google's stock advice to move the video higher in the HTML has nothing to act on here. What the site does lack is any description of its videos. There is no VideoObject markup anywhere -- head.html emits WebSite/SearchAction and nothing else -- so Google infers what each embed is from layout alone, and does so inconsistently. data/videos.json now carries name, description, thumbnailUrl, uploadDate, duration and channel for all 21 embedded videos, and the shortcode emits schema.org VideoObject for any ID it finds there. An ID with no entry degrades to a plain embed rather than half-populated markup, which Search Console reports as an error rather than ignoring. scripts/fetch_video_metadata.py regenerates the data from YouTube. It prefers JPEG thumbnails: YouTube now serves WebP by default, and Google accepts only .jpg, .png and .gif for a video thumbnail, so a WebP URL would invalidate the markup silently. Separately, and the reason the reported URLs look mangled: interpolating the query string into the iframe's src="" let Go's template escaper treat it as an untrusted URL fragment, so ?autoplay=1&mute=1 reached the browser as ?autoplay%3d1%26mute%3d1 -- one parameter with that literal name, which YouTube discards. Every autoplay="true" embed on the site has been inert. Building the URL as one string and marking it safeURL fixes it. Note this makes autoplay start working, including on the two-video BANC post. main="true" marks a page whose reason for existing is the video; it adds mainEntityOfPage and drops lazy loading so the player is present at real dimensions on first render. Set on the two Lo lab "Video:" posts only. Deliberately not set on /docs/overview/ or /about/geppetto/, where the video is supporting material and Google is right that they are not watch pages.
Add VideoObject markup and fix escaped autoplay params
workshop.virtualflybrain.org carries the current, runnable version of
material this site holds in two states. The 2021 "Hacking the connectome"
pages it supersedes outright; the API reference and tutorials remain
correct but have no worked example against live data. Neither said so.
A {{< workshop >}} shortcode puts the pointer in one place rather than in
29 hand-written alert blocks, so the wording is edited once when the
workshop moves, is renamed or gains a session. Two tones: "superseded"
for the 2021 pages, which names the session that replaces each one, and
the default for reference pages, which offers the worked example without
implying the page is stale. `url` takes a path, not a full URL -- the
host lives in the template.
Mapping follows the session structure, which matches the 2021 material
almost one to one: Discovery -> session 1, Mapping -> session 2
(bridging & identity), Visualisation -> 3, Connectomics -> 4, NBLAST ->
5, tools -> setup. Reference pages point at whichever session exercises
them; SOLR, KB, Owlery and PDB get the generic pointer because no
session teaches them directly.
Styling is a dedicated .workshop-note rather than the Docsy .alert shim.
That shim exists to keep superseded generated term pages rendering and
should not acquire first-class content as a dependent.
Search now reaches the workshop as well. The workshop's own palette has
pulled this site's index.json since it launched; app.js never gained the
other half. Ported from its search.js: data-remote-index/base/label,
a capped group of remote hits below this site's title matches, and a
re-render when the index lands so the first query does not need a second
keystroke. Both sites already serve index.json with
Access-Control-Allow-Origin: *, so no server change is needed, and a
failed fetch is silent -- this site's own results must never depend on
another host being up.
The static term pages at /term/<slug>/ carry sitemap_exclude: true because Hugo's own sitemap.xml has no pagination -- a sharded sitemap-terms.xml index (sitemap1.xml..) is written separately for them, advertised in robots.txt. That shard writer now lives in vfbterms.py itself rather than an undocumented external step: after every group is processed it emits sitemap1.xml.. plus the sitemap-terms.xml index, listing both the static page and the /reports/<id> viewer URL (now indexable per the geppetto-vfb SEO fix) for every term. Output directory is an optional 3rd CLI argument -- point it at wherever Jenkins publishes static files from (e.g. the Hugo public/ directory) to wire it into the live site; omit it and nothing changes from today.
Add /reports/<id> viewer URLs to the term sitemap alongside static pages
Point API and workshop docs at the self-led learning sessions, and put the workshop in search
Updated the workshop description and removed the conference attendance paragraph.
Every page advertised the site logo as og:image and twitter:image, so a term pasted into Slack, Bluesky or Teams previewed as the VFB logo rather than the neuron or region it points at. Term pages already carry their thumbnails as raw <img> in the body, so the first one is reused as the preview image, read from .RawContent. A front-matter field would have been tidier but means regenerating the whole term corpus -- a version bump refetches ~768k pages from VFBquery -- for a value already sitting in the page. Pages with no thumbnail, and every non-term page, keep the logo. Thumbnails are 674x640, comfortably over the 300x157 floor for a summary_large_image card.
Use a term's own thumbnail as its link-preview image
The term-page thumbnail rule from #509 becomes a general resolution chain in partials/preview-image.html, first hit wins: 1. `images:` in front matter -- the explicit override, Hugo's own convention, for any page where the automatic pick is wrong. 2. The page's video: `videos:` in front matter, else the first {{< youtube >}} in the body (main="true" preferred). Thumbnail from data/videos.json, the record the VideoObject markup already uses, else YouTube's always-present hqdefault.jpg for an ID it has not caught up with. 3. The first image in the body, raw <img> or markdown, so hand-authored docs get a preview too, not only generated term pages. 4. The site logo. A video outranks an inline image deliberately: a page with a video is usually about the video, and `images:` covers the exception. Verified against Hugo 0.122.0 across eleven cases: list and string overrides beating both a body image and a video; `videos:` known and unknown to the data file; shortcode main="true" beating an earlier embed, first-embed and positional-ID forms; term raw <img>; markdown image; and the logo fallback.
…solution Pick each page's link-preview image, with a front-matter override
Query documentation
The Term Info query panel is gaining a per-row help link. The Queries
Reference already has a {#QueryName} anchor per query; this adds the
targets the graph and Circuit Browser rows need — {#location} and
{#classification} on the Term Context page, and
{#add-a-neuron-from-term-info} on the Circuit Browser page — and tells
readers of the Queries Reference what the gold ? does.
The in-app help button on every tab window links to a Website Features page; these two tabs had none.
Add pages and anchors for the in-app help buttons
The download and upload dialogs are gaining the same help button as the tab windows, and neither had a Website Features page to link to.
Add Download and NBLAST upload pages for the in-app help
…nal in the docs The NBLAST upload dialog now links to the cookies page instead of Wikipedia, so the page has to name the cookie it sets (VFBu_<id>), and the Quick Help preference cookie was missing too.
List the viewer's functional cookies
update doc for stocks queries
Add a section to the Cell Types page covering GitHub issues on the DAO repo and email to support@, and point to it from the Contribution Guidelines index. Co-Authored-By: Claude Opus 5.5 <[email protected]>
Contributor
Author
|
Opened against the wrong repository by mistake; moved to VirtualFlyBrain/VFB2. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
🤖 Generated with Claude Code