Extra Thread Fields/Forum fields Manager

I was about to start working on the extra threads/forum field manager and I thought do we really need to managers that do the same thing? I mean if we just keep a hidden field based on input field in the forms on the page. It would be a lot easier then duplicating the current manager. Does this sound okay?

19 réponses sur “Extra Thread Fields/Forum fields Manager”

  1. it’s all yours…

    personally, i was more into field based, remember that it’s a similar system that i have implemented in InvisionBoard… but a lot of things have changed with vBulletin… i became stupid… LOL

    the only reason why i wanted that manager is because i wanted the « forumdata » to contain these details, to avoid a script change each time we change a function… this is because the vB engine is not complete yet…

    you code it the way it makes the job more efficient…

  2. remember one thing Drew, i know nothing about OOP, and i’m not an excellent PHP coder either, i just copy/paste stuff to make things work correctly. i may have coded the best plugins for vB, no matter what, i know nothing about performances. I always had someone to work with me on the coding side because my talent is about ideas, not results.. i’m a web-architect, i construct projects with ideas, and i have guys like you to execute the task to make the perfect work — that’s why i’m not focussing on my own profit but on the global goal.

  3. Forum side:

    forum behavior for global display

    Thread side:

    elements displayed in threadbit – forumdisplay
    elements displayed in firstpost, replies

    Post side:

    custom fields in firstpost, replies

    … this is hierarchical, that’s the worst part to deal with actually… we know that all the custom elements of the Posts (first post / replies) are managed per forum, but they have to be displayed per thread also, that’s why i generated that custom fields engine, i thought it would cut off some work if we work everything from the forum level instead of the post themselves…

    That’s where i was when i stopped coding it, too much brainstorm means nothing…

  4. so if it’s not set to firstpost, it is set for replies, so yes, just a switch…

    i don’t know MANY fields which would be for replies, because vB already have most of what is needed when we reply a thread, but some situations, like in Auctions, wouldrequire that an answer contain different elements — an auction may contain a comment AND a private/public price… this is one of the rare instances…

    for the thread part, it’s not content but display that is important, so no, no custom field. all of what threads have to look like is managed into the Forum thing…

    *****

    The challenge is actually to not edit the thread/post tables… i know the impact of a minimal change on these tables when you have thousands of threads… when i was upgrading christianforums.com, we installed vbCredits… took more than 3 hours just for the install of the product (dedicated server here) with the site closed/locked to visitors, because it edit the thread/post tables, and there are 45 millions posts on that site…

  5. exactly…

    but no field1, field2…

    we have to use varname or something similar, because we want to be able to use these fieldid without having to check the dB each time… modifying a template with field1 etc was always a waste in vBulletin…

    $thread[var_excerpt] is way easier to deal with in any situation than having to find the fieldid… we have to think templates, portal, etc…

  6. i told you, i want to add sooooo much things to vB with this engine, a simple « hidden field for administration » addon is a product in itself, so we can add more.

    i modified a version of « hidden posts » from vb.org and i thought it would be a good addon for MTF!…. there is a lot more! (i just have to take the time to find all the ideas of the world.. lol)

    btw, these hidden fields are more based on permission bit: « Can see hidden fields in this forum »… instead of « can_moderate() » which call a stupid function…