RE: Paginated index pages

> I really don't see what the problem is. 100s of index
pages are fine.

> Especially if they don't have to be dynamically
reproduced each time,

> and they have a sensible naming structure. They aren't
hurting anyone

> or really taking up that much space on your server.

Yes, space really isn't the issue.

> A dynamic approach would be what swish-e currently
gives you as your  
> search engine. Right?

Yes, we use swish-e as our search engine, and it also powers
our topic
results page.

For example: http://www.gr
ist.org/topic/green_living

This works great if you simply want the title, subtitle and
excerpt, but
the logic that I was envisioning for our news index pages is
a little
more complicated, and is native to Bricolage, but not
swish-e.

> Are you trying to think of a way to make the site more
browsable?

One issue for me is bulk republishing. If we make a template
change that
requires republishing all these pages, then it is currently
a pain. I
say "currently" because we unwisely have Bricolage
running on our
production server. So, bulk republishing a lot of pages via
bric_soap
has to be carefully monitored and coordinated so not to
cause the
website to be sluggish or non-responsive (due to maxing out
the CPU).
However, we will be migrating our website to a better server
and
eventually Bricolage to a dedicated machine.

Chris

----------------------------

Chris Schults
Web Production Manager
Grist
710 Second Avenue, Suite 860
Seattle, WA  98104
Phone: 206-876-2020, ext. 204
Fax: 253-423-6487
<http://www.grist.org>

>
>> Are you trying to think of a way to make the site
more browsable?
>
> One issue for me is bulk republishing. If we make a
template change  
> that
> requires republishing all these pages, then it is
currently a pain. I
> say "currently" because we unwisely have
Bricolage running on our
> production server. So, bulk republishing a lot of pages
via bric_soap
> has to be carefully monitored and coordinated so not to
cause the
> website to be sluggish or non-responsive (due to maxing
out the CPU).
> However, we will be migrating our website to a better
server and
> eventually Bricolage to a dedicated machine.

Ah I see. I have all my weekly archives updated once at week
at 3 am  
- they change so seldom - and If I want I can just republish
the  
Archive week I know corresponds to a story I just
moved/removed.  
Cover stories on the other hand update once an hour.

Dawn

>
> Chris
>
> ----------------------------
>
> Chris Schults
> Web Production Manager
> Grist
> 710 Second Avenue, Suite 860
> Seattle, WA  98104
> Phone: 206-876-2020, ext. 204
> Fax: 253-423-6487
> <http://www.grist.org>

>

"Chris Schults" <cschultsgrist.org> writes:
> One issue for me is bulk republishing. If we make a
template change
> that requires republishing all these pages, then it is
currently a
> pain.

I'm not exactly sure I followed each detail. Anyway, maybe
we have a
similar situation:

We generate pages that collect teasers of news stories
(using all kind
of bricolage meta info, eg. sorting by dates, categories,
content,
etc.). These collection pages theoretically have to be
updated each
time a news is changed or added. During bulk publish it's a
pain,
because each single story would continuously burn the
collection
pages again and again.

We created a rather dirty workaround for this: I do bulk
edit from the
outside via bric_soap. During this I create a special named
temp file
on the bricolage server, which, when it exists, tells the
templates to
not recreate the news collection pages.

Then I have a special story (with "do not delete
me" in the title 
that triggers re-burning of all known collection stories.
This story
is single published at the end of bulk publish.

After this bulk publish I delete the special temp file.

This way the news collection pages are only burned when
someone
publishes in the user interface, not during a bulk publish
run
outside.

There's some risk handling around this, eg. signal handlers
on exit
that assure the delete of the temp file, etc., so it's all
rather
dirty.

Steffen
-- 
Steffen Schwigon <schwigonwebit.de>
Dresden Perl Mongers <http://dresden-pm.org/>

Deutscher Perl-Workshop <http://www.perl-work
shop.de/>

On Jul 11, 2007, at 13:06, Steffen Schwigon wrote:

> There's some risk handling around this, eg. signal
handlers on exit
> that assure the delete of the temp file, etc., so it's
all rather
> dirty.

We really need the patch that I sent to David Beaudet. It
should  
solve all this bulk republishing crap once and for all.

Good hack, though. What I did in a similar situation was put
the code  
that triggers the publication of other stories in a utility
template,  
and that template has this line in it:

   return unless 1;

Just before I do a bulk publish, I check it out, change that
to 0,  
then deploy it. I do the bulk publish, then check it out,
set it to 1  
again, and redeploy.

Best,

David

On Jul 11, 2007, at 1:38 PM, Chris Schults wrote:

>> A dynamic approach would be what swish-e currently
gives you as your
>> search engine. Right?
>
> Yes, we use swish-e as our search engine, and it also
powers our topic
> results page.
>
> For example: http://www.gr
ist.org/topic/green_living

That's lovely. And this -- http://www.grist.org/topi
c/ -- is great.  
(Not sure how I missed it before!)

I'll be asking you how you approached that one day soon. 


--
Phillip Smith,
Simplifier of Technology
Community Bandwidth