Re: Fill page when printing archived threads

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
Cc: Christoph Berg <cb(at)df7cb(dot)de>, pgsql-www(at)postgresql(dot)org
Subject: Re: Fill page when printing archived threads
Date: 2026-02-20 19:18:52
Message-ID: CABUevEwohrJtN0NMrnAD4kHDLrzQn6bB_2Y=890P9PHTd3vuGg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-www

On Thu, 12 Feb 2026 at 17:11, Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
wrote:

> 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.
>

Yeah, I think that's the problem - a lot of fixes have been applied only to
one side, and that's led to a lot of divergence over time.

>
> 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).
>

We don't want to integrate it to that level, because we have external users
of the archives code that don't use pgweb at all. And we have our own
private archives, which aren't linked in under the same hostname and runs a
completely independent instance.

I'm thinking maybe something along the line of having a way to point
template directories at pgweb and have it pick up changes from there if
they show up, but still operate with built-in templates if iit doesn't. And
then we could reduce the built-in ones to not be as heavily postgres
branded. And the same for media files like css and js of course.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Browse pgsql-www by date

  From Date Subject
Next Message Nathan Bossart 2026-02-20 22:28:00 Re: Moving the vacuum GUCs' docs out of the Client Connection Defaults section
Previous Message Joe Conway 2026-02-16 14:56:22 Re: wiki : suggest new GUI