xbootstrap theme and slider

[GregMage]

When a module is on the home page, the slider is not displayed.

`<{if $xoops_dirname == "system"}>

` it's that what you want to do?

[geekwright]

Very good question. That seems inconsistent.

It probably would be best to add a 'xoops_startpage' assign in \xos_opal_Theme::xoInit() so the theme could make the decision? It could default to 'system' as well. Also, should add the assign to redirect_header() for consistency.

Sounds like that would be a good upgrade.

Do you have any ideas? I would be happy to hear any alternatives.

[GregMage]

I think it's a good idea to put the variable 'xoops_startpage' assign in \xos_opal_Theme::xoInit().

How can we know if we are on the home page? use $_SERVER['PHP_SELF']?

[geekwright]

We could assign the config value for startpage to xoops_startpage, and assign xoops_script from the basename() of $_SERVER['SCRIPT_FILENAME'].

My first thought was xoops_requesturi would work, but it would take a lot of code to process in the template, since siteurl/ and siteurl/index.php both refer to 'home.'

$_SERVER['PHP_SELF'] can be corrupted by user input in some cases, i.e. siteurl/index.php/garbage/

That leaves us with $_SERVER['SCRIPT_FILENAME'] as the primary choice, and $_SERVER['SCRIPT_NAME'] as a fall back if SCRIPT_FILENAME isn't set.

That should make it easy to adapt as needed in the templates with no parsing or multiple values to check.
<{if $xoops_dirname == $xoops_startpage}> - we are in the 'home' module
<{if $xoops_script == 'index.php'}> - we are on the main page.

Would that work?

I also considered setting a $xoops_default_page variable as a boolean instead of using xoops_script might be simpler and cleaner. I am leaning toward the xoops_script, since it provides data to the presentation layer, so the logic stays in the templates, while the xoops_default_page idea makes a presentation decision and passes it to the template. But, either one would work.

[mambax7]

We already have it in System's preloads this:

if (is_object($GLOBALS['xoopsTpl'])) {
   $GLOBALS['xoopsTpl']->assign('homepage', true);
}

So XOOPS can assign "$homepage", which then I can test in the theme to either assign the "one page" part of the theme, or the "module part":

<{if $homepage}> 
<{includeq file="$theme_name/pages/home.tpl"}> 
<{else}> 
<!-- module part--> 
<{/if}>

see the discussion in: http://xoops.org/modules/news/article.php?storyid=6734

Could we use this approach?

[mambax7]

Insraq also discussed this issue in his book "Design for XOOPS": https://goo.gl/DByanU

[geekwright]

I forgot that was there, but this approach solves a larger set of issues, so it would be more flexible.

I also considered setting a $xoops_default_page variable as a boolean instead of using xoops_script might be simpler and cleaner. I am leaning toward the xoops_script, since it provides data to the presentation layer, so the logic stays in the templates, while the xoops_default_page idea makes a presentation decision and passes it to the template. ...

The $xoops_default_page variable IS your $homepage.

Consider this example. Right now, with xBootstrap, it triggers off of <{if $xoops_dirname == "system"}> to place the carousel for the home page. It also places that same carousel on each top level page that isn't part of a module, like register, inbox, view account. We are not currently providing a mechanism for the theme to control that without way too much work.

These issues are in addition to the problem of the carousel not showing on the landing page when you change the startpage.

I was actually considering the one page themes when I made this suggestion. Being able to interrogate both module and script in a standard way opens things up. Right now the one page themes are strapped on, not integrated to XOOPS. With this, in addition to a cool landing, you could for example do something special to target just the onboarding (registration) with a cool slick process, because you could target just that page.

Instead of making just one controllable page, this makes them all individually controllable. This is a superset, and what you already did could be readily accommodated. We can keep the $homepage variable (but maybe move its setup to the environment setup in xoInit().) But the longer I think about it, the more value I see in the proposed new variables.

There are more things needed, like some more flexibility with blocks and placement, like some things Eduardo is doing in RMCommon, but this would be a step forward all on its own.

[mambax7]

I am fine with whatever is more generic and flexible :)

[GregMage]

Me too!

[geekwright]

OK! @GregMage can you take this one?

[GregMage]

Ok, I'll make a proposal.

I can create a variable $xoops_page with more values. I use $_SERVER['SCRIPT_NAME'] to fill the variable $xoops_page.
Exemple:
in /htdocs/userinfo.php?uid=1 -------> $xoops_page = userinfo
in /htdocs/modules/xmcontent/viewcontent.php?content_id=38 -------> $xoops_page = xmcontent/viewcontent

The variable is initialized in xoInit().

I think it is simple and flexible.

what do you think?

[GregMage]

A first version: #197

Finally I use $_SERVER['SCRIPT_FILENAME']

[alain01]

Hi,
ok and how to differentiate :
in /htdocs/modules/xmcontent/viewcontent.php?content_id=38 -------> $xoops_page = xmcontent/viewcontent
and
in /htdocs/modules/xmcontent/viewcontent.php?content_id=15 -------> $xoops_page = xmcontent/viewcontent

same $xoops_page.
I need this variable for the active attribut on bootsrap navbar