Feature Requests for TP 2!!!

[ZarPrime]

If i have bloc 1, 2, 3, 4 on left side, and 5, 6, 7, 8 on right side, visible at frontpage. Then i want 1,3,5,8 displayed on the left side in forums, that i guess is not possible now.

Kim,

JP Deni is absolutely correct.  Something like this can be confusing for your users.    However, if you really want to do it, it can be done.

If I am correct here is what you would like it to be ...

FP Left ...
1,2,3,4

Forum Left ...
1,3,5,8

FP Right ...
5,6,7,8

Forum Right ...
None

To do this, you'd do the following ...

1.  Blocks 1L and 3L are to be shown on both the FP and the Forum, so those can stay as they are.
2.  Blocks 2L and 4L are to be shown ONLY on the FP in the Left Panel.  Set to show on FP only.
3.  Blocks 6R and 7R are to be shown ONLY on the FP in the Right Panel.  Set to show on FP only.
4.  Now it gets slightly complicated.
5.  Blocks 5R and 8R in the Right Panel need to be set to show ONLY on the Forum.
6.  A second instance of both 5 and 8 need to be made for the Left Panel on the FP.  Call them 5L and 8L.
7.  The newly created blocks, 5L and 8L need to be set to show only on the FP.

I think I have that right but I can't be sure.  It's been a long day.  A little complicated but not too difficult to get through.

ZarPrime

[bloc]

Yes, I agreed..its too complex to add panel location along with all the individual page locations. Between membergroup access and page locations it should be enough to make quite complex setups still.

Consider this: even if its a bit cumbersome to make 2 blocks like ZP explains, you got more freedom. For example - if its a recent topics block - set the left instance to 4-5 topics, while the right one could have for example 12-14, if you got more space there.

[Zetan]

Moved to Feedback.

[mc]

I am working on a better upshrink routine - and yes, it is indeed a core function sent with the headers.

Blizzcraft, adding permission checks(or at least member/guest check) is something I'll consider, it seem to be a useful feature , instead of having two different menus+blocks.

I've been thinking about this since I posted.
Howabout a new type of block, which is based on a .php file, but can have extra functionality compared to a normal php block?

For example, say you have a SuperBlock with the code contained in SB.php (in reality it would be SuperBlock.php, but I don't like typing the same name many times!)
Within SB.php, you have several functions.
SB_title, SB_admin, SB_core.
SB_title would simply return a variable with the necessary details to create the block title (ie. Name, link, hideable...).
SB_core would provide the functionality to generate the block contents, pretty much the same as existing php blocks.
SB_admin, would then link into the block manager within TP, and provide a way of setting permissions for within the block (ie. membergroup permissions, content options)

SB_admin could be optional, so you could essentially have similar funtionality to a php_block, but adding a block would be a simple case of copying the php file to a directory (or via an upload similar to the package manager).

Off course, I've no idea how feasible this could be, and I'm just rambling to try and get some thoughts out my head to make way for some more new ones!

[blizz-craft]

It could be useful if you were able to select which blocs to display in forum. Now i have right & left blocs shown at my frontpage in an order i like, In the forum, i just want to have blocs displayed on left side, but it needs to take blocs from both left and right side in forum.

Example:

If i have bloc 1, 2, 3, 4 on left side, and 5, 6, 7, 8 on right side, visible at frontpage. Then i want 1,3,5,8 displayed on the left side in forums, that i guess is not possible now.


Greets
Kim

Kim... Dont do that... Your completly off the topic... Its about the TinyPortal menu not the TinyPortal block.
So dont post those senseless stuff onto another person's topic, it really ruins it.

[JPDeni]

Excuse me?!?!?! This topic is called "Feature Requests for TP 2". Kim added a feature request. It was completely on topic.

Please leave the moderating of the forum to the staff.

[blizz-craft]

Oh... LoL, my bad... I accidentally posted it there after forgeting what name of the topic I have added.
My Bad... LoL...

[blizz-craft]

Well, you can do that by making duplicate blocks for example:
Left Blocks: 1,2,3,4,5,8
Right Blocks: 5,6,7,8

[bloc]

I am working on a better upshrink routine - and yes, it is indeed a core function sent with the headers.

Blizzcraft, adding permission checks(or at least member/guest check) is something I'll consider, it seem to be a useful feature , instead of having two different menus+blocks.

I've been thinking about this since I posted.
Howabout a new type of block, which is based on a .php file, but can have extra functionality compared to a normal php block?

For example, say you have a SuperBlock with the code contained in SB.php (in reality it would be SuperBlock.php, but I don't like typing the same name many times!)
Within SB.php, you have several functions.
SB_title, SB_admin, SB_core.
SB_title would simply return a variable with the necessary details to create the block title (ie. Name, link, hideable...).
SB_core would provide the functionality to generate the block contents, pretty much the same as existing php blocks.
SB_admin, would then link into the block manager within TP, and provide a way of setting permissions for within the block (ie. membergroup permissions, content options)

SB_admin could be optional, so you could essentially have similar funtionality to a php_block, but adding a block would be a simple case of copying the php file to a directory (or via an upload similar to the package manager).

Off course, I've no idea how feasible this could be, and I'm just rambling to try and get some thoughts out my head to make way for some more new ones!

I think I see what you mean..but for what use? Fetching blocks into scripts outside of SMF?

[mc]

A main example I can think of, would be the menu one above.

At it stands, at the moment, you'd need to custom write a HTML/BBC block with all the links you need, then create duplicate blocks for each membergroup(s) that you want to display specific things for.
Or, you'd have to write a php block that checks for membergroups, then alters content accordingly.
Although both those methods would work, implementing and maintaining them would not be very straightforward, especially as the number of menu items increased.

Now imagine if you could write a script, that would then create an extra menu within the admin panel (I'll admit I missed adding this bit to my previous post), that you could then use for customising the block, where you could create/modify/delete menu items, and also select if/how they're shown to the available membergroups.

I know this could be done currently, but it would involve modding the core code to create the extra menu, and would need installed via the package manager.

Off course, the content needn't be confined to menus, it could be pretty much anything where you may want content to vary depending on who's viewing it, or where you'd like more advanced content within the block, which is not acheivable with the existing block system, or a way of making the content easier to edit.
Another example could be a gallery image block, where you could choose to display the latest image from a certain gallery depending upon the users membergroup.

Benefits I can think of are-
- Easier to install blocks (simply copy a php file to the selected directory)
- Easier development for advanced features (no need to alter code or write a package installer script to create an extra menu within admin)
- Easier maintenance for more complex blocks


As for being able to use blocks outwith SMF, I don't see why you would want to, but I'm, sure somebody would find a need for it.


However, I'll admit, I've not really got a need for this at the moment. It was just one of those ideas that seemed to keep bouncing around my head with little bits getting added.
Plus it may crossover into the module capabilty that you're adding..