Quote:

Sorry about my ramblings if you saw this post earlier; my brain isn't functioning properly at this time (4am). Let me try to rephrase this, now that I have re-read your comment.

1. Why the $_SESSION at all? The session variable would be used to fetch what block to display than checking against the database on each page. [update] Actually, it would be doing both: checking db for the complete list then the session for blocks to close.

2. Re-Opening Hidden Blocks It will be those X or [¯] image links which point to user.php?op=mod_block&choice=open&blockid=5 to re-open a block. the $open_close assigned variable would determine if a block would be re-opened or closed.

3. Why filter in the theme? My method wouldn't totally hide a block, it would just "shade/minimize" it showing only the title but not its contents.

4. SELECT ...
As far as my "SELECT" blurb above, I haven't looked too deep into the XOOPS core to see where this takes place. Although I can guess we could do something like 'SELECT ... WHERE ... AND NOT IN('.implode(',',$_SESSION['xoops']['hidden_blocks']).')';

Other Side This would totally remove the block from the user's interface where the X and [¯] won't get a chance to be displayed. I guess doing this method would require the user to re-open the block from his/her user account preferences :-/

5. In any case, this kind of dynamic feature might not work at all if the site is cached (don't quote me on that, I've never used that feature).

I hope my rambling is now somewhat comprehensive at this time of night.

If you still want the title of a block displayed, we'll still need to fetch it from the database.
However, we CAN avoid executing the block's display function and simply flag it "hidden".

Then in the theme, there'll be something like this:

with the hidden one just showing the title and a link to re-open it - and the visible one showing the full block and a link to close it

Adding blocks should not destroy anything - but removing a block could leave redundant data in the user's "hidden block" field.

Perhaps just have a new table "user_block_hidden" with uid and block id and fetch those. Then we can delete block ids by user on user deletion and user ids on block deletion. Would be a better solution, I think.

I like your idea about having status == "hidden" which cleans up the code a lot. The user_block_hidden table is nice too which prevents orphan block_ids but should only be deleted when the module is deleted, no?

Other than that, this seems like a good place to start. Supporting specific user block locations would be the next hurdle.

block ids should only be deleted, when the block is deleted - which they are on module uninstall or if it is a custom block, when that is deleted. So basically, you are right

DoH! hehe, for some reason I thought you were referring to something along the lines of: delete the user_block_hidden link when the admin disables/hides the block. my mistake

Well, I wasn't being explicit about it