Mailing List Archive

On Wed, 16 Apr 2008, David E. Wheeler wrote:
> I just noticed that I was able to set the cover date in a non-fixed story to
> be empty. So then my non-fixed story ended up with a URI with no date. This
> just seems wrong to me.
>
> Can anyone think of a reason not to require a cover date for all stories? Can
> you all run this query and let me know if you have any valid stories (or
> media) without cover dates?
>
> select count(story__id) from story_instance where cover_date is null
> union
> select count(media__id) from media_instance where cover_date is null;
>
> You should get:
>
> count
> -------
> 0
> 0
> (2 rows)

Corresponding 1.8 queries from our system:

bricolage=> select count(id) from story where cover_date is null and active=1;
count
-------
24
(1 row)

bricolage=> select count(id) from media where cover_date is null and active=1;
count
-------
1
(1 row)

I'm not sure how we're defining "valid story" or "valid media", however.
Everyone one of our assets is of course precious and of vital importance.
To someone.

David E. Wheeler wrote:
>
> select count(story__id) from story_instance where cover_date is null
> union
> select count(media__id) from media_instance where cover_date is null;
>

I get 0,0 on our main CMS and 21 stories and 1 media on our multi site
CMS. Looking further the stories in the multi site one were all inserted
via SOAP so I assume for some reason the cover date wasn't passed in
with the story at insertion point.

An easy fix would be to make sure that the $asset->save call sets the
coverdate to be now() if it's blank. That way it can't ever be set to
blank.

regards,

Paul.

On Apr 17, 2008, at 01:46, Paul Orrock wrote:

> I get 0,0 on our main CMS and 21 stories and 1 media on our multi
> site CMS. Looking further the stories in the multi site one were all
> inserted via SOAP so I assume for some reason the cover date wasn't
> passed in with the story at insertion point.
>
> An easy fix would be to make sure that the $asset->save call sets
> the coverdate to be now() if it's blank. That way it can't ever be
> set to blank.

Yes, and I'd add a NOT NULL constraint on the database, too. But to do
so, I'd have to write an upgrade script to set the cover date for
those that are missing it, probably from first_publish_date. Any
objections? Scott, can you look at those 24 stories and 1 media do see
what the deal is with them, or at least to get an idea?

Thanks,

David

On Thu, 17 Apr 2008, David E. Wheeler wrote:
> On Apr 17, 2008, at 01:46, Paul Orrock wrote:
>> I get 0,0 on our main CMS and 21 stories and 1 media on our multi site CMS.
>> Looking further the stories in the multi site one were all inserted via
>> SOAP so I assume for some reason the cover date wasn't passed in with the
>> story at insertion point.
>>
>> An easy fix would be to make sure that the $asset->save call sets the
>> coverdate to be now() if it's blank. That way it can't ever be set to
>> blank.
>
> Yes, and I'd add a NOT NULL constraint on the database, too. But to do so,
> I'd have to write an upgrade script to set the cover date for those that are
> missing it, probably from first_publish_date. Any objections? Scott, can you
> look at those 24 stories and 1 media do see what the deal is with them, or at
> least to get an idea?

I don't see any obvious pattern to them,
arbitrary categories and publish_dates... no idea.
Probably bric_soap-related as for Paul.
They do have first_publish_date and publish_date non-NULL.

On Thu, Apr 17, 2008 at 09:46:48AM +0100, Paul Orrock wrote:
> David E. Wheeler wrote:
> >
> >select count(story__id) from story_instance where cover_date is null
> >union
> >select count(media__id) from media_instance where cover_date is null;
> >
>
> I get 0,0 on our main CMS and 21 stories and 1 media on our multi site
> CMS. Looking further the stories in the multi site one were all inserted
> via SOAP so I assume for some reason the cover date wasn't passed in
> with the story at insertion point.
>
> An easy fix would be to make sure that the $asset->save call sets the
> coverdate to be now() if it's blank. That way it can't ever be set to
> blank.

I'm not still not sure if it'd be usefull to have an undated article, but if the policy _is_ to require it, I don't think I like the automagic installation of dates... I'd rather it throw and error and say "Finish your job, person creating this story".

> regards,
>
> Paul.

--

Brad Harder,
Method Digital Logic
http://www.methodlogic.net

I'm coming late to this, but I've run into precisely this issue with the
Observer site.

uco=> select count(story__id) from story_instance where cover_date is
null union select count(media__id) from media_instance where cover_date
is null;
count
-------
0
129
(2 rows)


All these cover-date-less story instances are author bios, which are
created by a utility template when a story is published and one of its
contributors does not already have a bio story.

The template doing the creating does not pass a cover date in to
$story->new. At first, I thought this was OK, because the bio stories
looked fine and published fine, and had static URIs.

But. The bio stories themselves use image_resize_and_relate.mc to make
small standard size versions of author mugshots, and those mugshots need
cover dates for their own URIs, and image_resize_and_relate.mc uses the
cover date of the parent story to set the cover date of new media it
creates.

So I've been manually adding cover dates to bio stories.

One more bit of weirdness: I tried to have publish_author_story.mc take
the cover date from the originating story, but that resulted in an
error. Each time I tried to publish a story with a new contributor, an
error would tell me that the story with (UUID) was not associated with
any categories. I imagine the story it meant was the new bio, becuase it
showed a new UUID in the error every time I tried the publish.

So a limited set of initial parameters for $story->new allowed was OK,
sort of, as long as the cover date was missing. But once cover date was
in the mix, Bricolage wanted a category as well.

Here's publish_author_story.mc. You can see the commented out
date-setter.

Just for reference, does anyody know the minimum set of initial
parameters that $story->new wants? Maybe it would be good to auto-set
(or insist on ) those. Heck, maybe even I could do that patch. :) I'll
try, anyhow.


Cheers,

Bret




<%doc>

=head1 NAME

publish_author_story.mc

=head1 SYNOPSIS

# create author story(s) for the contributors associated with this feature, if they don't already exist
foreach my $contributor ($story->get_contributors) {
$m->comp('/util/publish_author_story.mc', contributor => $contributor);
}


=head1 DESCRIPTION

Looks for an existing author story for this contributor object
If an author story doesn't exist for this contributor (and there isn't a same URI for an different contributor) create it and publish it

</%doc>

<%args>
$contributor => undef #this value should be sent via the story template that calls this template
$contrib_id => undef
$story_slug => undef
$author_story_element => Bric::Biz::ElementType->lookup({key_name => 'author'})
</%args>

<%init>
# We need a contributor object to get the ball rolling.
$burner->throw_error("There is no contributor, you need to add one.")
unless $contributor;

$contrib_id = $contributor->get_id;

my ($author_category) = Bric::Biz::Category->list({
uri => '/author/',
});


$burner->throw_error("There is no /author/ category, you need to create one.")
unless $author_category;


#format the slug using the contributor name
$story_slug = $m->comp("/util/authorname_to_slug.mc", contrib=> $contributor);
my $author_category_uri = $author_category->get_uri;
my $story_uri = lc($author_category_uri.$story_slug).'/';



</%init>

<%perl>
# Looks for an existing author.mc story with this same contributor associated
my ($author_story) = $story->list({
contrib_id => $contrib_id,
element_key_name => 'author',
Limit => 1,
unexpired => 1, # No expired stories!
#published_version => 1, # should this be looking for unpublished as well?

});


# Now look for an existing author.mc story with another contributor but the same URI (these things can happen!)
my ($author_story_sameuri) = $story->list({
#contrib_id => $contrib_id,
element_key_name => 'author',
uri => $story_uri,
Limit => 1,
unexpired => 1, # No expired stories!
published_version => 1, # should this be looking for unpublished as well?

});

# this makes me wonder if names should have numbers in the URI corresponding to contributor ID? Or a date corrosponding to when they were added?
#$burner->throw_error("An author story with the URI ".$story_uri. " already exists. You need to differentiate these contributor names to make the slugs different.")
# if $author_story_sameuri;


unless ($author_story){
# We need to create a new author story for this contributor.
$author_story = Bric::Biz::Asset::Business::Story->new({
element_type => $author_story_element,
source__id => $story->get_source__id,
site_id => $story->get_site_id,
user__id => Bric::App::Session::get_user_id(),
title => $contributor->get_name("Author :: %f% m% l"),
#cover_date => $story->get_cover_date, # you can change this
slug => $story_slug,

});

# Set it up and check it in.
$author_story->add_categories( [ $author_category->get_id ] );
$author_story->set_primary_category( $author_category->get_id );
$author_story->add_contributor($contrib_id);
Bric::App::Util::add_msg( 'New Author story created for author '.$contributor->get_name('%f% m% l'));
$author_story->checkin;
$author_story->save;

# Publish
$burner->publish_another($author_story);
}

</%perl>





On Wed, 2008-04-16 at 15:16 -0700, David E.Wheeler wrote:
> Hi All,
>
> I just noticed that I was able to set the cover date in a non-fixed
> story to be empty. So then my non-fixed story ended up with a URI with
> no date. This just seems wrong to me.
>
> Can anyone think of a reason not to require a cover date for all
> stories? Can you all run this query and let me know if you have any
> valid stories (or media) without cover dates?
>
> select count(story__id) from story_instance where cover_date is null
> union
> select count(media__id) from media_instance where cover_date is null;
>
> You should get:
>
> count
> -------
> 0
> 0
> (2 rows)
>
> Thanks,
>
> David
>
--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com

On Apr 18, 2008, at 06:57, Scott Lanning wrote:

> I don't see any obvious pattern to them,
> arbitrary categories and publish_dates... no idea.
> Probably bric_soap-related as for Paul.
> They do have first_publish_date and publish_date non-NULL.

Did you look at them on the site, maybe to see if a dateline is
screwed up in the output?

Best,

David

On Apr 18, 2008, at 08:08, bharder wrote:

> I'm not still not sure if it'd be usefull to have an undated
> article, but if the policy _is_ to require it, I don't think I like
> the automagic installation of dates... I'd rather it throw and error
> and say "Finish your job, person creating this story".

Well, they default to "now", but we would of course throw an error if
someone removed a cover date.

Best,

David

On Apr 18, 2008, at 08:32, Bret Dawson wrote:

> But. The bio stories themselves use image_resize_and_relate.mc to make
> small standard size versions of author mugshots, and those mugshots
> need
> cover dates for their own URIs, and image_resize_and_relate.mc uses
> the
> cover date of the parent story to set the cover date of new media it
> creates.
>
> So I've been manually adding cover dates to bio stories.

Bleh. That doesn't sound fun.

> One more bit of weirdness: I tried to have publish_author_story.mc
> take
> the cover date from the originating story, but that resulted in an
> error. Each time I tried to publish a story with a new contributor, an
> error would tell me that the story with (UUID) was not associated with
> any categories. I imagine the story it meant was the new bio,
> becuase it
> showed a new UUID in the error every time I tried the publish.

Odd.

> So a limited set of initial parameters for $story->new allowed was OK,
> sort of, as long as the cover date was missing. But once cover date
> was
> in the mix, Bricolage wanted a category as well.

That's probably because it was properly checking the URI. So set the
cover date separately, after you set the category. So, pseudo-code:

my $s = Story->new(...);
$s->add_category($cat);
$s->set_primary_category($cat);
$s->set_cover_date( $date );

> Here's publish_author_story.mc. You can see the commented out
> date-setter.
>
> Just for reference, does anyody know the minimum set of initial
> parameters that $story->new wants? Maybe it would be good to auto-set
> (or insist on ) those. Heck, maybe even I could do that patch. :) I'll
> try, anyhow.

That would be nice. I don't know the minimum, but you can look at the
source for new() and at Bric::App::Callback::Profile::Story for
examples.

Best,

David

On Fri, 18 Apr 2008, David E. Wheeler wrote:
> On Apr 18, 2008, at 06:57, Scott Lanning wrote:
>> I don't see any obvious pattern to them,
>> arbitrary categories and publish_dates... no idea.
>> Probably bric_soap-related as for Paul.
>> They do have first_publish_date and publish_date non-NULL.
>
> Did you look at them on the site, maybe to see if a dateline is screwed up
> in the output?

I think it's easier if I just set the cover date
to the publish date for those ones.

On Apr 21, 2008, at 12:09 AM, Scott Lanning wrote:

> On Fri, 18 Apr 2008, David E. Wheeler wrote:
>> On Apr 18, 2008, at 06:57, Scott Lanning wrote:
>>> I don't see any obvious pattern to them,
>>> arbitrary categories and publish_dates... no idea.
>>> Probably bric_soap-related as for Paul.
>>> They do have first_publish_date and publish_date non-NULL.
>>
>> Did you look at them on the site, maybe to see if a dateline is
>> screwed up
>> in the output?
>
> I think it's easier if I just set the cover date
> to the publish date for those ones.

I finally made this happen yesterday, BTW. Cover dates are now
required and default to the current time.

Best,

David