Community Builder Clone - *Must READ*

Well to my amazment I was unable to locate a decent Multisites component that did what I wanted and allowed me to take "Less Time" and design to accomplish my goal.

This lead me to create "Community Builder 2"

What is Community Builder 2?
1. An exact replica of Community Builder 1.1 with modified directories and database entires. *Theoretically IDENTICAL*

2. It holds all of the same functionality and useability as Community Builder 1.1, meaning Plugins, Templates, Languages.. etc

Why Community Builder 2?
Its simple.... I needed two installations of the same component "Community Builder" so I saught out a plan to duplicate it which I was successful. This allowed me to have two Registrations, Two sets of User List, Two User Groups.. etc.

Some added benefits come from programs such as JACL, AEC.. etc which allow us as developers and users to be able to create user groups which another plugin founf in the JED will automatically assign a Newly registered user to that user group.

The downside to this new component?? Existing plugins do NOT work out of the box, they have to be altered to match the new prefix com_profiler2 as well as any database entries related to Community Builder. Most plugins take a maximum of 5 - 10 minutes to change.

My goal and question with this post is...... does anyone see use of this? Would you like to be able to utilize it for yourselves?

Prior to public release I am trying to have BEAT bless it and allow me to do so.

Please post your ideas, questions and comments here.

Post edited by: ugcomputers, at: 2008/03/28 23:38

James,

Thanks for making a proposal and opening discussion publicly with a solution proposal. As I stated in my private message response to your initial query a week ago:

“If you want my sincere reply: While I understand that this is an easy change with 2-3 simple replace-all statements, I think that this problem should be solved differently than with 2 instances of CB...”

I believe that there are many methods to address your needs with existing CB features and extensions – plugins.

Creating a "second instance" clone (please avoid the proposed term "Community Builder 2", as we are already working on CB 2.0, and would like to avoid confusion ) – hacked CB would only add to the confusion currently plaguing our community : Joomla 1.0.X, Joomla 1.5.X, 1.5 Legacy plugin, Mambo, AEC hacks, JACL hacks, etc.

I see many technical issues that have not been addressed. Some quick ones come to mind:

• Would you need 2 login modules or most likely a modified one?
• How would user synchronization work with joomla table? (I can just see someone clicking the CB sync tool and messing things up – or will you also replicate the Joomla user tables?)
• I would hate to start addressing support issues and see this bringing up many of them.
• Plugins that have databases (profilebook and cb gallery among many others) will have problems and would also need to be hacked.
• What happens with language plugins?
• You will end up with 2 separate communities, e.g. no PMS/connections/forum between them ?

These are just a few quick thoughts – I am sure there are a lot more.

The CB Team has always been very thoughtful and cautious regarding quick hacks. The team feels that hacks lead to confusion and frustration and of course a hack has no long-term future. That is why the team spent significant time and effort to design and release the CB API. This way real solutions can be created. Solutions that will survive the next release. :whistle:

We are currently spending a ton of effort to solve the existing confusion above and to make CB 1.2 cross CMS native (Joomla 1.0, 1.5, Mambo 4.5.0 - 4.5.5 + 4.6.x compatible), in a single universally installable package, with a single coherent API . We are trying very hard NOT to create different versions of CB – one for Joomla 1.0.X, one for Joomla 1.5.x, one for Mambo, etc. This would be catastrophic for our scarce free time. We are also addressing in CB 1.2 many of the current problems of CB users, and designing a solid basis for future improvements. The CB API itself has undergone quite some changes, while lots of efforts have been put in assuring the compatibility of the 100+ existing CB extensions.

FInally, coming back to the problem you are trying to solve with this solution proposal: have 2 different groups of users with 2 different registrations, we believe that with some carefully selected existing plugins and components, and probably an additional plugin and mambot to develop, you can solve that problem more elegantly without any hack in CB 1.1, and without the hassle of keeping the clone up-to-date with future releases.

Some which come to mind are GroupJive, Conditional fields, JACL, among half a dozen others.

CB 1.2 will bring a few more features which will help again, and we are also in contact with the GroupJive team and many other teams to bring those functions in a powerful and non-hacked way into CB.

Hope you now better understand my short answer of a week back

James,

I would be interested in cloning CB. I think there is a definite need here. Maybe it is not popular enough to address the issue, but it does seem like something that should be part of CB.

Beat,
I have had very little luck trying to figure out a solution and as far as my research goes, I would say that you are not correct in assuming that there "is a way". Even with all available extension and plugins. If there was such a solution, then I would hope you would offer some actually examples or ideas.

I understand the need for eliminating confusion as much as possible, but the problem exist and there needs to be a solution.

My site has 2 demographics. My first member type are vendors. These are business owners that I want to sell directory space to. I am using SOBI2 as the directory, but since it does not have it's own membership sign up I am using CB. With CB they pay the site fee and then they can click on "Add Entry" in the SOBI2 tab where I have installed the CB-SOBI2 connection extension.

This above works just fine by itself. I have it already set up and if I do decide to get 1.2 and the subscription plugin it will work even better... Maybe. I am not totally convinced of that just yet though.

Now on to the second member type. This group is for Brides who want to sign up at the site and make a profile that will show off their wedding stuff. They can upload pictures and write a blog and add information about their upcoming wedding and their registry. They can do this at no charge.

Hince the problem. How can I allow these Brides to sign up and not be presented with the same information as the vendors. I don't want the vendor subscription to be visible in their profile nor do I want them to have access to adding to the SOBI2 directory.

There is nothing available to do this because CB was not designed to have different member types. If it did allow different member types then you could have a place in the tabs manager to specify which member type to give certain features to and who to hide others from.

Cloning would solve most of these issue. If there was a concise way to do it. You would have to work with 2 seperate admin menus but you could customize each member type without affecting the other.

You would loose the ability to PM, but I don't want that anyways. To contact the Vendors you would use the contact form in their directory profile.

I would have 2 seperate logins, but that is not a bad thing. I will just have either 2 links or one page with 2 boxes. One for each and clearly label each one. Many large production sites do this exact thing. I could supply examples.

I know there are other issues, but this route seems to be the best idea offered up so far.

Bubba HoTep:
I have several projects that have similar issues revolving around having two different classes of users.

I've come to the conclusion that the best way to handle this is to create two different websites that have the same look-and-feel. In your case, perhaps create them under the same parent domain with differing subdomains: brides.domain.com and shops.domain.com

Your brides site could then seemlessly link to your directory site, which could be managed independently.

Obviously, putting links back and forth between the sites is simple enough. You can even implement a shared login mechanism if you really needed it. The real trick comes when you want to display new or sponsored directory items within your end user site. You can trick this out in the following way:

Install SOBI2 on your end user site. Write a database backup/restore script that backs up the SOBI2 directory on your vendor site and 'restores' it to your end user site. Put the script in a cron job that runs once or twice daily (or whatever). Viola.

We haven't implemented this for our SOBI2 projects yet but have used this approach to "share" a jevents calendar between two sites. One site maintains the master calendar while the other site is able to view upcoming events and minicalendars in a 'read only' environment.

That seems too complicated for what I am trying to do, although I think it is a brilliant idea.

So far cloning still seems to be the best for me.

One of the downfalls to doing a clone is the plugins. However, for my paying vendors they will not get all the frills of the addons for CB. They do not need a gallery because they have one in SOBI2.

As a matter of fact, I would like to set it up so that the vendor CB profile is very basic and not even visible to the public. CB for the vendors is just used as a gateway to get to SOBI2 and have a log in process.

I just don't want anyone to be able to upload to the directory. I want only registered members to be able to do so.

nnwltrs wrote:

Bubba HoTep:
I have several projects that have similar issues revolving around having two different classes of users.

I've come to the conclusion that the best way to handle this is to create two different websites that have the same look-and-feel. In your case, perhaps create them under the same parent domain with differing subdomains: brides.domain.com and shops.domain.com

Your brides site could then seemlessly link to your directory site, which could be managed independently.

Obviously, putting links back and forth between the sites is simple enough. You can even implement a shared login mechanism if you really needed it. The real trick comes when you want to display new or sponsored directory items within your end user site. You can trick this out in the following way:

Install SOBI2 on your end user site. Write a database backup/restore script that backs up the SOBI2 directory on your vendor site and 'restores' it to your end user site. Put the script in a cron job that runs once or twice daily (or whatever). Viola.

We haven't implemented this for our SOBI2 projects yet but have used this approach to "share" a jevents calendar between two sites. One site maintains the master calendar while the other site is able to view upcoming events and minicalendars in a 'read only' environment.

nnwltrs,

Thanks for sharing this clean and well-thought implementation idea, which indeed allows to do the best focussed marketing, tailored to each group of people, and is really easy to implement.

I believe Bubba HoTep hasn't seen yet the size and scope of CB and definitely underestimates the work and all issues araising from his favorite approach if he thinks making a second instance of CB is easier than your excellent and so easy to implement and wise, straightforward, modern marketing-oriented solution.

Existing CB extensions like GroupJive (looks like news are scheduled soon ), APC (momentarly not available, but hopefully available soon again ), and the CB subscriptions plugin (currently in last private beta tests by over a dozen beta-testers, one of them running a very popular wedding site among many other sites ) will also help bringing a cool solution. Not to speak about the pipeline of features CB 1.3 and 2.0 are preparing...

Well, back to work to finish polishing the stable release and help getting out all those exciting things above

(btw nnwltrs and all doc subscribers: thanks a lot for supporting our work, it makes a difference being able to work full speed ).