Create / Share a Topic in More Than One prefixed-Forum (Page 1 of 2)

@lie2  -yes-

@Lie2 ...Hmm...

Another idea (while we think on this one):  (again, I am not yet got around to looking at the code, just 'broad-stroke' musing )...
  Usually you (can) set a single prefix when installing a bbs.  In all the queries there is a variable placeholder for it.  What if you could simply add a second one (or even more) and reconfigure the way the db.php parses the prefixes?

I think the prefix gets passed/parsed through the relevant dp.php when initially processed (so-to-speak... like on page load, etc). 
I am wondering if I could make it so it would simply loop through 'the collection' of prefixes.
The idea would be to do something like install a third bbs with, say, a prefix of 'common' or something,
then add that prefix to the other two installations,
set things up so at the db parser it is looping through these...

...Of course, I have to think it through, but the idea would be to make the third bbs fully available in both the first and second ones, thus not having to sweat "changing tons of queries", only figuring out how to "somehow naturally" include forums and topics from the third.
Then all you might have to do is some coding to add the ability to select the third when creating the initial forum.  Topics should naturally follow suit.

Of course, then you got to sort out the logic for users permissions, but if the idea has any sound basis then I think the method for handling this should shake out readily.

Something along those lines.
Is this making sense?

Last edited by twohawks (2009-07-04 05:20:19)

The prefixes are actually inserted into the query throughout the code. It's not done by the database layer.
For that idea you would probably have to do a UNION for every single query regarding posts, but that would probably not be the easiest solution - not by far.

I know. I was refering to twohawks' last post.

@lie2 ..
The idea would be adjusting the entry in config.php to something like...
$db_prefix = array(main, common);
...so in effect I think all you would need to do is adjust the db function handling slightly, similar to what Matt has mentioned, but possibly even simpler (?).

By simpler what I mean is... it would seem you could then quite naturally/natively include the whole of the 3rd so-named "commonDB" in any other BBS, and it could be fully included for "normal" access *without fuss*... (meaning for searching and allowing all other base functions without needing to change any of them), and without worrying over isolating piecemeal access to forum-topics in another (say, the first or 'master") adjacent BBS, which seems, in this scenario anyway, might either limit some native functions or require more coding (??).

-----------------------------------------------------
@MattF:  Interesting...   
How would your wrapper be facilitated to decide/choose?  I.e., where's it obtaining its directive-var from?
I would think it would have to be config.php -- is this your thinking?

And so then this wrapper function would be called "only in certain circumstances" and not universally all the time?

I am wondering if there isn't something betwen your idea and mine that is somewhat connected and may proffer an elegant *without fuss* solution??

Does Admin want to get replies in both bbs? It seems to be much more complex then looks at a glance.

May be some sort of "feeds" from master bbs are better choise? Let some extra block in viewforum module to insert links to the master forum topics. They will looks like "sticked topics" at the top.

Please excuse the length of this post, but it seemed more appropriate in this instance to set sections in a single post rather than breaking it up...

1. BRIEF REPLIES
2. PONDERING FURTHER
3. NEW IDEA! (is it any good?)

=============================================================================
1. BRIEF REPONSES
@Matt:  that's interesting.  However, unless I missed something, it seems the question still remains "How would your wrapper be facilitated to decide/choose THE FORUM FROM THE OTHER BBS?  I.e., where's it obtaining its INITIAL directive-var INFO from?" 
I capitalized words I am adding here to try to make it less ambiguous.

   So in your example, for instance, we do not know how or 'where/from' "alt" is intended to be intialized... how does the function know its gotta be 1 or 0?
And then where does the external db_table info get initialized?

***To be clear, I am more concerned with first discussing clarity to the general logicistics than worrying right now over any particular code or coding.** 

Seems to me its critical to consider How any query is going to know it is being 'sent' anything from 'outside' the currrent BBS - where and how that is initially 'set' and 'held' for reference(?)  Seems this will probably set the tone for decisions as to how anything shall be handled.

(...please read on, I had an idea...)

---------------------------------------------------
@r2d2:
1) yes to 'replies expected in both BBS's'.
2) Sorry, I posted and then I realized I misunderstood your post.  I still may have it wrong, but it seems the intention might be to pull off the array I proposed for config.php? 
If so, and maybe even if something else, sort of similar to my question with Matt's idea, how/where is the 'impetus' initially pulled from and then planted? 

=============================================================================
2. PONDERING FURTHER.......

Please Check My Logic Here....(New idea in #3 hinges on this one)

So we have 'this'>BBS and 'that'>BBS and then 'common'>BBS, where 'this' and 'that' represent unique BBS's, and 'common' is a BBS created for sharing ALL its db-tables with both the other BBS's ...and so 'common' is not a BBS anyone ever logs into directly.

What initially occurs to me in this scenario is that, in effect, ...well, a couple things...

-1- 'common' BBS would only need to be setup for the sake of initial creation of its tables, and then its prefix added to the config file (per the above suggested array) of any BBS that will attach to forums and topics that may be later created in 'common',

-2- when the admin creates a forum from within 'this' or 'that' BBS, in order to designate it as a "shared" forum a method would need to have been created to facilitate choosing which BBS to place a new forum into ...say, the primary (native) one or the 'common' one for sharing purposes. (SideNote: the reason we would not have the admin log into 'common' BBS directly for doing this is because then he/she could not readily assign permissions, because no relevant users/groups actually exist in 'common' BBS)...,

-3- anytime a new forum is created in 'common' it will immediately appear in both 'this' and 'that' BBS's (because all 'common-forum-tables' are always referred to, just as natively as any primary/native tables are),

-4- hence, any topics or posts added from either BBS into any 'common-forum' would naturally appear in both BBS's.

-5- because the 'common' db-tablesets would be present and accessible as natively and commonly to either BBS where 'common' is added to its $db_prefix array --> each BBS could set its own unique users permissions in the normal way and without conflicts;
...for instance, in 'this-BBS' you could set user permissions like you would for any other primary/native forums that were created there, and there would be no conflict with doing exactly the same thing independently in 'that-BBS'. 

-6- users in each BBS would see each other's handles, but be unable to view each other's profiles (acceptable) or non-shared topics/posts (of course).

---------------------------------------------------
Unless I have grossly overlooked something, this seems like an elegant, or at least simple and workable, solution(?WHAT DO YOU THINK?), that is, short of having better 'logical' clarity on Matt's or r2d2's suggestions ...as to where the initial tie-in is intended for the desired "other forum's tables" (and maybe its there and I missed it? sorry).

NOTED SHORTCOMINGs WITH THIS METHOD:
It would seem that if there was possiblity for an elegant solution that does not rely on creating another BBS tableset (e.c. 'common'), or impose any sharing limitations, ...that would be the ideal really.
  Conversely to what I have proposed above, a third ('common') BBS doesn't facilitate "true sharing" of any forums that may pre-exist in already established working BBS's - which seems would more naturally and effectively serve an admin's needs.

For instance, one BBS has a discussion or lesson underway and now the admin wants to share that with another group (another school)..., my above proposed solution would require moving the forum to the 'common' BBS - maybe doable, but that may introduce too many undesired ramifications to deal with (haven't even begun to think about it).

....what to do... ? .... ? ... ? ....

=============================================================================
3. **NEW IDEA** : instead of intercepting db_query to try to solve this, will intercepting forum_ids provide a more wholisticly viable solution?
IF the proposed logic above has sound viability while maintaing a fair amount of its proposed simplicity...,  then... being inspired by the excellent feedback so far and thinking harder about my questions regarding how to initially tie into another BBS's forums...
...PLEASE CHECK ME ON THIS IDEA -->>

Based on the logic for tying into a third 'common' BBS, how about selectively tying directly into any foreign forums you choose?...

---REQUIRES 3 LOGICAL MODS (?)----------------------------------------
Short Version:
1) Pull in a list of forums from the other BBS for the Admin to make selections from (in admin_forums.php),
2) When selected, a unique forum_id is generated same as when you create a new one, but additionally a unique decimal number is formulated for identifying the specific foreign forum, and then that decimal value is addended to the fid,
3) Then when any fid/f_id is called in a query, if it contains a decimal value a function parses the value for targeting whichever foreign forum is being referred to.
...after that, everything should follow suit without any modifications to queries or code...

Details:
1. Create a Method for the Admin to choose any foreign BBS Forum(s) from within admin_forums.php.
HowTo-Logic:
- Create a new array variable in config.php named $db_foreign_prefix: where you would input foreign prefix values.
- Create a table for storing unique values assigned to each foreign prefix, say for now, double-digit integer assignments starting at 10 (and auto-incrementing).  (Have to create a simple function for generating the assignments when  new entries aare found in the new variable.)
- In admin_forums.php (perhaps a plugin) create a section that will access, iterate, and list foreign BBS forums for the admin utilizing these $db_foreign_prefix table values,
- And create checkbox selection ability for these.
- Wont need a new page that facilitates setting options for ones that get selected because, by making the foreign forum selections appear native to the current BBS (see ahead) we'll be able to rely on all the existing native functions just as they are...

2. When a foreign BBS forum is selected for inclusion, then a unique id is added into the current BBS's "forums datatable", same as when you create a new forum, but with a twist...
HowTo-Logic... Challenge: create a unique id# that doesn't conflict, but in fact blends in, with native forum_id's (fid's or f_ids) auto-increment-numbering:
- upon selection of a foreign forum, allow the usual creation of a new auto_incrementing unique f_id (integer) assignment in the forum table for it,
- but then (new function) retrieve and augment that value with a unique re-calculated decimal value where the digits represent:
-- a)the foreign BBS's id listed in the above new table, and
-- b)the foreign BBS's forum_id addend to that. 
...and then replace the unique id# in the table with this new one.

--> So for instance, say
- the new f_id auto-assignment = 101,
- the foreign BBS prefix value = 22, and
- the foreign BBS's f_id = 55 [and we'll be adjusting that to, say, 6-digits, so this final result = 000055]
...then the new f_id for this "attached-to foreign share" becomes: 101.22000050
...or something generally along those lines ***so that we can keep the native AND THE foreign forum_id assignments together in one-and-the-same forum table without having to augment the existing structure.

Now we would have a unique f_id that can be parsed to always reference a real external BBS's forum.

3. If this logic is not flawed, then it would seem all that's left is to add a function that parses any f_id (or fid) values when a db_query is initiated (perhaps simply in functions.php?).

If the unique decimal value is present in the f_id, it is parsed in order to "lock" on to a foreign forum as a top level reference for everything that follows (topics, posts, etc,),
...so it would seem nothing further would need to be fussed with. No db_query changes would be required anywhere.  The only thing required is to cause our function to trigger anytime an fid/f_id is referenced in any query.  I would presume to be setting this 'call' up in the relevant db.php file.

Solves the issue of not wanting to pull in all the forums from "the other BBS" everytime viewforums is loaded, or wrestling with how to isolate and access only 'shared' forums.
Solves the isolation issue imposed by using a 3rd 'common' BBS.

======================================================================
How's my logic holding up?
What do you think of the idea of this approach?

Last edited by twohawks (2009-07-06 10:46:57)

Hell, I've lost the plot completely whilst reading your post, so for the moment I'll just answer the question you asked regarding the $alt var.

Some config file which contains all $db_info for an alternate connection and suchlike for creating a new DBlayer is in included in that conf file, plus the following:

$alternate_forum_ids = array(1, 2, 3, 4); //These are the shared forum id's.

viewforum.php, viewtopic.php, post.php, edit.php etc.:

require [alt config file path];

if (in_array($forum_id, alternate_forum_ids))
{
    $alt = '1';
}

Hopefully some of my responses to 'lie2' will help some.

Thanks for those clarifications.  I think I get the idea(s) now.

I appreciate your time and reflections ;^)

I apologize for the long post[s] (and to you, as well, Smartys)... I have been "told" before.
I am trying to be sure that clear complete info is included so the whole picture becomes readily apparent.
I will try harder to be as succinct as possible...

Nope. Think about it... when users at 'thisBBS' are accessing a forum, permissions management has nothing to do with anyone at any other BBS. Same thing applies over at 'thatBBS'.
The BBS doesn't care about managing foreign permissions. (see next)

Described in 3rd Section --> "NEW IDEA" / 'Details'  / at #1. "Create a Method for the Admin to choose..." foreign forums with a checkbox.

To Re-Summarize My/The 2nd idea (skippable):
- In 3.1: in config.php any foriegn BBS prefix identifier-labels are manually assigned into a new array variable. Those get 'parsed' into a new table where they are given numeric labels.  Those will later be pulled for use.
- In 3.2: Admin_forums.php plugin pulls in full foreignBBS forums into a list (based on new table data from 3.1) The admin is provided selecting via checkboxes.
- That foreign forum list has all the needed identification info including a numeric value that identifies a foreign BBS (in place of its prefix name ;^), and then also each foreign forum id number.
- When a foreign forum is selected, a query runs and the forums_table update runs in the usual way creating a 'f_id'...,
- A new function takes and tweaks that auto-assigned value into the new/unique 'identifier code' **using the foreign prefix + f_id numbers obtained above, and replaces the auto-generated f_id.

Lastly, since the forums are now included in the natural way (in the native forums table), permissions assignment can be handled normally.
- admin logs into 'thatBBS', creates a forum, sets permissions for her users there, etc...
- admin logs into 'thisBBS', picks a 'thatBBS forum, sets permissions as usual for her users here.

The BBS will only ever use its native prefix.  Non-natives are always handled via an identifier-code.  So when viewing and posting, the added db query function discovers and then parses any foreign identifier codes in order to query the correct tables.

Hmmm... yeah, you are right.  However, I was reading somewhere that sql will allow decimals to be placed into the Integer value structured records, ...I have to sort out if thats true.
That made me think, hey, the table always auto-updates one full ineger value, but we can change any value to a unique code by adding a fractional-decimal number.  In this way there could always be full id-separation between foreign and native ...and right there within the native forum table.

If that won't work, then I think I would have to either...
1) create a new foreign forums table... but that would then change the method and require editing lots of queries,
OR
2) insert those new identifier numbers as integers either starting at some ridiculously high level (say 1,000,000,000), or using negative values,  might do just as well.

...I am still pondering a couple other points you brought up...
Really appreciate these ideas and this feedback.

Last edited by twohawks (2009-07-07 23:29:03)

The permissions part is the simplest part. You do actually create a native forum and set the necessary permissions on that forum locally. However, you will never actually be referencing that forums content in the local table but rather the remote table, so you have the local permissions but the remote content. As soon as you reference that local forum id, that's when the wrapper kicks in.