static pages using entries.tpl, revisited

Creating and modifying plugins.
User avatar
Don Chambers
Regular
Posts: 3638
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

static pages using entries.tpl, revisited

Post by Don Chambers » Sat Mar 22, 2014 6:58 pm

Prior discussion started by YL.
Prior discussion started by me

In both discussions above, it was noted that entries.tpl is used/processed whenever staticpages are viewed. Another example of this identical behavior can be seen when viewing output from the contactform plugin. This "flow" occured in s9y <1.7, and still happens in 1.7.8 today.

In both mine, and YL's examples above, the use of entries.tpl during staticpage generation resulted in an empty <div> which neither of us wanted on static pages nor contact forms.

Prior to s9y 1.7, my solution was to skip over portions of entries.tpl by wrapping nearly all of entries.tpl within the following:

Code: Select all

    {if $staticpage_pagetitle ==''} {* proceed only if this is not a static page *}
        .....
    {/if}
I said "NEARLY" ALL of entries.tpl, because the following cannot be excluded from entries.tpl, as this line calls the static page (among other things):

Code: Select all

{serendipity_hookPlugin hook="entries_header" addData="$entry_id"}
The {if $staticpage_pagetitle ==''} above could also be replaced with empty($staticpage_pagetitle) or isset($staticpage_pagetitle). The key issue here was that $staticpage_pagetitle was available within entries.tpl, and detecting it meant the template logic could skip whatever code we did not want to use in entries.tpl for any page that had a staticpage_pagetitle.

s9y 1.7 changed all this. The value of $staticpage_pagetitle is no longer available within entries.tpl in s9y >=1.7, though it IS still available in index.tpl. I have set up a quick demo to show this using 2k11 and s9y 1.7.8. Static Page and Contact Form. Navlinks on that page will allow you to switch back and forth between the two pages. I have modified 4 files within 2k11 (index.tpl, entries.tpl, plugin_staticpage.tpl, plugin_contactform.tpl) only to emit comments showing the beginning and end of those tpl's.

It seems to me, we either need a way to generate static pages without using entries.tpl, or we again need a smarty way of bypassing what we do not need within entries.tpl, as we had in s9y <1.7.

User avatar
Don Chambers
Regular
Posts: 3638
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: static pages using entries.tpl, revisited

Post by Don Chambers » Sat Mar 22, 2014 6:59 pm

BTW - the modified tpls can be found here: http://www.optional-necessity.com/uploa ... c-test.zip

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: static pages using entries.tpl, revisited

Post by Timbalu » Sat Mar 22, 2014 8:00 pm

For me your examples show the right behaviour, while the index.tpl and all plugin_*.tpl files ('plugin scope') have that var, since assigned through staticpages, as you see by isset(staticpage_pagetitle). The entries.tpl file does not have it, since build independently, which is a different scope. With Smarty2 - I think - we had the same behaviour, but it wasn't taken strict, like with Smarty3 now. So again, a Smarty2 check for {if $staticpage_pagetitle ==''} was even true, when this var wasn't set at all.

Since your 2k11-static-test.zip is empty, I cannot see what you have changed.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
Don Chambers
Regular
Posts: 3638
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: static pages using entries.tpl, revisited

Post by Don Chambers » Sat Mar 22, 2014 8:41 pm

Timbalu wrote:Since your 2k11-static-test.zip is empty, I cannot see what you have changed.
Uploaded again. Try to download again.

User avatar
Don Chambers
Regular
Posts: 3638
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: static pages using entries.tpl, revisited

Post by Don Chambers » Sat Mar 22, 2014 11:36 pm

Zipfile updated again to reflect additional comments: http://www.optional-necessity.com/uploa ... c-test.zip
With Smarty2 - I think - we had the same behaviour, but it wasn't taken strict, like with Smarty3 now. So again, a Smarty2 check for {if $staticpage_pagetitle ==''} was even true, when this var wasn't set at all.
Not quite sure what you meant by "strict", but compare the 2k11 example running s9y 1.7.8 to a kinetic example running s9y 1.6.2.

Like 2k11, the kinetic template's entries.tpl also does not initially know the value of $staticpage_pagetitle.... however, after {serendipity_hookPlugin hook="entries_header" addData="$entry_id"} is processed, which generates the static page content (and anything else called by that hook), entries.tpl then has access to the value of $staticpage_pagetitle. This does not occur in s9y >=1.7

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: static pages using entries.tpl, revisited

Post by Timbalu » Sun Mar 23, 2014 9:52 am

Before I start to debug it this way, which does not really help to understand, since Smarty 3 in something different using OOP scopes, could you please give me a exact testcase what for a

Code: Select all

{if $staticpage_pagetitle ==''} do what? {/if}
question is definitely needed to be placed inside the entries.pl.

Some time ago we had something "~similar" with serendipity_event_entrypaging, which stopped working with Smarty3 in entries.tpl too. It was not even possible to capture the var to bring it into entries.tpl scope. There the easy solution was to move $entrypaging into content.tpl, since not making any sence in entries.tpl, while on top or bottom only.

That is why I ask to know, why it needs to be placed in entries.tpl, since in content.tpl it would be available!

PS.
The one and only relevant part for staticpages output in entries.tpl is this line

Code: Select all

{serendipity_hookPlugin hook="entries_header" addData="$entry_id"}
In case of a staticpage, all other is empty, since there is no $entries array, $plugin_clean_page and $footer_* vars and no {serendipity_hookPlugin hook="entries_footer"} available.

But what you can do in entries.tpl is this, ie:

Code: Select all

{capture name="pheh" assign="pluginHook_entries"}{serendipity_hookPlugin hook="entries_header" addData="$entry_id"}{/capture}
{if !empty($pluginHook_entries)}
<section id="section_hookPlugin_entries">
  {$pluginHook_entries}
</section><!-- // "id:#section_hookPlugin_entries" end -->
{else}
<p>No staticpage available!</p>
{/if}
Though I still would like to know why you need that staticpage_pagetitle question in entries.tpl
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
Don Chambers
Regular
Posts: 3638
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: static pages using entries.tpl, revisited

Post by Don Chambers » Sun Mar 23, 2014 4:54 pm

Timbalu wrote:...could you please give me a exact testcase what for a

Code: Select all

{if $staticpage_pagetitle ==''} do what? {/if}
question is definitely needed to be placed inside the entries.pl.
The only thing I was using that for, was to avoid every line of code in entries.tpl except {serendipity_hookPlugin hook="entries_header" addData="$entry_id"} for instances when a staticpage_pagetitle exists. This happens, at minimum, for static pages and contact forms. I do not know if there are other pages that generate a staticpage_pagetitle. Are there others??


Timbalu wrote:Some time ago we had something "~similar" with serendipity_event_entrypaging, which stopped working with Smarty3 in entries.tpl too. It was not even possible to capture the var to bring it into entries.tpl scope. There the easy solution was to move $entrypaging into content.tpl, since not making any sence in entries.tpl, while on top or bottom only.

That is why I ask to know, why it needs to be placed in entries.tpl, since in content.tpl it would be available!

PS.
The one and only relevant part for staticpages output in entries.tpl is this line

Code: Select all

{serendipity_hookPlugin hook="entries_header" addData="$entry_id"}
In case of a staticpage, all other is empty, since there is no $entries array, $plugin_clean_page and $footer_* vars and no {serendipity_hookPlugin hook="entries_footer"} available.

But what you can do in entries.tpl is this, ie:

Code: Select all

{capture name="pheh" assign="pluginHook_entries"}{serendipity_hookPlugin hook="entries_header" addData="$entry_id"}{/capture}
{if !empty($pluginHook_entries)}
<section id="section_hookPlugin_entries">
  {$pluginHook_entries}
</section><!-- // "id:#section_hookPlugin_entries" end -->
{else}
<p>No staticpage available!</p>
{/if}
Though I still would like to know why you need that staticpage_pagetitle question in entries.tpl
Are pages with staticpage_pagetitles the only pages generated with {serendipity_hookPlugin hook="entries_header" addData="$entry_id"}?? If so, using a derivation of your idea above, could we simply use this in content.tpl to completely avoid entries.tpl for pages with a staticpage_pagetitle:

Code: Select all

{if isset($staticpage_pagetitle)}
    {serendipity_hookPlugin hook="entries_header" addData="$entry_id"}
{else}
    {$ENTRIES}
    {$ARCHIVES}
{/if}
note: content.tpl contains more code than what I have shown above.. just showing the portion that relates to my question....

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: static pages using entries.tpl, revisited

Post by Timbalu » Sun Mar 23, 2014 5:59 pm

Hmm
I also have thought about moving the hook out of entries into content, but there must have been a reason to put it in...
I know more than 10 plugins generating and assigning a $staticpage_pagetitle var, since this is a blog system with either blog entries or static (entries/pages). And the 'entries_header' hook may contain more than a staticpage_pagetitle var, so it is a need to not make it depending on staticpages solely.

So why don't you leave the hook in entries.tpl, move any extra kinetic added content out of entries.tpl into content.tpl and just do something like:

Code: Select all

{if $staticpage_pagetitle == ''}
    set something
{/if}
    {$ENTRIES}
    {$ARCHIVES}
?
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
Don Chambers
Regular
Posts: 3638
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: static pages using entries.tpl, revisited

Post by Don Chambers » Mon Mar 24, 2014 12:53 am

Timbalu wrote:Hmm
I also have thought about moving the hook out of entries into content, but there must have been a reason to put it in...
yeah, but those reasons might have been so long ago that no one even remembers the reason why! :lol:
Timbalu wrote:I know more than 10 plugins generating and assigning a $staticpage_pagetitle var, since this is a blog system with either blog entries or static (entries/pages).
Any chance you have those documented somewhere? The only ones I can think of are static pages, and contactform. In both cases, the page is rendered through a tpl specific to that plugin - which is why I do not think either of them (or any other plugin using its own smarty tpls) should ever process entries.tpl. Additionally, maybe these plugins need something more unique to identify them if so many are using staticpage_pagetitle?
Timbalu wrote:And the 'entries_header' hook may contain more than a staticpage_pagetitle var, so it is a need to not make it depending on staticpages solely.
Do we know if any other vars are contained in that hook when staticpage_pagetitle exists?
Timbalu wrote:So why don't you leave the hook in entries.tpl, move any extra kinetic added content out of entries.tpl into content.tpl and just do something like:

Code: Select all

{if $staticpage_pagetitle == ''}
    set something
{/if}
    {$ENTRIES}
    {$ARCHIVES}
?
How do you see that as any better than what I proposed?

I STRONGLY believe that static pages should not be using entries.tpl. Static pages have their own tpls. An option exists within static pages (and contact forms) to render the output to look like an entry ({if $staticpage_articleformat}), which seems to imply ("looks like output generated by entries.tpl"). This logic is processed solely within the static pages, not in entries.tpl. Contact forms also have their own smarty tpls, and should likewise not use entries.tpl (IMHO). We have other purpose-specific templates, such as entries_archives.tpl and entries_summary.tpl. I think the time has come for static page output (and other plugins setting staticpage_pagetitle) to "live" solely within their own tpls, and not use entries.tpl for anything.

User avatar
Don Chambers
Regular
Posts: 3638
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: static pages using entries.tpl, revisited

Post by Don Chambers » Mon Mar 24, 2014 10:14 pm

I have reviewed all "additional plugins" to determine which seem to be setting staticpage_pagetitle. The majority of these plugins render their content with the expectation that they are NOT going to be rendered via entries.tpl.

In the plugin serendipity_event_cal, I found this comment just prior to the code setting staticpage_pagetitle: "/* templates detection that this is not a regular entry view and avoid processing entries.tpl, which will obviously contain serendipity_Entry_Date, etc. */" I am in total agreement - page types that set a staticpage_pagetitle should not be using entries.tpl, as they are probably already emitting their own html structure, either directly, or through a plugin-specific tpl.

Plugins emitting their own html (not using tpls) which include an option to "format as article":
  • serendipity_event_pollbox.php
  • serendipity_event_externalphp.php
  • serendipity_event_customarchive.php
Plugins using tpls which include an option to "format as article". Tpl's use typical article/entry structure beginning with .serendipity_EntryDate:
  • serendipity_event_staticpage
  • serendipity_event_contactform
Plugins using tpls which do NOT include an option to "format as article". Tpl's use typical article/entry structure beginning with .serendipity_EntryDate:
  • serendipity_event_usergallery.php
  • serendipity_event_suggest.php
  • serendipity_event_guestbook.php
  • serendipity_event_downloadmanager.php
  • serendipity_event_cal.php
The following plugins set staticpage_pagetitle, but behave slightly differently than those above as follows:

serendipity_event_wrapurl.php - emits its own containing div. Would not want entries.tpl's html structure that typically contains serendiipity_EntryDate. All content is emitted within an iframe.

serendipty_event_userprofiles.php - uses its own tpl. staticpage_pagetitle does not seem to be correctly assigned - is not detected using isset, empty, if =''.

serendipity_event_thumbnails.php This plugin doesn't seem to work as expected. It does NOT output its own entry style html, nor use its own tpl. This is the only plugin I found that would benefit from being output via entries.tpl. **EDIT**: This plugin has a dependency on serendipity_event_photoblog.php to work (a little) as expected.

serendipity_event_forum.php - uses own tpls, but tpls do not use typical entry html structure, ie class serendipity_EntryDate.

The issue here of why most plugins setting staticpage_pagetitle should NOT be using entries.tpl is this:

entries.tpl typically creates an html structure that is duplicated by the plugin output - either directly from the php file, or from a plugin's own smarty tpl's.

So how about we finally get a way to generate these non-entry pages without using entries.tpl, or at least a logical test that lets us avoid entries.tpl?? A different hook? A different $view? Perhaps another variable in these plugins which specifically let's us know that this plugin renders to its own template (ie, $serendipity['smarty']->assign('plugin_tpl', true); )??? Then we could do something like:

{if !$plugin_tpl}.... continue with entries.tpl... {/if}

User avatar
Don Chambers
Regular
Posts: 3638
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: static pages using entries.tpl, revisited

Post by Don Chambers » Tue Mar 25, 2014 4:01 pm

This issue affects all templates. Does anyone have any input?

User avatar
onli
Regular
Posts: 2264
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: static pages using entries.tpl, revisited

Post by onli » Tue Mar 25, 2014 4:09 pm

It is a bit voodoo for me. Though from a distance it sounds like a good idea to just render staticpages via their own template, ignoring entries.tpl, and giving index an appropriate variable to check for.

User avatar
Don Chambers
Regular
Posts: 3638
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: static pages using entries.tpl, revisited

Post by Don Chambers » Tue Mar 25, 2014 5:51 pm

I agree - I believe plugins with a staticpage_pagetitle should not be using entries.tpl. Most use their own tpl's anyway, and those that do not, could be modified to do so.

$staticpage_pagetitle can no longer be determined within entries.tpl. It can, however, be detected in a plugin's own tpl (if used), as well as index.tpl and content.tpl. Above I proposed the creation of a new variable which would indicate that a plugin has its own tpls. However, I think that variable would likely not be accessible from entries.tpl, just as staticpage_pagetitle is not.

All templates need a way to detect staticpage_pagetitle, and avoid most, if not all, of entries.tpl. I have made my suggestions in this thread, but am not the experienced coder many others here are. Does anyone have a solution to recommend?

User avatar
garvinhicking
Core Developer
Posts: 30020
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: static pages using entries.tpl, revisited

Post by garvinhicking » Wed Mar 26, 2014 3:33 pm

Hi!

Coining it like "plugins should not be using entries.tpl" is a bit misleading. Actually, entries.tpl CALLS plugins like the ones mentioned, not "plugins call entries.tpl".

The best way would be to restore pre Smarty3 behaviour, and make sure that $staticpage_pagetitle os propagated globally to every sub-template. Ian, do you know how to achieve that?

Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: static pages using entries.tpl, revisited

Post by Timbalu » Wed Mar 26, 2014 6:35 pm

garvinhicking wrote:Ian, do you know how to achieve that?
No, I don't.
I still would like to know why we should care actually, since I can't see a need to ask for $staticpage_pagetitle in entries.tpl at all.

The entries.tpl file is either empty by blog $entries and used to output the staticpage called by the hook in this case or otherwise loops and shows the blog entries.

IMHO it doesn't help to reclaim this var was there (pretending to be empty) with Smarty2, since nothing assigned it to entries.tpl before. The entries.tpl is, beside of the hooks calling plugins, mainly just a foreach block, looping blog $entries, enclosed by the 'entries_header' and 'entries_footer' hooks. This part between the hooks is not meant to be used for something else. The $entries loop is not processed when empty, which is the case when $view is 'plugin', so there is no need to enclose it with something extra. If that was done by Kinetic in prior, it was the wrong solution, in my eyes.

But, if Dons upper suggestion with moving into content.tpl works with a Smarty3 ready Kinetic template, all the better, even if it would just be a workaround to safe some structural work.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

Post Reply