| Age | Commit message (Collapse) | Author |
|---|
|
Adds a new yes/no config setting (default no, preserving current behavior)
that orders the main album's photos by EXIF date taken (ascending) instead
of the default filename/shuffle order. Reuses the existing EXIF cache and
tag fallback chain (DateTimeOriginal -> DateTimeDigitized -> DateTime)
already used for tooltips/details/stats, so ordering never disagrees with
what those features show. Photos with no usable EXIF date fall back to
their source file's mtime, staying fully deterministic and crash-free.
CHRONOLOGICAL_ORDER takes precedence over SHUFFLE when both are enabled,
documented in album-photo-select.source.sh and docs/configuration.md.
Wired through the config registry (CONFIG_SPECS), validation, CLI flags
(--chronological/--no-chronological), --print-config, --dry-run,
--verbose logging, and shuriken.json generation metadata. Adds unit and
end-to-end tests covering default-off behavior, EXIF-date ordering with
shuffle precedence, and mtime fallback for EXIF-less photos.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
|
Album owners can now set DETAILS_PAGE=no (or pass --no-details) to skip
generating each photo's *-details.html EXIF summary page and its "Details"
navigation redirects, without touching the normal thumbnail overview,
per-photo view pages, EXIF tooltips, or STATS_PAGE, which all stay
independently controlled. Every "Details" link (on view pages and stats
filter mini-album view pages) and every "-details" redirect stub is gated
on the setting so no generated page ever links to a file that was not
rendered. Wired the new field through CONFIG_SPECS (registry-driven
defaults/validation/print-config/CLI override), the --details/--no-details
CLI flags, usage() help, the verbose effective-config log, shuriken.json
generation metadata, and the dry-run plan. DETAILS_PAGE=yes (the default)
keeps prior output byte-for-byte identical.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
|
Pure, behavior-preserving refactor: extract _-prefixed helpers from six
functions that exceeded the project's 50-line threshold, leaving each
original as a thin orchestrator. Generated HTML, dry-run output,
shuriken.json, EXIF cache behavior and the flush-grid layout are all
byte-identical (full test suite green).
Refactored:
- _generation_metadata_json -> _generation_metadata_json_head +
_generation_metadata_json_settings
- print_dry_run_plan -> _print_dry_run_settings + _print_dry_run_files
- _photo_exif_tooltip_text_from_values -> _collect_exif_tooltip_parts +
_emit_exif_tooltip_parts
- cached_photo_identify_output -> _rebuild_photo_identify_cache
- render_album_pages -> _render_album_page (one page record)
- append_preview_grid -> _roll_and_align_page_tiles + _emit_page_tiles
(uniquely-named namerefs to avoid circular-nameref)
Left intact (delicate errexit/trap management that must stay in one
function scope, where a split would change semantics):
source_template_file, refresh_splash, generate_staged,
replace_dist_with_staging.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
Consumers 5 (log_configured_action) and 6 (the --dry-run plan) are
consciously left bespoke: both are human-facing prose that interleaves a
curated subset of config fields (each with its own label and per-field
decoration) with non-config values (resolved rc_file path,
SHURIKEN_FORCE_GENERATE, computed image/page/redirect counts, planned
tarball name, and whole non-config 'Planned directories/files' sections).
Driving them from CONFIG_SPECS would require per-line label+format+marker
facets that contort the schema for no DRY benefit, since each string
appears exactly once.
They already read the canonical registry-driven globals, so CONFIG_SPECS
remains the single source of truth for the config schema; only the
presentation stays hand-written. Added comments to both explaining the
decision. No behavior change -- output stays byte-identical (asserted by
the effective-config log and dry-run plan tests).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
collect_dry_run_page_plan re-derived page_count via the ceil formula and
redirect_count via a magic "*4+2", duplicating logic owned by
album_page_records (pagination) and render_page_view_redirects (redirect
files). The preview could silently drift from a real --generate.
Single source of truth:
- album_page_count_for_image_count (album-photo-select.source.sh) owns the
MAXPREVIEWS-per-page grouping count that album_page_records realises.
- ALBUM_REDIRECTS_PER_PAGE=4 / ALBUM_REDIRECTS_LAST_PAGE_EXTRA=2 +
album_redirect_count_for_page_count (album-render.source.sh) own the
per-page (4) plus last-page-extra (2) redirect tally that
render_page_view_redirects actually emits.
dry-run now predicts both counts through these helpers (no dist files
touched, side-effect free). Confirmed the real redirect count is
page_count*4+2, so output is byte-identical: partial-final-page (3 preview
pages / 14 navigation redirects) and empty album (0 / 0) unchanged.
Regenerated bin/shuriken; just test/shellcheck/check-generated all pass.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
album-metadata.source.sh aggregated six unrelated concerns. Move each
along its existing seam (pure mechanical move, no logic changes):
- EXIF presentation (photo_exif_details_html, tooltip helpers, the
_photo_exif_values_to wrapper) stays in album-metadata.source.sh,
which is now EXIF-presentation only.
- File counting (count_files, count_incoming_images, count_tree_files)
-> image.source.sh, which already owns incoming_image_files;
count_incoming_images is a direct wrapper of it.
- Tarball naming (tarball_name_plan, generated_tarball_name) ->
archive.source.sh, which already owns tarball()/resolve_tar_opts.
- Generation metadata + JSON (_collect_generation_metadata,
_generation_metadata_json, write_generation_metadata) -> new
generation-metadata.source.sh.
- Dry-run (dry_run, collect_dry_run_*, print_dry_run_plan) -> new
dry-run.source.sh.
- clear_exif_cache -> metadata-cache.source.sh, next to the cache
primitive cached_photo_identify_output.
LIB_SOURCES (Justfile + src/shuriken.sh): insert generation-metadata
and dry-run right after album-metadata, before album-render/album.
They depend on image, archive, template and metadata-cache (all earlier
or runtime-only calls), and are consumed by the album coordinator and
the dry-run CLI action, which come later. bin/shuriken regenerated via
just build. File-header comments updated to reflect the new homes.
just test, just shellcheck, just check-generated and git diff --check
all pass.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
