Copyright not showing on mobile theme when user signs out.

Prosper

The plugin "Copyright" does not show up on mobile theme after user signs out. It only shows when user is signed in the forum. Please why is it like that and is there a way to make the plugin (Copyright) show when user signs out from forum?

hgtonight

Hiya!

You need to add 'MobileFriendly' => TRUE, to the plugin info array.

peregrine

@hgtonight has the correct answer to your question..

however @prosper

Since you now know how to modify tpl files the other option you have that is theme based is just to directly add the copyright via the tpl in the footer.
similar to the way you changed things here.

minuses of plugin

then you can avoid the extra js overhead, minor as it may be.

advantages of plugin

• But the plugin is a simple, easy and effective way to go if you want the same thing on all themes and saves you the effort of changing the tpl of themes
• simple to turn on and off by just enabling and disabling plugin.

http://vanillaforums.org/discussion/27818/how-can-i-remove-vanilla-forum-footer-image-on-version-2-1-1

e.g. in tpl of mobile

 <div id="Foot">
        <div class="FootMenu">
        {nomobile_link wrap="span"}
          {dashboard_link wrap="span"}
          {signinout_link wrap="span"}
        </div>
      <p>  © 2014 Prosper, Inc. All rights reserved. </p>
      <a href="http://yoursite.com" class="PoweredByProsper" > © 2014 Prosper. All rights reserved.</a>
        {asset name="Foot"}
     </div>

tpl of of the non mobile theme

 <div id="Foot">
    <div class="Row">
       <p>  © 2014 Prosper, Inc. All rights reserved. </p>
      <a href="http://prosperssite.com" class="PoweredByProsper" > © 2014 Prosper. All rights reserved.</a>

      {asset name="Foot"}
    </div>

then you can style with custom.css based on class PoweredByProsper

vrijvlinder

Thanks for helping guys, however this plugin sends the copyright mark after the foot. It is not in the footer, it is appended to the body.

The reason for this is to not have to use the footer for this so other things can go in the footer like footbox plugin.

This plugin adds an extra div after the Foot. Please give me a link so I can see what is going on.

Prosper

I have found out why copyright information failed to show on mobile theme discussion list/pages. Another addon "Infinite Scroll 1.3.1" by @Bleistivt was the cause. "Infinite Scroll 1.3.1" also disrupted two other plugins ("Button Bar" and "imageupload") on mobile theme.
Please @Bleistivt could you update "infinite scroll" to work well with other plugins? Thank you.

Bleistivt

InfiniteScroll doesn't enable on mobile devices as it is not mobile friendly.

But if it is a problem on desktop too, I will look into it.
Could you open a thread under my plugin and explain the error or attach a screenshot?

vrijvlinder

As I look at infinitescroll plugin, I do not see code which disables the loading of the js and css file for the plugin on mobile.

public function Base_Render_Before($Sender) {
        $Session = Gdn::Session();
        //this adds the Ressources if only the sticky Panel is enabled
        if (!C('Plugins.InfiniteScroll.FixedPanel', false) ||
            !$this->GetUserMeta($Session->UserID, 'Enable', true, true) ||
            inSection(array('Profile', 'Dashboard')))
            return;

        $Sender->AddDefinition('InfiniteScroll_FixedPanel', true);
        $Sender->AddJsFile($this->GetResource('js/infinitescroll.js', false, false));
        $Sender->AddCssFile($this->GetResource('design/infinitescroll.css', false, false));
    }

Maybe add

public function Base_Render_Before($Sender) {
        $Session = Gdn::Session();

            if(IsMobile()){
 return;
}
else
{
        //this adds the Ressources if only the sticky Panel is enabled
        if (!C('Plugins.InfiniteScroll.FixedPanel', false) ||
            !$this->GetUserMeta($Session->UserID, 'Enable', true, true) ||
            inSection(array('Profile', 'Dashboard')))
            return;

        $Sender->AddDefinition('InfiniteScroll_FixedPanel', true);
        $Sender->AddJsFile($this->GetResource('js/infinitescroll.js', false, false));
        $Sender->AddCssFile($this->GetResource('design/infinitescroll.css', false, false));
    }
}

hgtonight

@vrijvlinder said:
As I look at infinitescroll plugin, I do not see code which disables the loading of the js and css file for the plugin on mobile.

If MobileFriendly is not set in the plugin array (or set to FALSE), that plugin is not loaded when Vanilla detects a mobile device.

No need to add your own checks.

vrijvlinder

That may be in theory but I had to add it to a couple of plugins because even though mobilefreindly true was not set , it loaded. And even using mobilefriendly false it loaded.

So I added that to make sure it would not load.

peregrine

@vrijvlinder @hgtonight @Bleistivt

I'm gonna have to place my hat in the ring with @vrijvlinder on this one.

/infinitescroll.js does indeed get loaded in mobile theme.

hgtonight

@vrijvlinder said:
That may be in theory but I had to add it to a couple of plugins because even though mobilefreindly true was not set , it loaded. And even using mobilefriendly false it loaded.

I just found out that the call to remove the unfriendly plugins is in a themehook for the mobile theme.

Good catch.

I would highly suggest you add this to your mobile themehooks file:

/** Remove plugins that are not mobile friendly! */
public function Gdn_Dispatcher_AfterAnalyzeRequest_Handler($Sender) {
   // Remove plugins so they don't mess up layout or functionality.
   if (in_array($Sender->Application(), array('vanilla', 'conversations')) || ($Sender->Application() == 'dashboard' && in_array($Sender->Controller(), array('Activity', 'Profile', 'Search')))) {
      Gdn::PluginManager()->RemoveMobileUnfriendlyPlugins();
   }
   SaveToConfig('Garden.Format.EmbedSize', '240x135', FALSE);
}

This is from the default mobile theme.

Bleistivt

that is... weird.

@vrijvlinder Great find!

this should happen somewhere here
https://github.com/vanilla/vanilla/blob/master/library/core/class.pluginmanager.php#L463-L471

My first suspicion is that it is this line:

$this->UnRegisterPlugin($PluginName.'Plugin');

I have chosen to omit "plugin" from the classname, that could be the cause.

peregrine

yes... @Bleistivt

class InfiniteScrollPlugin extends Gdn_Plugin {

works

---

class InfiniteScroll extends Gdn_Plugin {

doesn't work

I think you've go it solved.

good catch finding initial issue @prosper

vrijvlinder

@hgtonight said:
This is from the default mobile theme.

Yes , @peregrine did you test that on the default mobile theme as I think you did ?

@Bleistivt said:
that is... weird.

vrijvlinder Great find!

this should happen somewhere here
https://github.com/vanilla/vanilla/blob/master/library/core/class.pluginmanager.php#L463-L471

My first suspicion is that it is this line:

$this->UnRegisterPlugin($PluginName.'Plugin');

I have chosen to omit "plugin" from the classname, that could be the cause.

I don't think it should matter is it's class.infinitescroll.plugin.php or default.php if that is what you mean.

From what I get from the plugin manager code is it already checks to see if there is a class name or if it is default. But I could be off on a tangent....

The thing is that even with that in the themehooks of the mobile theme, the MobileFriendly false in a plugin does not work always. I would almost go to say it is a bug.

Bleistivt

@peregrine thanks, I was just about to test it myself. Giving back the speedy badge.

Can confirm, it still enables on the default mobile theme.
Could be either a bug or the need for stricter naming conventions for plugins

peregrine

@vrijvlinder said
Yes , @peregrine did you test that on the default mobile theme as I think you did ?

yes.

I don't think it should matter is it's class.infinitescroll.plugin.php or default.php if that is what you mean.

its the name that is used on the extends line within the file.

(not the file name - that is insignificant as far as mobile theme hooks goes).

meaning

class InfiniteScrollPlugin extends Gdn_Plugin {

vrijvlinder

Oh good catch @peregrine that part totally got past me as a possibility , I was looking for what gets loaded when, however all my plugins have that and we still run into the issue.

The only way for me to make sure and not depend on themes or hooks is to declare it from the Base render since that definitely works for me using any mobile theme.

peregrine

@virjvlinder
Oh good catch @peregrine that part totally got past me as a possibility , I was looking for what gets loaded when,

however all my plugins have that and we still run into the issue.

which plugins are you sure have issues without testing for mobile.

the only reason to test individually within plugin, is if it is mobile friendly.

if mobile friendly is false and the class name extends has a class (with Plugin in the name) thenamePlugin extends Gdn_Plugin, it seems that the themehooks should remove the plugin.

so it would be interesting to know which plugins fail to pass muster in the theory which may now be a hypothesis.

vrijvlinder

What I would like to know is where does it check for the Value of MobileFriendly. If it does not say MobileFriendly at all it gets removed in theory correct? Based on the plugin manager file.

If it says MobileFriendly False nothing happens. In some cases even mobilefriendly true does not work either.

I don't think it should be left up to the themehooks of a theme to remove the plugins. I think the plugin should dictate if it is or not friendly and specify it. And the manager should remove it based on the value true or false of mobilefriendlyness.

Otherwise the function is useless if a theme does not specify to remove them.

Bleistivt

Right now, a plugin is only removed if:

1. It does not explicitly have "MobileFriendly" => true
   AND
2. The themehooks make a call to Gdn::PluginManager()->RemoveMobileUnfriendlyPlugins();
   AND
3. The plugins classname ends with "Plugin"

The second one is debatable, but I'd say the last one is a bug.

I have seen many plugins that don't have classnames ending with "Plugin", there are even 2 in the official addons repo (Vanoogle and CssThemes)

hgtonight

@Bleistivt said:

The second one is debatable, but I'd say the last one is a bug.

I have seen many plugins that don't have classnames ending with "Plugin", there are even 2 in the official addons repo (Vanoogle and CssThemes)

I am liable to agree.