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?
Views: 50
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…
Ok, sounds good oh yeah if you (or anyone who has access to this forum) ever wants to see that status of MTF my test board is at http://www.sim2world.com/testvb and the username is guest and the password is guestpass
the only other person is Mert… as a spy for his wife, who is the one dealing with the money…. (spending it!)
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.
Also back on this topic What fields should be added/deleted to the forum manager from the post field manager?
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…
Ok, except we don’t have to create a manager for threads right only for posts because you can just say first post only right?
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…
I think for threads we should defently use a secondary table to store the data. And just have it setup like
id
threadid
field1
field2
…
And then from the thread use a LEFT JOIN with the secondary table
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…
Yeah we can just store is the Field ID field in the post field manager
/me look bloat here!
One other thing about the forum fields manager… Do you think we will need hidden fields in the admincp? I really don’t think we would but if you can give me a reason to I gladly add it back.
sure, admin notes… 🙂
tagging « possible scammer », or in a Meeting script « hetero » so the guy have no access to the « lesbian » thing… lol
Ok then a little different of an answer then I was expecting lol
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…
Yeah I see why it would be needed now, except I’m going to turn it into a type (of field) rather then an option for types (it makes more sense)
Also do we really need the advanced check/multi-selection options manager? It is a lot of code to just rename/move/delete form options.
no no, just the basics, we can add that kind of stuff in a paid request if we have one client for this… 🙂