Обсуждение: Fill page when printing archived threads
Hello, www folks! When printing some mailing list threads, I wind up with mostly blank vertical space on the page. For example this one: https://www.postgresql.org/message-id/flat/3c86a16f-4272-4df3-9959-70a9a7d88a71@ewie.name (PDF attached). The reason is the .message-content CSS rule sets the display: inline-block property, and that causes the paragraphs to "stick together" more tightly than to the header or the next message. Changing the property to "block" makes the thread print much more naturally (sample PDF attached, also a patch). What do you think of this change? Btw pgweb has the same CSS rule, although it doesn't appear to be used by anything in that repo. I haven't tested with a locally-running copy of the site. Are there instructions anywhere on setting that up? I'm comfortable with Django, but I would still need a database, possibly a settings file, etc. Yours, -- Paul ~{:-) pj@illuminatedcomputing.com
Вложения
Re: Paul A Jungwirth > I haven't tested with a locally-running copy of the site. Are there > instructions anywhere on setting that up? I'm comfortable with Django, > but I would still need a database, possibly a settings file, etc. docs/dev_install.rst is pretty good. Christoph
On Fri, Jan 23, 2026 at 2:17 AM Christoph Berg <cb@df7cb.de> wrote: > > Re: Paul A Jungwirth > > I haven't tested with a locally-running copy of the site. Are there > > instructions anywhere on setting that up? I'm comfortable with Django, > > but I would still need a database, possibly a settings file, etc. > > docs/dev_install.rst is pretty good. Thanks! My change is actually for the pgarchive repository, but I think you're talking about the instructions for pgweb. I did get pgweb running locally though. (It required some surprising changes to requirements.txt, which I'll submit separately.) When I click on the left nav's "Mailing Lists" link it goes to http://localhost:8000/list/ which is a 404. So I guess postgresql.org must be tying these together behind a reverse proxy. I still haven't found any instructions for getting pgarchive running locally, but I'll experiment a bit. Yours, -- Paul ~{:-) pj@illuminatedcomputing.com
On Wed, 11 Feb 2026 at 23:32, Paul A Jungwirth <pj@illuminatedcomputing.com> wrote:
On Fri, Jan 23, 2026 at 2:17 AM Christoph Berg <cb@df7cb.de> wrote:
>
> Re: Paul A Jungwirth
> > I haven't tested with a locally-running copy of the site. Are there
> > instructions anywhere on setting that up? I'm comfortable with Django,
> > but I would still need a database, possibly a settings file, etc.
>
> docs/dev_install.rst is pretty good.
Thanks! My change is actually for the pgarchive repository, but I
think you're talking about the instructions for pgweb.
I did get pgweb running locally though. (It required some surprising
changes to requirements.txt, which I'll submit separately.) When I
click on the left nav's "Mailing Lists" link it goes to
http://localhost:8000/list/ which is a 404. So I guess postgresql.org
must be tying these together behind a reverse proxy. I still haven't
found any instructions for getting pgarchive running locally, but I'll
experiment a bit.
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
On Thu, Feb 12, 2026 at 4:05 AM Magnus Hagander <magnus@hagander.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 betweentwo 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 abookmark 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@illuminatedcomputing.com
On Thu, 12 Feb 2026 at 17:11, Paul A Jungwirth <pj@illuminatedcomputing.com> wrote:
On Thu, Feb 12, 2026 at 4:05 AM Magnus Hagander <magnus@hagander.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.