TinyPortal

[Antechinus]

Eh. @rjen Where did your post go?

[@rjen]

Agreed, still looking into this, but it needs some more thought and time: there are so many variables at play outside the board index that need to be taken into consideration.

What bothers me most is that it works fine in every other section and page of the forum without the need to set this calculated max-width. It seems that there must be a easier, more consistent approach to deal with this going forward...

[@rjen]

Eh. @rjen Where did your post go?

sorry, I posted and reread it only to find that I may not have the complete picture, so I deleted it. You were so quick to respond though... 

This was the message I deleted...

Thanks again for your time and effort, but this also has some issues...

First: the check against the $context['tp_panels'] needs to be reversed: afaik the panel will only show in there if it is in fact deactivated...

Second: checking $context['TPortal']['showcollapse'] for the width calculation is not relevant: that variable only controls if the show / collapse icons are showing, not if the panel is actually collapsed itself

After changing the logic slightly it does work initially, but the collapse function will actually set the sidebars to display=none while not updating the context, so the width calculation will be off and result in white spaces left or right...

At this time I am going to adopt the changes for css and remove the redundant style="clear: both;" statements. The fancy css that I had put in to the board index for child boards may just no be supported in TinyPortal going forward. This seems to have a bit too much implications atm...

[Antechinus]

Agreed, still looking into this, but it needs some more thought and time: there are so many variables at play outside the board index that need to be taken into consideration.

Ok, but don't all areas rely on the same basic panels?

What bothers me most is that it works fine in every other section and page of the forum without the need to set this calculated max-width. It seems that there must be a easier, more consistent approach to deal with this going forward...

That's the case with the default theme, yes. But if any custom theme starts using flex or CSS columns on other pages you are likely to end up with similar issues, or simply if anyone modifies the default CSS on the board index.

So if the width issue is bulletproof to start with, less hassle down the track, because the portal will work with any custom theme or any modified version of the default.

ETA: And if there are child boards, any edits to board index CSS are likely to affect message index too.

[@rjen]

Maybe we should stock with the table layout for panels after all... 

[Antechinus]

Ok suit yourself, but then you still have that webkit bug to find a solution to. Which, I suspect, is also going to rely on determining the correct max-width.

[@rjen]

Plenty of stuff to figure out still with all the css options... mind you, I was not dismissing the flex option, just joking...

thanks for all your support so far.
It seems that this small bug brings a lot of additional options to play with...

[Antechinus]

Lol. Ok, what is the variable that determines if a panel is shown or hidden? There must be one.

I know it's using cookie values too, but they don't appear to control the panel itself (I think they just change the +/- icons for the upshrinks).

This controls whether the panel is enabled, yes?

Code Select Expand

$context['TPortal']['leftpanel']==1
With ==0 being disabled?

[@rjen]

These toggles are actually causing more issues than I thought.

On small screen the toggles icm with flex cause white spaces when one of the side panels is switched off (screen width smaller than 900px with both bars active). Meh...

Wether a panel is showing is a two-step approach.

First there is the $context['TPortal']['leftpanel'] and $context['TPortal']['rightpanel'] that determine if a panel is set to show on the page. If these are '1' the side panels are active

Secondly there is the context element $context['tp_panels'] that actually contains any panels that need to be suppressed because the user has set a toggle to suppress..

Thirdly the $context['TPortal']['showcollapse'] value indicates if the 'collapse' option is even active: if that is not then the second switch is igored...
Value 1 indicates that the user has the option to collapse panels

So the left panel will show for this condition:

$context['TPortal']['leftpanel']==1 && (!in_array('tpleftbarHeader',$context['tp_panels']) ||  $context['TPortal']['showcollapse']==0)

[Antechinus]

First there is the $context['TPortal']['leftpanel'] and $context['TPortal']['rightpanel'] that determine if a panel is set to show on the page. If these are '1' the side panels are active.

Yup, thought so.

Secondly there is the context element $context['tp_panels'] that actually contains any panels that need to be suppressed because the user has set a toggle to suppress.

Aha. That's the bit I was chasing.

Thirdly the $context['TPortal']['showcollapse'] value indicates if the 'collapse' option is even active: if that is not then the second switch is ignored.
Value 1 indicates that the user has the option to collapse panels.

Cool.

So the left panel will show for this condition:

Code Select Expand

$context['TPortal']['leftpanel']==1 && (!in_array('tpleftbarHeader',$context['tp_panels']) ||  $context['TPortal']['showcollapse']==0)

Ok, so this should not be hard then. It just has to have that as the condition for a ternary, then it calls the panel width if that condition is true, and subtracts the panel width (or both panel widths, depending) from 100%. Easy.

I'll mess around with it tomorrrow.

[@rjen]

Ok, so this should not be hard then. It just has to have that as the condition for a ternary, then it calls the panel width if that condition is true, and subtracts the panel width (or both panel widths, depending) from 100%. Easy.

Probably we will also need to substract the margin values for left and right panel that are set in context too...

[Antechinus]

Eh? You have margins? Awesomesauce.

This is going to end up being a gruesome ternary. Might make more sense to turn it all into a simple $thing output before the div tag, so the markup stays looking halfway sane. Otherwise anyone who wants to check it out will be chasing ternaries across country for miles.

[Antechinus]

Hey hang on: what's up with this?

Code Select Expand

<div id="tprightbarContainer" style="width:' ,$context['TPortal']['rightbar_width'], 'px;' , in_array('tprightbarHeader',$context['tp_panels']) && $context['TPortal']['showcollapse']==1 ? 'display: none;' : '' , '" >
<div id="tprightbarHeader" style="' , in_array('tprightbarHeader',$context['tp_panels']) && $context['TPortal']['showcollapse']==1 ? 'display: none;' : '' , '">
If you're setting display: none; on the outer div, why do you need to declare it again on the inner div?

Both divs have exactly the same conditions set, so hiding the outer one will hide the inner one too. The current code makes no sense to me.

[@rjen]

Not sure, there is a LOT of history in the TinyPortal code and templates.

I have been cleaning up and cleaning out for a while now, but there are still bits that need work...

[Antechinus]

OK, probably leftovers then. I'll mess around with it tomorrow.

[@rjen]

Just installed the latest version on the most up-to-date SMF, and it's just not displaying correctly for me when I'm logged in as an admin?

When I go into the forum listings, the page stretches out to the right.

If I read a thread it's fine, but when I go to quick edit I then again have the screen stretching way off the side of my phone. Any ideas?

Ok, thanks to Antechinus I managed to create a permanent fix for this.

You did not mention what TinyPortal version you are using, so I assume it is the latest (TinyPortal version 2.2.1)
The fix will be in the next TP release, but if you want to fix it now you can upload attached css files to you /Themes/default/css folder and replace the files there.

After that remember to clear your browser cache to load the new css files...

I need to come back on the css files I posted before. Though they work for most use cases there are still some inperfections with those files. I would like to request the moderators to delete these attachments from the referenced message please.

As a quick fix for this issue anyone who has a problems with the quick moderation actions on mobile: you can add this little piece of code to a css file to fix it.

Code Select Expand

/*Quick and dirty fix for quickactions */
@media screen and (max-width: 720px) {
#quick_actions > select[name="qaction"] {
    width: 80px;
}
}

Any css file in your theme should work, if you want it to be fixed for all themes you can add it to the empty tp-custom.css file you find in the folder:
/Themes/default/css

[Antechinus]

So the left panel will show for this condition:

$context['TPortal']['leftpanel']==1 && (!in_array('tpleftbarHeader',$context['tp_panels']) ||  $context['TPortal']['showcollapse']==0)

Ok, I tried this. Doesn't seem to get me anywhere.
I made up a little test paragraph, to echo the output of test conditions:

Code Select Expand

echo '
<div id="mainContainer" style="clear: both;">';

echo '
<p style="padding:1em;font-weight:700">
Echo output of conditions:
Leftbar_test = ', $leftbar_test;
echo '
</p>';

// TinyPortal integrated bars
if($context['TPortal']['leftpanel']==1) {
echo '

Then I set up the test output, just before that, with the condition you gave:

Code Select Expand

$leftbar_test = ($context['TPortal']['leftpanel']==1 && (!in_array('tpleftbarHeader',$context['tp_panels']) ||  $context['TPortal']['showcollapse']==0)) ? $context['TPortal']['leftbar_width'] :'';
That echoes 200 when the left bar is enabled and not collapsed. So far, so good.

However, it also echoes 200 when the left bar is enabled and collapsed. Not so good.

So then I take a look at the conditions for displaying (or not) the bar by setting (or not) display: none; in the markup.

Code Select Expand

// TinyPortal integrated bars
if($context['TPortal']['leftpanel']==1) {
echo '
<div id="tpleftbarContainer" style="width:' , ($context['TPortal']['leftbar_width']) , 'px; ' , in_array('tpleftbarHeader',$context['tp_panels']) && $context['TPortal']['showcollapse']==1 ? 'display: none;' : '' , '" >
That boils down to:

Code Select Expand

($context['TPortal']['leftpanel']==1) && in_array('tpleftbarHeader',$context['tp_panels']) && $context['TPortal']['showcollapse']==1 ? 'display: none;' : '' , '" >
IOW, this should echo the left bar width when the bar is collapsed:

Code Select Expand

$leftbar_test = ($context['TPortal']['leftpanel']==1) && in_array('tpleftbarHeader',$context['tp_panels']) && $context['TPortal']['showcollapse']==1 ? $context['TPortal']['leftbar_width'] :'';
But, it doesn't. It echoes nothing, even though it is the same condition that sets display: none; when the bar is collapsed.

But, that only applies if you just collapse the left bar without doing anything else. If you refresh the page after collapsing the left bar (or after un-collapsing it), suddenly it behaves correctly: displays the width when bar is collapsed, and displays nothing when bar is not collapsed.

So the problem is not the logic. The problem is that the markup can't access it without refreshing the page.

So, on that basis I re-tested your original condition. Same result. It will echo what it is meant to echo, but it requires a page refresh to do it.

Which makes sense once you think about it, because the collapse is being handled by javascript, not directly from the db, so setting a defined width on the centre panel container is going to require javascript.

[@rjen]

Makes sense. 

So to make it bullet proof I may have to Learn JavaScript.

That's not in my resume atm, but I can make a project out of it when I have a little more time...

It seems that using the display:table-cell may actually be in here to work around this, because that seems to automatically fill the width of the screen when one of the side bars is collapsed...

I keep learning everyday...

[Antechinus]

Table-cell is probably worth exploring. It can give great results for some things (auto filling width, as you say) but IIRC (haven't used it for a while) it can also have odd overflow problems at times. Worth checking though, and easy enough to check.

I was thinking the existing arrangement is still more complicated than it needs to be. Really, the only place you need anything fancy is the container that holds the sidebars and the main board index. The rest is just ordinary divs, so is basic and easy

And the only time you need anything fancy is when the sidebars are sidebars. As soon as the screen gets narrow enough for them to stack underneath the board index, you can go straight to flex and call 100% width on your central div (that holds the board index).

So I really can't see any use for the display: table-caption/footer-group/whatever. I think that is all just confusing the issue, and things can be a fair bit simpler.

ETA: It would be good to have a pure CSS solution that didn't need javascript. Not that there's really anything wrong with js (sidebar show/hide relies on it anyway) but doing it with CSS should be less code to frig around with.

[@rjen]

Guess you are right there. The problem with the varying width only applies to the side bars next to the middle panels (excluding top and bottom div)

It would also include changing the template though: because at this time all panels are in the main container.

Could leave the table-cell on the side panels somehow and change the main structure more to flex.

I must say, apart from the minor bug that started this investigation the display-table has (though somewhat complicated) proven to be pretty solid over the last years...