News:

Wondering if this will always be free?  See why free is better.

Main Menu

TinyPortal

Started by lurkalot, February 12, 2005, 04:43:00 AM

Previous topic - Next topic

Antechinus

#3180
Yes, it's annoying that there's only a tiny bug with Webkit/Blink/whatever.

I checked out display: table; on #mainContainer, with display: table-cell; #tpleftbarContainer, #tprightbarContainer, and #centerContainer and, as I suspected, it's still vulnerable to custom theming blowing it apart. It's still going to need a defined width on  #centerContainer to make it bulletproof, so it's not really going to solve anything.

But, since the default floats are fine above 900px (or wherever anyone chooses to set the break point) and since #centerContainer can have a max-width: 100%; on it on widths < 900px, it should be fine with flex at <900px.

Antechinus

Hey this seems to be good in Firefox or Chrome, down to 360px wide, with the checkboxes selected, and with "too long for the box" content in the quick actions selects. And, it even handles the custom child boards in multiple columns, with hidden overflow. Unless you can find another hidden bug somewhere, I think this is the best option.

It's using the existing floats above 900px, so same behaviour as it has always had. It only brings in the new stuff where it needs it.
/* ------------------------------------------------------- */
/*    @TINY PORTAL
/* ------------------------------------------------------- */
@media (min-width: 0px) and (max-width: 900px) {
    #mainContainer {
        display: flex !important;
        flex-wrap: wrap;
        max-width: 100%;
    }
    #tpleftbarContainer {
        display: block !important;
        flex: 0 0 auto;
        order: 2;
        width: 50% !important;
    }
    #tprightbarContainer {
        display: block !important;
        flex: 0 0 auto;
        order: 3;
        width: 50% !important;
    }
    #centerContainer {
        display: block !important;
        flex: 1 1 auto;
        order: 1;
        width: 100% !important;
    }
}
@media (min-width: 0px) and (max-width: 500px) {
    #mainContainer {
        flex-direction: column;
    }
    #tpleftbarContainer, #tprightbarContainer, #centerContainer {
        width: 100% !important;
    }
}

Now, this is just a rough and brutal override on top of the default TP CSS. It can be simplified a bit once the old table-group-bananas-whatever is out of the way (less need of large hammers then). But, AFAICT, it works. :)

Antechinus

@rjen - Try these when you get a chance. Seems to be fine for me.

TPortal.php was edited on Lines 2162 & 2163, just to get rid some unnecessary logic now that #tpleftbarContainer and  #tprightbarContainer are gone. I don't know why they were ever included, as the only other places they seem to have been mentioned are the markup in TPBlockLayout.template.php, and the CSS (tp-style and tp-responsive).

All other panels are just wrapped in a #******Header div, so the extra #******Container divs just for the sidebars seemed pointless. Figured I might as well make them consistent with the other panels, for less crud. Everything still works and still looks the same.

Kept the existing #tpleftbarHeader and #tprightbarHeader (as they relate to $context) and just swapped CSS over to them where required. Changed the logic a bit, so it just skips all the roundframe crud in one hit if it's not required, then tests for 2.1 if roundframe is required (can't see the point of echoing the spans in 2.1).

Doing it with brackets seemed more sensible than trying to cram it all into a gnarly ternary. :)

Apart from that it's just a basic CSS cleanup to make things behave.

However: I tested the .roundframe option on the left bar (it works) but I did notice that although the admin GUI allows selecting .roundframe on all panels, it does not in fact work on all panels due to the lack of the required logic in the template. I assume this is a known issue. My 2c is that rather than trying to get it working on all panels, might make more sense to drop it.

Alternatively, given that roundframe in 2.0.x can be done with border-radius these days anyway, maybe just add a little something to tp-style.css to make 2.0.x do .roundframe on 2.1 markup (ie: div only, no spans required). That would simplify the logic in the template.

Antechinus

#3183
Actually this works really well, providing you don't mind adding a little to tp-stye.css to compensate for the lack of spans/images on 2.0.x.
// Tiny Portal left side bar - floated left by default.
if($context['TPortal']['leftpanel']==1) {
echo '
<div id="tpleftbarHeader"', ($context['TPortal']['useroundframepanels']==1) ? ' class="roundframe"' : '', ' style="width:', ($context['TPortal']['leftbar_width']), 'px;', in_array('tpleftbarHeader', $context['tp_panels']) && ($context['TPortal']['showcollapse']==1) ? 'display:none' : '', '" >
', TPortal_panel('left'), '
</div><!-- #tpleftbarHeader -->';
}

// Tiny Portal right side bar - floated right by default.
if($context['TPortal']['rightpanel']==1) {
echo '
<div id="tprightbarHeader"', ($context['TPortal']['useroundframepanels']==1) ? ' class="roundframe"' : '', ' style="width:', ($context['TPortal']['rightbar_width']), 'px;', in_array('tprightbarHeader', $context['tp_panels']) && ($context['TPortal']['showcollapse']==1) ? 'display:none' : '', '" >
', TPortal_panel('right'), '
</div><!-- #tprightbarHeader -->';
}

Then the CSS can do this:
#tpleftbarHeader.roundframe, #tprightbarHeader.roundframe {
/* Reduced padding for sidebars? */
padding: 10px;
/* Only required for 2.0.x. */
border: 1px solid #c5c5c5;
border-radius: 7px;
}

Although, I am starting to think the responsive CSS should be tweaked a bit. If you have both sidebars enabled on 900px it really is a bit much. Might make sense to bump the break point for layout if both sidebars are enabled. Given that the forum itself has responsive CSS based on the assumption that there will be no sidebars, shoving in two of them really borks things a bit.

So perhaps TP should take account of default 2.1 break points, then add the width of one or two sidebars to that, for deciding when to shuffle sidebar layout. Since TP assigns parent div classes based on 0, 1, or 2 sidebars, this should be easy.

@rjen

Thanks Antechinus, had no time to test your proposals yet.

Just a question: did you also test the behavior when collapsing one of the side panels? Does it work without JavaScript  now?

As for the roundframe stuff: I really do not want to spend too much time on 2.0 related layout changes now: this is legacy resulting from the old curve theme and though this can be simplified I personally want to focus on stuff that also helps for SMF 2.1.
Running SMF 2.1 with latest Tinyportal at www.fjr-club.nl
Testing SMF 2.1 with next version Tinyportal at test.fjr-club.nl

Antechinus

Yes, it's fine without extra javascript now. It's just bringing in the flex once things stack anyway, so the centre container is always 100%.

Quote from: @rjen on May 08, 2022, 01:40:23 AMAs for the roundframe stuff: I really do not want to spend too much time on 2.0 related layout changes now: this is legacy resulting from the old curve theme and though this can be simplified I personally want to focus on stuff that also helps for SMF 2.1.
In that case I'd just go with the simplified logic that suits 2.1 anyway. If anyone specifically wants the roundframe look on side panels in 2.0 it's easy to give them a CSS snippet for it.

@rjen

I have not had a chance to do full testing yet, but it seems there is one pesky little issue left...

when on screen small that 900px the sidebars push down, side by side: Collapsing one of the side bars then will result in an empty area on screen where the collapsed panel was... did you see that too?

You cannot view this attachment.

This where the old setup would automatically push the remaining panel to full screen. I personally prefer that behavior...

Running SMF 2.1 with latest Tinyportal at www.fjr-club.nl
Testing SMF 2.1 with next version Tinyportal at test.fjr-club.nl

Antechinus

Ok, but then you're back to the webkit bug. Take your pick. Or, you use a javascript override there.

Personally I don't care about it, because they're both shunted downstairs anyway, so why collapse one?

@rjen

Running SMF 2.1 with latest Tinyportal at www.fjr-club.nl
Testing SMF 2.1 with next version Tinyportal at test.fjr-club.nl

Antechinus

Just noticed the hidden overflow I added to the main panels is have an odd effect on some pages. I'll check it out later. It'll be something simple.

@rjen

The TinyPortal Team is pleased to announce the release of TinyPortal 2.2.2

TinyPortal 2.2.2 can be used on SMF 2.0 and 2.1

Minimum required PHP version : 7.0.0
Highest supported PHP version (tested): 8.1.1

Changelog:
This release includes the following changes relevant to SMF 2.0 and 2.1:

New functionality:
- TinyPortal package now supports upgrade option in SMF2.1

Bugfixes:
- Css file cleanup fixing some validation issues
- Fixed some textstrings for easier translation
- Fix for BBC blocks in SMF2.1 not parsing correctly
- Fixed language strings for alerts on TP mentions
- Fixed shoutbox layout when using scroll function
- Fixed layout issue with quickactions on mobile display

Note:
when updating from TinyPortal versions older than 2.1.0, recent topics blocks are enhanced with a new block setting: "Characters to display in titles". Due to this change any pre-existing recent topics blocks 'may' have a changed title length after installing the new version of TP. Please check these blocks and adjust the block setting "Characters to display in titles" to the desired length...
Running SMF 2.1 with latest Tinyportal at www.fjr-club.nl
Testing SMF 2.1 with next version Tinyportal at test.fjr-club.nl

Steve

I assume the usual applies, uninstall the old (without deleting data) and install the new?
Please do not PM me for support. 

tinoest

Quote from: Steve on May 13, 2022, 10:04:47 AMI assume the usual applies, uninstall the old (without deleting data) and install the new?

If you're running SMF 2.1 then you can just click the upgrade button. SMF 2.0 is the old method of uninstall and install.

Steve

Excellent! Thanks tinoest!
Please do not PM me for support. 

Steve

Reporting an issue. This mod and Nibogo's Shoutbox Pro conflict.

I can install one or the other but if I install both and go to the Package Manager and click 'Browse', I get a white page.

I'm also letting Nibogo know.
Please do not PM me for support. 

tinoest

It shouldn't cause an issue on the package manager page.

What version of TinyPortal and PHP? Also anything in the SMF error log or Apache logs?

Steve

Latest version of TP (I'm on 2.1.2) and PHP v. 7.4 ... I don't remember any errors other than I had to enlist Doug's help to fix it all. Never checked the server logs. I don't really want to install them both together again just to find out because it is way beyond my capabilities to correct.

I'll check with Doug and see if he can shed more light on this and get back to you.

And it's odd, I could go anywhere else in the package manager, just not browse.
Please do not PM me for support. 

@rjen

Not something we could reproduce if it is a conflict with a paid mod...
Running SMF 2.1 with latest Tinyportal at www.fjr-club.nl
Testing SMF 2.1 with next version Tinyportal at test.fjr-club.nl

tinoest

Quote from: @rjen on June 05, 2022, 02:45:18 PMNot something we could reproduce if it is a conflict with a paid mod...

Unless the other mod author is willing to release their code to us to verify.

I think it's more likely an issue with the smf cache being corrupt or similar myself.

Steve

Will look into it. Thanks guys.
Please do not PM me for support. 

Advertisement: