Re: Fill page when printing archived threads

On Thu, Feb 12, 2026 at 4:05 AM Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> That's correct, the /list/ namespace is proxied.
>
> The whole handling of templates between them is a mess (one has to remember to manually copy the base template between two different repos when changed), and we should really find a better way to handle that. But that is how it is now.
>
> FWIW, locally I just run pgarchive on a different listener and ignore that the link in the menu doesn't work and have a bookmark that point directly to it.b

Okay, that was pretty much my plan too.

My initial motivation is to improve printing mailing list archives. So
my patch changes a CSS rule in pgarchive. But when I look at an
example page from the archives [1] vs an example page from the About
section [2] they both reference the same CSS URL [3] (albeit with a
different cache-busting hash). So I'm guessing that really comes from
pgweb? Maybe the CSS files in pgarchives should be removed. Or perhaps
they are convenient for running it in dev? A diff between each
project's main.css shows a lot of differences, so I guess you aren't
syncing them like the base template.

Are there any big-picture improvements you'd like to make here that I
could help with? For instance maybe pgarchive should be a separate
Django app within the pgweb project. (I think that would likely call
for moving settings.py and wsgi.py to the top level.) Or just roll it
into pgweb entirely. Or if we're keeping them separate, maybe I could
at least write some documentation about how to set up a dev copy of
pgarchives, and how to integrate it with pgweb (copying templates,
sharing css, etc).

[1] https://www.postgresql.org/message-id/CAKFQuwb0Q655=EYRdpKaVoES9uDbZ3RdWn3=1xOnaZbdpykiLw@mail.gmail.com
[2] https://www.postgresql.org/about/featurematrix/
[3] https://www.postgresql.org/dyncss/base.css

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com