Both sites used WordPress's default plain permalinks -- no
permalink_structure was ever set -- so every inbound link anyone has
bookmarked, linked from another site, or has indexed in search is of the
form ?page_id=N or ?p=N. Without a redirect those all land on the
homepage with no indication of where the content went.
scripts/export-wp.mjs now also writes redirects.map: a full ID -> new
path table for every published page/post (not just the ones referenced
from other content, since any of them could have outside inbound links),
in the "id path" format Apache's txt RewriteMap wants. Regenerated on
every export run alongside the content itself.
The :443 vhost looks up page_id/p from the query string against that
map and 301s to the resolved path, stripping the old query string.
Unmapped IDs (deleted pages, a stray revision) fall through to the
homepage rather than a bare 404. The redirect target is host-relative,
so it works correctly under any ServerAlias this vhost answers for
(including the still-dormant www.vicidial.com/vicidial.com aliases,
with no changes needed once DNS is eventually pointed here).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The theme gives every button a pressed effect -- button:active sets
position: relative; top: 1px. Splide renders its arrows as <button>, so
they matched it and flipped from absolute to relative positioning for as
long as the mouse was held down, jumping 181px out of their centred
position mid-click. mousedown and mouseup therefore landed on different
elements (the arrow, then the caption overlay behind it), so the browser
fired click on their common ancestor and the arrow's own handler never
ran. Nothing was logged because nothing errored.
Restoring absolute positioning for .splide__arrow:active fixes it.
Autoplay and the pagination dots were unaffected throughout, which is
why this looked like the arrows specifically were unbound -- they were
bound, the click just never reached them. Verified with real mouse
clicks (not synthetic .click(), which bypasses hit-testing and masked
the bug) on both sites.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The gap between listing items was collapsing to 11-33px and varying per
item, despite a 50px margin. The thumbnail floats left and nothing
contained it, so whenever the excerpt was shorter than the 150px image
-- which is most of them now the column is the full 930px rather than
the theme's 650px -- the image overflowed the item and the margin below
it was absorbed.
.post/.hentry now use display: flow-root, so the item wraps its own
float and the margin is measured below the image. Measured against the
live old site: it has no overflow (-6px) and a steady 42px gap; this was
overflowing by 39-61px. Both sites now sit at a consistent 60px.
That also makes the theme's trailing <br /> and clear div redundant --
they existed only to escape the float -- so the listing markup drops
them and the wrapping Fragment with them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
.post/.hentry margin-bottom goes from the theme's 20px to 50px, giving
about 72px between items once the heading margins and the clearing
<br /> are counted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three things were off in the front-page and blog listings.
The floated thumbnail was never cleared, so the next item's heading
wrapped around it instead of starting below -- front-page.php emits
<br /><div class="clear"> </div> after each post, which is now
reproduced.
The post wrapper was missing the classes WordPress adds via
post_class(); .post/.hentry carry the margin-bottom: 20px that separates
items.
And the listings sat in the theme's #content, which is float: left and
650px because it expects a 230px sidebar alongside. There is no sidebar
here -- the search and widget boxes were WordPress-specific chrome and
were dropped -- so that just left dead space to the right. BaseLayout
already wraps the slot in the full-width #content-full, so the inner
wrapper is removed and the sections span the full 930px.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The theme styled the nav, all headings and the comments watermark with
'Coda', cursive, sans-serif, pulling Coda from Google Fonts. That font
load was never ported, so browsers moved to the next entry in the stack
-- the generic cursive family -- and rendered those elements as a script
face on any device that ships one, which phones do. It went unnoticed
because this server's Chromium has no cursive font installed and so fell
through to sans-serif.
Those three rules now use Arial, Helvetica, sans-serif, matching the body
text, rather than depending on a webfont that is no longer loaded.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Same approach as the vicidial.com migration: 58 pages, 6 posts, 41
attachments and the 4-item nav exported from wordpress_vicihost via
scripts/export-wp.mjs, with the layout and styling ported from this
site's own copy of the small-business theme.
That theme copy is not identical to vicidial's -- it carries the red
VICIhost palette, its own meta description, and shows 6 slides rather
than 5 (smallbusiness_ppp) -- so the CSS and slideshow are ported from
it rather than shared with the other site.
The export script gained handling for custom-link menu items, which this
menu uses for its "Home" entry and vicidial's did not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
jamespandClaude Sonnet 5