MIME-Version: 1.0
References: 
 <CA+renyXaMYGFKvyqt4ZpQFUu8A70VConiNSzPM=Pn_xKqeRDEw@mail.gmail.com>
 <aXNKspgzgJbzL8Iv@msg.df7cb.de>
 <CA+renyWA77wVu2Zis3=tdBWAj-Xbz7cKuZbMbo6=o5cMR7wZVQ@mail.gmail.com>
 <CABUevExFUaz0htSuq3HaKxt-Ci7kTmVNHxQRvsP0Ys-+ZEh+Fw@mail.gmail.com>
 <CA+renyXechJ8mMg7gd9Wn-noxhfBAExXKWx7HATWhn63AVKvug@mail.gmail.com>
In-Reply-To: 
 <CA+renyXechJ8mMg7gd9Wn-noxhfBAExXKWx7HATWhn63AVKvug@mail.gmail.com>
From: Magnus Hagander <magnus@hagander.net>
Date: Fri, 20 Feb 2026 20:18:52 +0100
Message-ID: 
 <CABUevEwohrJtN0NMrnAD4kHDLrzQn6bB_2Y=890P9PHTd3vuGg@mail.gmail.com>
Subject: Re: Fill page when printing archived threads
To: Paul A Jungwirth <pj@illuminatedcomputing.com>
Cc: Christoph Berg <cb@df7cb.de>, pgsql-www@postgresql.org
Content-Type: multipart/alternative; boundary="0000000000006e63c7064b464ba3"
Archived-At: 
 <https://www.postgresql.org/message-id/CABUevEwohrJtN0NMrnAD4kHDLrzQn6bB_2Y%3D890P9PHTd3vuGg%40mail.gmail.com>
Precedence: bulk

--0000000000006e63c7064b464ba3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 12 Feb 2026 at 17:11, Paul A Jungwirth <pj@illuminatedcomputing.com=
>
wrote:

> On Thu, Feb 12, 2026 at 4:05=E2=80=AFAM 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.

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

--0000000000006e63c7064b464ba3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, 12 Feb 2026 at 17:11, Paul A Jung=
wirth &lt;<a href=3D"mailto:pj@illuminatedcomputing.com">pj@illuminatedcomp=
uting.com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_contain=
er"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Feb 12, 2026 =
at 4:05=E2=80=AFAM Magnus Hagander &lt;<a href=3D"mailto:magnus@hagander.ne=
t" target=3D"_blank">magnus@hagander.net</a>&gt; wrote:<br>
&gt; That&#39;s correct, the /list/ namespace is proxied.<br>
&gt;<br>
&gt; The whole handling of templates between them is a mess (one has to rem=
ember to manually copy the base template between two different repos when c=
hanged), and we should really find a better way to handle that. But that is=
 how it is now.<br>
&gt;<br>
&gt; FWIW, locally I just run pgarchive on a different listener and ignore =
that the link in the menu doesn&#39;t work and have a bookmark that point d=
irectly to it.b<br>
<br>
Okay, that was pretty much my plan too.<br>
<br>
My initial motivation is to improve printing mailing list archives. So<br>
my patch changes a CSS rule in pgarchive. But when I look at an<br>
example page from the archives [1] vs an example page from the About<br>
section [2] they both reference the same CSS URL [3] (albeit with a<br>
different cache-busting hash). So I&#39;m guessing that really comes from<b=
r>
pgweb? Maybe the CSS files in pgarchives should be removed. Or perhaps<br>
they are convenient for running it in dev? A diff between each<br>
project&#39;s main.css shows a lot of differences, so I guess you aren&#39;=
t<br>
syncing them like the base template.<br></blockquote><div><br></div><div>Ye=
ah, I think that&#39;s the problem - a lot of fixes have been applied only =
to one side, and that&#39;s led to a lot of divergence over time.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Are there any big-picture improvements you&#39;d like to make here that I<b=
r>
could help with? For instance maybe pgarchive should be a separate<br>
Django app within the pgweb project. (I think that would likely call<br>
for moving settings.py and wsgi.py to the top level.) Or just roll it<br>
into pgweb entirely. Or if we&#39;re keeping them separate, maybe I could<b=
r>
at least write some documentation about how to set up a dev copy of<br>
pgarchives, and how to integrate it with pgweb (copying templates,<br>
sharing css, etc).<br></blockquote><div><br></div><div>We don&#39;t want to=
 integrate it to that level, because we have external users of the archives=
 code that don&#39;t use pgweb at all. And we have our own private archives=
, which aren&#39;t linked in under the same hostname and runs a completely =
independent instance.</div><div><br></div><div>I&#39;m thinking maybe somet=
hing 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 w=
ith built-in templates if iit doesn&#39;t. And then we could reduce the bui=
lt-in ones to not be as heavily postgres branded. And the same for media fi=
les like css and js of course.</div></div><div><br></div><span class=3D"gma=
il_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signatur=
e"><div dir=3D"ltr"><div>=C2=A0Magnus Hagander<br>=C2=A0Me: <a href=3D"http=
://www.hagander.net/" target=3D"_blank">https://www.hagander.net/</a><br>=
=C2=A0Work: <a href=3D"http://www.redpill-linpro.com/" target=3D"_blank">ht=
tps://www.redpill-linpro.com/</a></div></div></div></div>

--0000000000006e63c7064b464ba3--