My Feature Ideas

[leefish]

(12-10-2010 10:05 PM)ZiNgA BuRgA Wrote:  

(12-10-2010 12:44 PM)leefish Wrote:  and - not mentioned - but wanted by me for so long - a way to create a display page for a "family"of forums all using the same custom thread fields (would tie in nicely with that XBlog.....)

Would you be able to elaborate more?

Hmm, well, its hard for me to explain what I want - but I tried in this post:

http://mybbhacks.zingaburga.com/showthre...http://mybbhacks.zingaburga.com/showthread.php?tid=615&pid=50  >> up to post 17 in that thread.

Regarding your remark on the blog idea - if each blog was a forum. This is kind of what I have now - I have a couple of people who share the site with me and we all have corners of the board (categories with forums inside) for our stuff. It would be cool for users if they could see ALL the stuff we all have to offer on a display page. Kind of like a portal for our forums.

I know I could use template conditionals for headers and things, but I go a lot further than that, and I am working on my css skills to make all the same base templates look different.

You see, at the moment we have all these individual forums - all individually styled - but they only pull together at the portal (via portal announcements) - otherwise its all islands of forums on the board. Its a shame, because I have these really neat looking forums, but the categories are not so flashy looking (part of that is me I know - we can style the forum bits a lot more than I do) what I really want is to have the opportunity to have the power of Xthreads (filters - styling - custom fields etc) on a grouped page - so why not use the portal? But I use the portal page for News/latest threads etc - basically as a portal. This would be more a showcase for a certain aspect of the "blogs" - I use the mybb themes option for styling the blogs + different templates via XThreads to give each area a different look, but our site visitors want to see all the offerings on one page - we all make items for the sims games, but we have different areas of speciality. One of us does tutorials, another does gameplay mods, me and another guy make objects, but we all do the same things, just some more than others.

So I make a tutorial - its just one  - and it looks kind of sad all on its own in my forum. But I have LOADS of things to download. For another one of us its the other way round - loads of tutorials, not so many downloads.

So it would be neat if we could have an area that calls all the tutorials together, and another area that calls all the downloads together,  but when you click through you end up in a certain persons "blog" - with their theme styling and XThreads templates. That way we can present the stuff better for visitors, and still keep our blogs. Its the idea of presenting things by category - eg tutorials/downloads/pictures/deep thoughts on sims (which can be in several forums) rather than presenting by forum.



Um. I guess that was kind of rambly.......I hope it was clear what I was trying to say

[RateU]

@ Yumi: How about custom thread fields applied to the forum, Yumi?
Let say that I have this thread structure:
Parent Thread
-- Child Thread 1
-- Child Thread 2

In the forum contained with the thread, I have a textbox custom thread fields.
When this custom thread fields will be applied? When creating the parent thread, or when creating the Child Threads, Yumi?
I'm sorry for my dumb question, Yumi. I know that this is still in "planing". But I'm very interesting with this feature. And it is the first time for me (yeah, for me) hearing about this system

[ZiNgA BuRgA]

(12-11-2010 01:58 AM)leefish Wrote:  Hmm, well, its hard for me to explain what I want - but I tried in this post:

http://mybbhacks.zingaburga.com/showthre...http://mybbhacks.zingaburga.com/showthread.php?tid=615&pid=50  >> up to post 17 in that thread.

Pulling threads from multiple forums?  I've thought about it before, but it gets tricky, for example, potentially different permission sets on forums etc.  It gets really difficult to handle all that.
Search system may work better, but it's not quite as versatile as the forumdisplay page.

@your other idea - just portal categorisation?
Is it similar to the page here? http://sc2.zingaburga.com/ where you can click on the category and will only show posts of that forum?

(12-11-2010 04:11 AM)RateU Wrote:  @ Yumi: How about custom thread fields applied to the forum, Yumi?
Let say that I have this thread structure:
Parent Thread
-- Child Thread 1
-- Child Thread 2

In the forum contained with the thread, I have a textbox custom thread fields.
When this custom thread fields will be applied? When creating the parent thread, or when creating the Child Threads, Yumi?

Child threads will be identical to normal threads, that is, have their own thread fields.  The only difference is that instead of being displayed on forumdisplay, they're displayed in showthread.
Eg:
- Forum
--- Thread
----- Child thread 1
------- Sub-child thread 1
------- Sub-child thread 2
--------- Sub-sub-child thread 1
----- Child thread 2

I've thought a bit about it though, and I think it may be too difficult to get it to work completely right... :/
Unfortunately would require a lot of code duplication from forumdisplay to display threads on showthread.

[leefish]

(12-08-2010 09:00 PM)ZiNgA BuRgA Wrote:  v1.40 of XThreads will have most of the features I've wanted to include in the plugin.  So I'm thinking of slowing down on development after that, and primarily only maintain bug fixes and maybe something that really interests me, but I kinda want to move on to other things.

But then on the other hand, XThreads is damned awesome already - might be interesting what the OTHER things are....will they be MYBB related?

[ZiNgA BuRgA]

Nope

[RateU]

That's why personally I prefer this version is not released as soon as possible.
I'm afraid you will leave us, Yumi..... (I don't know how to say it correctly).

(12-08-2010 09:00 PM)ZiNgA BuRgA Wrote:  Additional "Parser" setting: evaluated value.  Essentially allows variables to be inserted, as well as conditionals.  I'm worried about the security implications of this however.  This may be useful for a "custom pages" type system.

Do you mean that we can use conditional, or maybe php (if we use php in template plugin), Yumi?

(12-08-2010 09:00 PM)ZiNgA BuRgA Wrote:  Multiple file input field??  This may be rather tricky to do.

Will we have a separated variable for displaying each file, Yumi?

[ZiNgA BuRgA]

(12-13-2010 07:35 AM)RateU Wrote:  I'm afraid you will leave us, Yumi..... (I don't know how to say it correctly).

I won't "leave" you

(12-13-2010 07:35 AM)RateU Wrote:  Do you mean that we can use conditional, or maybe php (if we use php in template plugin), Yumi?

Yes.

(12-13-2010 07:35 AM)RateU Wrote:  Will we have a separated variable for displaying each file, Yumi?

Haven't thought about that one actually.  I did think about using the display item format and you just use the 'value' key of the threadfields array, but that may be restrictive.

[RateU]

(12-13-2010 08:34 AM)ZiNgA BuRgA Wrote:  I won't "leave" you

(12-13-2010 08:34 AM)ZiNgA BuRgA Wrote:  

(12-13-2010 07:35 AM)RateU Wrote:  Do you mean that we can use conditional, or maybe php (if we use php in template plugin), Yumi?

Yes.

With that we can have dynamic pages!
Ugh.... Personally, I would really love to vote for this feature, but because the security implications of this, I think you don't want to add this, Yumi?

(12-13-2010 08:34 AM)ZiNgA BuRgA Wrote:  I did think about using the display item format and you just use the 'value' key of the threadfields array, but that may be restrictive.

Ah... So, it is like the multiselect field.
Yes, personally, I think it is good using the display item format for this, Yumi. So, XThreads will detects automatically whether one of the file input array contained a file or not, especially if the multiple file input field is not a required field.
I think this custom thread field is very handy for some applications that allowed users to upload more than one file/images.
For example the garage forum. Admins need to create 4 non required input file fields for that (based on the default example application).
With this, we only need to create two multiple file input fields (because it needs to be placed at the different area).
This happens to the product review application too.
And maybe for download forum that needs more than one non required file input fields for screenshots.

[ZiNgA BuRgA]

(12-14-2010 01:57 AM)RateU Wrote:  With that we can have dynamic pages!
Ugh.... Personally, I would really love to vote for this feature, but because the security implications of this, I think you don't want to add this, Yumi?

Well, ultimately, it would be the admin's decision to enable it.
It's a bit dangerous to allow outside the AdminCP though.

What I might do, is add a function to the template conditionals thing to evaluate (safely) conditional text, so you could:
- set sanitise to nothing
- editable by admins only
- have display format similar to this:

Code:

<?=xthreads_phptpl_eval_text({VALUE})?>

---

This is a bit more flexible, plus it doesn't provide an easy switch for admins to stab their security.
EDIT: committed locally

[ZiNgA BuRgA]

I think I'll ditch gzip in XThreads attachments. (and I kinda wanted this)

The stupid HTTP specification fails to mention the ordering which Content-Encoding and Content-Range should be applied in.  And it's hard to find any info on this via Google.
But I did manage to find something after quite a bit of searching.  Apparently, it's compression then range selection, though IDK about the support of clients/download managers for this are:
http://www.mail-archive.com/www-talk@w3....http://www.mail-archive.com/www-talk@w3.org/msg

Which makes things a little tricky:

• If I store the file uncompressed, there is no way to to select the range as I cannot generate compressed data from a specified range.  Compressing the entire file up to the range may be possible (difficult because PHP doesn't provide all the zlib APIs), but absurdly slow
• If I store the file compressed, everything works well, except if a client doesn't support gzip content-encoding, and decides to use ranged requests.  This wouldn't be a problem if gzseek wasn't slow.
• All problems are solved if the file is stored both compressed and uncompressed - except for the fact that this increases the amount of disk space used
• If PHP exposed all of zlib's API, it may be possible to force deflate block splits mid-stream - this would be somewhat of a tradeoff in that you'd get a slight bit of slowness (but this is limited because you only need to start decompressing from the start of the block rather than the start of the file) and less compression efficiency (due to forcing block boundaries).  Nonetheless, would be difficult to implement, and would require managing an index (yuck)
  EDIT: actually, this may be possible with a bit of fiddling around with binary strings.  I still think it's yucky, but doable perhaps.
• I could offer a tradeoff - enable gzip and disable ranged requests; maybe offer such an option to smaller (uncompressed?) files
  

Also, PHP doesn't offer a way to compress in chunks (like zlib) - you can only compress the whole data at once.
None of these work:

PHP Code:

fopen('compress.zlib://php://output', 'wb'); gzopen('php://output', 'wb');

---

However, a workaround may be to use stream_filter_append: http://php.net/manual/en/filters.compression.php
Will only work on PHP 5.1.0 and higher.  Gzip headers can be outputted, the rest through something like:

PHP Code:

$fp = fopen('php://output', 'wb'); stream_filter_append($fp, 'zlib.deflate', STREAM_FILTER_WRITE, 6); fwrite($fp, $data); fclose($fp);

---

The remaining difficulty would be calculating the CRC32 in chunks, but this can probably be reasonably done by porting zlib's crc32_combine function.

Ah well.