New "sticky" concepts?

[Don Chambers]

Garvin - fetching stickies is now based on the the value of a custom user field???? .... or is your example above supposed to be something like my previously mentioned concept of "was_sticky"???

I can see you have also been editing the tech docs for this. Suggestion: include what happens by default (ie, option not specified).

[garvinhicking]

Hi!

Garvin - fetching stickies is now based on the the value of a custom user field????

Exactly. The "useSticky" value before actually only says: Do not fetch old stickies. If your blog entry was posted on the date that would include that entry in the usual entry list, the sticky entry would still be fetched (and put into the 'Sticky' group).
Only entries that do not show up in the same chronological timeline will then not be fetched.

.... or is your example above supposed to be something like my previously mentioned concept of "was_sticky"???

[/quote]

You can use that for 'was_sticky' as well, yes.

I can see you have also been editing the tech docs for this. Suggestion: include what happens by default (ie, option not specified).

I'm doing that for the book, the effort for doing that online is too heavy for me.

Regards,
Garvin

[Don Chambers]

Garvin - fetching stickies is now based on the the value of a custom user field????

Exactly. The "useSticky" value before actually only says: Do not fetch old stickies. If your blog entry was posted on the date that would include that entry in the usual entry list, the sticky entry would still be fetched (and put into the 'Sticky' group).
Only entries that do not show up in the same chronological timeline will then not be fetched.

Thanks again Garvin. My apologies - I do not understand how this works, and do not understand any practical application of the description you provided. An entry is either sticky, or it isn't. Most entry pages are not displayed for date ranges.... they are usually fetched in date order, showing X number of entries per page. Perhaps I just need more coffee to understand!!

However, assuming there is actually some advantage of this old vs. not old, how about these options:

oldSticky: true/false: which seems to be what currently exists.
allSticky: true/false: Include all stickies/exclude all stickies.
onlySticky: true/false: Only sticky entries fetched.

Or perhaps a single variable (string or int) that is set for each type of condition:

useSticky: 0=old stickies, 1=all stickies, 2=only stickies 3=no stickies.

This final method seems to have an advantage - you can update in the future to include 4, 5, etc if there are scenarios that have not been anticipated at this time.

It just seems very burdensome IMHO to use an extended custom field for every entry to identify entryprops="ep_is_sticky=true" when the "mark as sticky post" has already been checked.

It IS, however, great that you were able to work in fetching based on custom user fields... that will likely come in real handy.

I can see you have also been editing the tech docs for this. Suggestion: include what happens by default (ie, option not specified).

I'm doing that for the book, the effort for doing that online is too heavy for me.

I meant something like:

Code: Select all

full             
(boolean) 
Indicates if the full entry will be fetched (body+extended: TRUE), 
or only the body (FALSE).  If not specified (or "Default"): true.

[garvinhicking]

Hi!

Thanks again Garvin. My apologies - I do not understand how this works, and do not understand any practical application of the description you provided. An entry is either sticky, or it isn't. Most entry pages are not displayed for date ranges.... they are usually fetched in date order, showing X number of entries per page. Perhaps I just need more coffee to understand!!

No apologies required.

A sticky entry has an entry date, despite of it being sticky. You can see that if you edit the blog entry - you'll see the original date in the edit screen.

Let's say you have 5 entries:

Entry #1, 2007-01-01
Entry #2, 2007-02-01
Entry #3, 2007-03-01
Entry #4, 2007-04-01
Entry #5, 2007-05-01

Let's say you make entry #1 sticky. Let's say you configure your startpage to show 3 entries.

This means, you will see this rendering:

Entry#1 (Sticky, no date shown)
Entry #5
Entry #4

Now, assume you use the smarty_fetchPrintEntries code to show 3 items. With the default no Sticky setting, you get Entry 1, 5 and 4.

If you now set the "no sticky setting" for the fetchPrintEntries function, you will get entry 5, 4 and 3 instead. This is, because Entry #3 is more recent than Entry #1. It gets hidden, because the sticky-fetching is unfunctional.

However, if you made entry #3 sticky, you will see entry #3 on the "non sticky" output as well, because entry#3 is the most recent third entry of the three items you want to show.

You can only forcible exclude sticky entries by using this new filtering mechanism I introduced. noSticky simply means: "Do not treat entries as sticky, interpret their date as usual". It does not mean "Treat sticky entries as invalid entries and remove them completely".

Once the stickyness is ignored, a blog entry resumes to be a usual blog entry. It does not get removed from the "flow".

However, because of the way that entries.tpl formats entries which have the "sticky" attribute (this is still attached to the entry, because you actually did not remove the sticky attribute, only the way they are fetched), the entry will still be rendered as a sticky entry. So you only get the same display because your entries accidentaly are within the same daterange - not because the function does not work properly.

However, assuming there is actually some advantage of this old vs. not old, how about these options:

We cannot change the way it is currently implemented, that would break BC.

It just seems very burdensome IMHO to use an extended custom field for every entry to identify entryprops="ep_is_sticky=true" when the "mark as sticky post" has already been checked.

Actually that's the most logical conclusion. You simply add a listing of fields with their expected values you want to fetch. IMHO that's the most clean and lean solution.

I meant something like:

You have coWiki access, right? Could you do that?

Regards,
Garvin

[Don Chambers]

Let's say you have 5 entries......

OK - I am finally understanding it. But I still think it might be valuable to introduce a NEW sticky option with the options I previously described (old, all, only, none).... there would be no BC issue if it were new.

You have coWiki access, right? Could you do that?

No access that I know of, but even if I did, I do not know what the defaults are.... otherwise I would be happy to.

[Don Chambers]

What kind of things are suppressed by use_footer="false"? I am using the latest 1.3 alpha.

Code: Select all

{serendipity_fetchPrintEntries limit="0,5" full="true" use_footer="false" skip_smarty_hooks="true"}

I realize it is this, in entries.tpl:

Code: Select all

    {if $footer_info}
        ({$footer_info})
    {/if}

I just cannot think of an example off the top of my head of what gets fed into this and it is driving me nuts!!!

[garvinhicking]

Hi!

There's some function in include/functions_entries.inc.php that generates this...

Regards,
Garvin

[Don Chambers]

But can you think of any? I want to trigger it for styling purposes, and I cannot for the life of me come up with anything!!!

[garvinhicking]

Hi!

But can you think of any? I want to trigger it for styling purposes, and I cannot for the life of me come up with anything!!!

What do you mean with "think of"? $footer_info is that what gets displayed for pagination purposes "(Page X of Y, totalling Z entries)"...?

Regards,
Garvin

[Don Chambers]

That is what I originally thought Garvin, but here is the bottom of the default entries.tpl, and what most entries.tpl's look like too:

Code: Select all

    <div class='serendipity_entryFooter' style="text-align: center">
    {if $footer_prev_page}
        <a href="{$footer_prev_page}">« {$CONST.PREVIOUS_PAGE}</a>  
    {/if}

    {if $footer_info}
        ({$footer_info})
    {/if}

    {if $footer_next_page}
        <a href="{$footer_next_page}">» {$CONST.NEXT_PAGE}</a>
    {/if}

    {serendipity_hookPlugin hook="entries_footer"}

[garvinhicking]

Yes, exactly - that's where $footer_info is emitted?!?

I'm feeling as if either one of us is standing on a power cord as thick as the atlantic ocean.

Regards,
Garvin

[Don Chambers]

My point is that next/previous page is not enclosed within {if $footer_info} in any template I have seen.

1) should it be?
2) what might the contents of $footer_info be?
3) should {serendipity_hookPlugin hook="entries_footer"} also be within this {if}?

[garvinhicking]

Hi!

$footer_info only contains the Text "Page X of Y, totalling Z entries". The next/back links are part of different $footer_* things, like you pasted in your output. If we would enclose them, all templates that currently exist would have duplicate output...

Regards,
Garvin

[Don Chambers]

In that case, it is definitely not working. I am using the following in my index.tpl to retrieve the 5 most recent entries:

Code: Select all

{serendipity_fetchPrintEntries limit="0,5" full="true" use_footer="false" skip_smarty_hooks="true" template="entries.tpl"}

This is using the bulletproof entries.tpl.

[garvinhicking]

Hi!

What is not working? What do you get/see? What do you expect?

Regards,
Garvin