Why? Doesn't vB have a news/blog kinda thing available where all posts to a certain forum appear on a page?

I also would be very much interested in this. I´d like to provide my users with the ability to open their own blogs, so it would have to use the vB user database.

any chance of revisiting this request, please?

just my 2c, however personally I would prefer seeing open source software primarily pushing/supporting other open source software, instead of closed source/proprietary or other commercial solutions.

On the other hand, speaking more generally: the exact forum or software that's used together with b2evolution should't really matter all that much if the feature request is looked at from a broader perspective: that is, the corresponding infrastructure could be easily provided if b2evolution had the right hooks in place to allow integration with other software (not necessarily only phpbased), simply by providing a well-defined RPC API, for example using SOAL/XML. Recently this has become increasibly easy and feasible for php projects due to the power provided by php.

Indeed, more and more php/perl projects are starting to recognize the need for remote APIs, for example the mantis projects (www.mantisbt.org) has already an support for RPC integrated natively-that way, mantis can be easily configured to work with other software, too.

So, in this context this would merely come down to optionally allowing admins to use an alternative source for the information contained normally in the user database, the functionality for this could be easily exposed using SOAP/XML and be enabled in the admin control panel.

any chance of us getting this in english, please?

:lol:

b2b sounds like you know your stuff.

b2evo is already set up with the hooks required, as the plugin system shows, and vb or phpbb i would have no clue.

But the main problem is with each version increment database structures can change hence breaking the integration.

Over december and january, i will be looking into making b2evo act like a forum, it's been on yabba's and my own mind for a while, and i will need my own forum software for various reasons.

But yeh, importing a user database should not be a problem at all, but getting them to use the same user database would be, or even getting them to sync changes would be difficult, not to mention a lot of work.

Atm, i would say it would be take too much time and research to bother with integration. But that may change later.

What would be good is if all the projects used a nickname convention for database items. Which would stop problems with changes to the database structure being a problem.

So yeh, thats my thoughts and comments on it...

I am not sure whether you are aware of the vBulletin 'product plugin system' they are using, which leads to minimal change to the vB core code making integration practically unaffected when upgrades take place

a drupal coder put out vBdrupal and the integration has proven to be quite successful

to me b2evolution has a lot to offer and if you are looking at including your own forums and they are written in php then providing integration to vB should be quite standard (??)

Integration with vB would be great

:)

But yeh, i'm a b2evo guru, i've installed phpbb like once for maybe a week or so, then got rid of it.

It would require collaboration with people from both sides. If you find a vB or phpBB guru that believes its possible from their side, and they have some time, i'm sure one of the devs here would be interested.

wow .. sounds interesting

currently I am busy with drupal (vbdrupal) integration and Wiki integration with vBulletin

once this is complete I will see what has been happening with b2evo and see if I can interest a coder or two

I like b2evo

thanks

balupton wrote:

b2evo is already set up with the hooks required, as the plugin system shows, and vb or phpbb i would have no clue.

But the main problem is with each version increment database structures can change hence breaking the integration.

yes and no: the point of an API (Application Programming Interface) is actually to protect users of said API from significant changes in the underlying code base, that is whatever may be changed internally is usually not reflected in the outer abstract interface to access said functionality.
So, the purposes and requirements of/behind a plugin system and an API that's meant to facilitate remote procedure calls, are really pretty different.
Nonetheless, having a well-defined plugin API can indeed facilitate development of a corresponding RPC (remote procedure call) mechanism, too.
balupton wrote:

Over december and january, i will be looking into making b2evo act like a forum, it's been on yabba's and my own mind for a while, and i will need my own forum software for various reasons.

personally, I really wouldn`t want to see something like this, not necessarily because a forum would be totally beyond a blog's scope, but rather because of additional workload and increased complexity of the code base. So, I`d rather see existing forum solutions being properly interfaced with something like b2evolution, so that all projects could benefit from eachother.

balupton wrote:

But yeh, importing a user database should not be a problem at all, but getting them to use the same user database would be, or even getting them to sync changes would be difficult, not to mention a lot of work.

sorry if I wasn`t totally clear: an XML/SOAP interface would not serve the purpose to import any databases, but rather to redirect requests (for data) between different components of an application or even completely different applications in the first place.

So, in the context of this thread, this could for example work like this:

1) install forum vBulletin
2) install b2evolution
3) setup forum & blog software to expose internals to each other
4) i.e. allow b2evolution to directly access (remotely EXECUTE) code in the vBulletin software

Basically, it could mean that there software components are interchangeably re-used, regardless of the host application.

[quote=balupton]Atm, i would say it would be take too much time and research to bother with integration. But that may change later.

What would be good is if all the projects used a nickname convention for database items. Which would stop problems with changes to the database structure being a problem.[/quote]

database stuff is usually MUCH too low-level: when dealing with other applications, you`ll want to RE-use functionality and features, rather than plain data-that`s exactly the point of technologies such as RPC & SOAP/XML:

http://en.wikipedia.org/wiki/Web_service
http://en.wikipedia.org/wiki/SOAP
http://en.wikipedia.org/wiki/Remote_procedure_call

So, the point is really not data duplication, but rather proper functionality/feature-reuse (code, that is), from a programming point of view, SOAP-enabled applications expose certain functionality, so for example implementing the feature request this thread is about, one might approach the task like this:

- add a remotely call-able "login" function to the forum software that accepts two parameters: username (string), and password (string) - make it return a cookie if succesful, or an error if not

- make this new function call the software's native built-in (non-remote) login function, passing the two mentioned parameters

--> that is, whenever the remotely call-able function is called, it will directly pass its arguments to the built-in function and thus merely serves as a wrapper, so it will by default use the database and configuration settings it has been set up for

So, on the b2evo side, one would mainly have to tell b2evo to override its native login function and use the one exposed via the correcponding SOAP/XML interface defined by the forum software.

Ultimately, this would be totally abstract and actually also pretty straight-forward from a design perspective, additionally one would however integrate some mechanisms to ensure that the corresponding RPC mechanisms are only utilized by trusted hosts/applications

b2b wrote:

balupton wrote:

Over december and january, i will be looking into making b2evo act like a forum, it's been on yabba's and my own mind for a while, and i will need my own forum software for various reasons.

personally, I really wouldn`t want to see something like this, not necessarily because a forum would be totally beyond a blog's scope, but rather because of additional workload and increased complexity of the code base. So, I`d rather see existing forum solutions being properly interfaced with something like b2evolution, so that all projects could benefit from eachother.

Yeh, but for my needs, it is a good option (for myself), i agree that yeh a proper forum software would be a much better for a forum, but in my case this is a good solution. It will just be some re-writes of permission settings which hacks are already avaliable, and a skin with plugin functionality. Categories would represent forums, Posts would represent topics, and Comments would represent replys.

b2b wrote:

sorry if I wasn`t totally clear: an XML/SOAP interface would not serve the purpose to import any databases, but rather to redirect requests (for data) between different components of an application or even completely different applications in the first place.

SOAP and RPC i have never heard of until now, i will take a look at the links you provided when i have time.

But a question is, you seem to know a hell of a lot about what your talking about, wouldn't you be "qualified" in making this integration?

Just in case anybody is seriously interested in some more background info:

presentations:
http://www.cs.fsu.edu/~engelen/soaptalk.ppt
http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030827soapdb/manifest.xml
http://www.idealliance.org/proceedings/xml03/slides/salz/salz.ppt
http://www.ibiblio.org/xml/books/xmljava//chapters/ch02s06.html
http://benramsey.com/media/talks/XML-and-Web-Services.pdf

articles:
http://www.devhood.com/tools/tool_details.aspx?tool_id=904
http://www.topxml.com/soap/default.asp
http://java.sun.com/developer/technicalArticles/xml/webservices/

w3c details:
http://www.w3.org/TR/2003/REC-soap12-part0-20030624/
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/
http://www.w3.org/TR/2003/REC-soap12-part2-20030624/

balupton wrote:

But a question is, you seem to know a hell of a lot about what your talking about, wouldn't you be "qualified" in making this integration?

well, maybe from a purely theoretical point of view I might be-however, I am a pretty new b2evo user (just a couple of days) and while I am familiar with php, I totally lack any understanding of the underlying code base to add any significant functionality easily and quickly, in fact I haven`t so far looked at any single line of code in b2evo.
So, until I'll have the time to actually look into the source code and play with it, my contributions are likely to be relatively restricted.

balupton wrote:

SOAP and RPC i have never heard of until now, i will take a look at the links you provided when i have time.

Just to describe the whole thing more figuratively: imagine SOAP/XML to be a technology that allows you to remotely execute some portion of code (optionally using custom data values) and getting the result.

So, let's imagine your buddy jeff speaks japanese and you want to know the translation of a word in a japanese book, then you'd normally simply use a request such as:

"hi jeff, could you please translate word #31 on page #324 to English for me?"

as soon as you have to repeat the same question over and over again, this would however become tedious and inefficient-so you'd probably make up some short form, such as:

"translate word # 31 on page #324"

So, this would already contain all required information to enable jeff to process your request.

That is, the point is really that you are delegating functionality, that is RE-USING existing resources, rather than duplicating any work/effort in order to process data.

B2evo does come with a the rpc things you are talking about (the "xmlsrv" folder).

Just to clarify, do you want / would you suggest, for them to use two seperate user databases that sync, or just have b2evo use the forums database via rpc.

I would say syncing is the best option, as there would be no risk of breaking hard-coded queries and such.

wow .. if that is the case then what do you call this contribution .. a teaser

look forward to further input

:)

balupton wrote:

B2evo does come with a the rpc things you are talking about (the "xmlsrv" folder).

as I'm said, I am really not at all familiar with the underlying code base, so I may be talking completely out of my a*se ;-)
Nonetheless, approaching the request as laid out previously, would surely have many benefits from a design/architecture point of view.

balupton wrote:

Just to clarify, do you want / would you suggest, for them to use two seperate user databases that sync, or just have b2evo use the forums database via rpc.

normally, this scenario would be implemented in a fashion that both applications (forum & blog software) are set up with their default database structure (and user tables), however one of the applications would be told to simply ignore its user table and use data received from the other application via the RPC mechanisms previously described.

balupton wrote:

I would say syncing is the best option, as there would be no risk of breaking hard-coded queries and such.

again, you are still thinking too low-level: spend 10-15 minutes checking out some of the links and you'll see the power behind a real 100% SOAP/XML approach: there are simply no such issues, because SOAP/XML is totally transparent and abstract.

Yes but a skin or plugin for b2evo may just perform it's own database query on the user database instead of using b2evo's provided function and such.... In which case if b2evo is using the forums user database then theres a problem....

I'm guessing that in order to make it work we would just add the RPCs into parts of the b2evo core appropriatly.

balupton wrote:

Yes but a skin or plugin for b2evo may just perform it's own database query on the user database instead of using b2evo's provided function and such.... In which case if b2evo is using the forums user database then theres a problem....

Yes, that's of course entirely correct, and indeed a potential problem-however, from an architectural point of view it should nonetheless be discouraged to allow plugins to do their own queries on/for native tables, rather the key is to really provide a common set of functions or OO wrappers to provide a well-defined API to the low-level data structures (tables), this would also be the only proper and reliable way to isolate users and plugin developers from potential architectural changes in the underlying code base. That is, plugin authors should usually only execute raw SQL queries on custom tables, rather than native ones. So, in the short-mid term this could probably easily become a general guideline to evaluate and assess future plugins for eligibility for use with b2evo.

I'm guessing that in order to make it work we would just add the RPCs into parts of the b2evo core appropriatly.

yes, however actually the design would at least consist of two layers: one layer to be able to delegate functionality to other components/software (such as for example the login), but on the other hand also in order to be able to be delegated functionality by other software. So, an advanced implementation would preferably take into account that b2b may not only want to use external functionality, but may also feature functionality that other software may want to use, thus exposing key functionality in a two-way fashion would indeed be crucial.

So, SOAP/XML-enabled applications are all about remote-controlling: in a two-way fashion, so that possibly useful functionality may not only be imported/used (from other software), but also exposed/exported for use by other software.

Just to provide another example for why an SOAP/XML interface might come in handy: I have installed b2evo on an intranet server that also runs a cron job regularly, personally I would have found it very useful if there was an option to be optionally able as admin, to add enable comments to certain articles being posted via SOAP/XML, that way the results of the cron job could be regularly posted to the relevant article easily.

In general, however it wouldn't be all that important to come up with a 100% solution now, rather it would be generally a good idea to start implementing the required infrastructure for such future functionality, so that new features can be added on an on demand basis-for example, right now there may be 3-5 features that users would mainly want to see available, so adding this now would actually be relatively straightforward - and the (SOAP) API could remain identical (stable!) regardless of low-level changes or addition of support for new features

All4Data wrote:

if that is the case then what do you call this contribution

well, it's really only speaking from a very general point of view: as I said I have virtually no experiences with the b2evo code base, that's in fact the reason why I am keeping things so general and broad, otherwise I would directly provide concrete examples for a possible initial approach, as well as some patches.
However, without the required familiarity with the code base, I'll really have to keep things that broad, otherwise I could easily ridicule myself-for example, I didn't even know until just recently that b2evo already uses XML/RPC functionality in general.

So, my postings are really mainly ideas and suggestions, not so much well-informed decisions based on real life experience with b2evo itself, neither as user and certainly not as developer.
That said, do make sure to take my previous ideas with a good grain of salt, not everything I may be suggesting may turn out to be feasible for a b2evo implementation, simply because of the design of b2evo itself.

For example, while my previous postings may make the whole thing appear relatively straightforward, there's indeed some subtle complexity hidden in the details: i.e. if the user database and permissions database in b2evo should not be normalized (separated), then things may indeed complicate things-simply because a forum software such as phpBB or vBulletin would surely have a completely different concept of permissions, thus any sort of integration and interfacing would be complicated, as you would then really start to approach the task from a more low-level approach (database/table syncrhonizing that is), rather than the preferred abstract way.

Hence, you really do need to have a properly designed code base and database structure to make an advanced implementation feasible at all-at least in the long term.

I'll email blueyed, the co-developer of b2evo, and get him to post on the topic.

I would say that the database synchronising would be the best idea. And leave the permissions enitirely seperate. So only a user's info and existance are synched. And that would occur on a login, registration, update to a user's profile, and deletion of a user.

Which is would make everyone happy yeh?

Although then with synchronisation, you have the problem of getting the information of existing users synched in the first place. If you have any ideas on how this could be done, go ahead and tell :)

this may be of interest

in this thread

http://www.vbulletin.org/forum/showpost.php?p=749311

and Kai Backman's post

http://www.vbulletin.org/forum/showpost.php?p=749311&postcount=10

this was integration with vB and Wiki .. it may be in the lines of what you were discussing about not interfering with databases from each application

balupton wrote:

Although then with synchronisation, you have the problem of getting the information of existing users synched in the first place. If you have any ideas on how this could be done, go ahead and tell :)

you could for example provide a separate native b2evo function exposed via SOAP/XML that allows other -trusted- scripts/sites to query the user database, basically providing sort of a memberlist.
However, as soon as you really intend to integrate two different solutions with two distinct sets of database that are meant to serve the same purpose, things can get really tricky, i.e. because of identical records in the underlying databases (for example usernames) which may however not necessarily point back to the same user. That's usually, why you want to avoid working with such scenarios where multiple data sets serve similar purposes, however if you truly have to do so, then there are viable compromises-for example, all forum user names could be automatically prefixed with a "phpBB" or "forum" to indicate where the account originally came from, likewise blog usernames could have a prefix such as "b2evo" or "blog". While this isn't totally intuitive it would at least allow administrators to easily and quickly combine multiple different data sets, with the only inconvenience of requiring your users to specify the additional prefix, be it either as a part of their new login name, or alternatively as a combo/drop down box (menu) where the user may chose the origin of his account.

balupton wrote:

I would say that the database synchronising would be the best idea. And leave the permissions enitirely seperate. So only a user's info and existance are synched. And that would occur on a login, registration, update to a user's profile, and deletion of a user.

Yes, of course it would make sense to keep permissions entirely separate, simply because these are two separate applications-however, I only mentioned permissions, because some web applications natively store this sort of information directly in the user database (tables), that is you will literally depend on actually using the user database if you don't want to duplicate/synchronize data manually-which of course would be totally inconvenient if you are considering to export/import functionality to/from other applications, that's why it`s so crucial to have at least a well-normalized database that doesn't integrate unnecessary information and thus adds complex inter-dependencies.

With regards to synchronizing: I am still not sure if you mean to literally synchronize (i.e. duplicate) any information, or if you are merely referring to making sure that all parties use the same information sources?

As I said: there should be hardly any synchronizing necessary as long as the corresponding tables are properly normalized, so that's basically the most crucial precondition, simply because it would be much easier to expose only certain functionality if it's indeed distinct and not totally integrated.

[url=http://doc.b2evolution.net/DB_schema/b2evo_1_8.png]This[/url] is the database schema for 1.8+, it might help you understand the way that the evocore deals with it's data.

Using your "share users" example as a starting point, there is already the ability for "alternative" authentication built into the evocore (the [url=http://manual.b2evolution.net/Plugins/ldap_plugin]ldap plugin[/url] is probably the best place to gain further information on this).

¥

Wow Yabba has a big star now ;) :)

And yeh by synchronising i do mean duplicating all info, while keeping it the same.

apologies I did not realise ordinary users were unable to see the data on this link >

http://www.vbulletin.org/forum/showpost.php?p=749311&postcount=10

if you are interested in seeing this I can copy&paste it here as it is also available on a few other sources

sure, copy/paste it

¥åßßå wrote:

[url=http://doc.b2evolution.net/DB_schema/b2evo_1_8.png]This[/url] is the database schema for 1.8+, it might help you understand the way that the evocore deals with it's data

Indeed very helpful, thanks for posting this: having had a quick look at the current db schema now, I'd say that while there is some good potential for additional [url=http://en.wikipedia.org/wiki/Database_normalization]database normalization[/url] in various places (i.e. by further splitting up T_users into "T_user_details", "T_user_contact", "T_user_preferences"), implementing what has been requested in this thread should be relatively straightforward, in particular also because you mentioned that there's already LDAP support integrated.

Here we go it is rather long .. this is what he said before the code

MediaWiki has a facility for creating Authentication plugins that let you do the integration pretty easily. They were non-documented when I started with the hack, but once you find the correct template everything was smooth sailing. There are a few comments about the code

- People still need to log on to MediaWiki once, after that they are cookied.
- MediaWiki has a smaller namespace for usernames than vBulletin, on a large board you might have clashes. I'm assuming it's not a security problem, but it might be an inconvenience.
- You need to clean up the user properties pages of things like changing names and stuff (they aren't automatically dropped).
- The Wiki will create only those users who actually log on
- The $usergroupid clauses determine who can create an account, you need to change these clauses to suit your own board.

--------------------------------------------

Add this snippet to you LocalSettings.php. Insert your vBulletin DB information:

require_once("AuthPlugin_vBulletin.php");

$wgAuth = new AuthPlugin_vBulletin(<hostname>, <vb_username>, <vb_password>, <vb_dbName);

And then AuthPlugin_vBulletin.php itself:

<?php


/**
 * Authentication plugin interface. Instantiate a subclass of AuthPlugin
 * and set $wgAuth to it to authenticate against some external tool.
 *
 * The default behavior is not to do anything, and use the local user
 * database for all authentication. A subclass can require that all
 * accounts authenticate externally, or use it only as a fallback; also
 * you can transparently create internal wiki accounts the first time
 * someone logs in who can be authenticated externally.
 *
 * This interface is new, and might change a bit before 1.4.0 final is
 * done...
 *
 * @package MediaWiki
 */
require_once("includes/AuthPlugin.php");

class AuthPlugin_vBulletin extends AuthPlugin {

  // Persistent DB connection
  var $vb_database;

  function AuthPlugin_vBulletin($host, $username, $password, $dbname)
  {
    $this->vb_database = mysql_pconnect($host, $username, $password);
    mysql_select_db($dbname, $this->vb_database);
  }  


  /**
   * Check whether there exists a user account with the given name.
   * The name will be normalized to MediaWiki's requirements, so
   * you might need to munge it (for instance, for lowercase initial
   * letters).
   *
   * @param string $username
   * @return bool
   * @access public
   */
  function userExists( $username ) {
    $username = addslashes($username);
    $vb_find_user_query = "SELECT usergroupid FROM user WHERE LOWER(username)=LOWER('" . $username . "')";
    $vb_find_result = mysql_query($vb_find_user_query, $this->vb_database);
    if(mysql_num_rows($vb_find_result) == 1) {
      $vb_user_info = mysql_fetch_array($vb_find_result);
      $usergroupid = $vb_user_info['usergroupid'];
      // Only registered and admins. Banned and unregistered don't belong here.
      if($usergroupid == "2" || $usergroupid == "5" || $usergroupid == "6" || $usergroupid == "7")
        return true;
    }
    else
      return false;
  }
	
  /**
   * Check if a username+password pair is a valid login.
   * The name will be normalized to MediaWiki's requirements, so
   * you might need to munge it (for instance, for lowercase initial
   * letters).
   *
   * @param string $username
   * @param string $password
   * @return bool
   * @access public
   */
  function authenticate( $username, $password ) {
    $username = addslashes($username);
    $vb_find_user_query = "SELECT password, salt, usergroupid FROM user WHERE LOWER(username)=LOWER('" . $username . "')";
    $vb_find_result = mysql_query($vb_find_user_query, $this->vb_database);
    if(mysql_num_rows($vb_find_result) == 1) {
      $vb_user_info = mysql_fetch_array($vb_find_result);
      $usergroupid = $vb_user_info['usergroupid'];
      
      // Only registered and admins. Banned and unregistered don't belong here.
      if($usergroupid == "2" || $usergroupid == "5" || $usergroupid == "6" || $usergroupid == "7")
        if(md5(md5($password) .  $vb_user_info['salt']) == $vb_user_info['password'])
          return true;
    }
    return false;
  }
	
  /**
   * Return true if the wiki should create a new local account automatically
   * when asked to login a user who doesn't exist locally but does in the
   * external auth database.
   *
   * If you don't automatically create accounts, you must still create
   * accounts in some way. It's not possible to authenticate without
   * a local account.
   *
   * This is just a question, and shouldn't perform any actions.
   *
   * @return bool
   * @access public
   */
  function autoCreate() {
    return true;
  }
	
  /**
   * Return true to prevent logins that don't authenticate here from being
   * checked against the local database's password fields.
   *
   * This is just a question, and shouldn't perform any actions.
   *
   * @return bool
   * @access public
   */
  function strict() {
    return true;
  }
	
  /**
   * When creating a user account, optionally fill in preferences and such.
   * For instance, you might pull the email address or real name from the
   * external user database.
   *
   * The User object is passed by reference so it can be modified; don't
   * forget the & on your function declaration.
   *
   * @param User $user
   * @access public
   */
  function initUser( &$user ) { 
    $vb_find_user_query = "SELECT password, salt FROM user WHERE LOWER(username)=LOWER('" . addslashes($user->mName) . "')";
    $vb_find_result = mysql_query($vb_find_user_query, $this->vb_database);
    if(mysql_num_rows($vb_find_result) == 1) {
      $vb_user_info = mysql_fetch_array($vb_find_result);
      $user->mEmail = $vb_user_info['email'];
    }
    else {
      // ERROR?
    }
  }
}


?>

--------------------------------------------------

I am sure there must be a similarity somewhere

*edit to add php tags ¥*

just a short update: given that we have now learnt that b2evo supports LDAP, too-there should be hardly any reason to actually implement this feature request using SOAP/XML, that is while I am really not sufficiently familiar with vbulletin, I do know for sure that phpBB does also support LDAP, too-so, if your server does allow you to set up/enable an LDAP daemon, you could simply tell both, your blog software and forum software, to simply use LDAP.
For the sake of this feature request, this ought to be really the most straightforward approach.

just thought I would revisit this thread so as to give an update

I now use Drupal via integration vBdrupal with my vbulletin forums

as well as MediaWiki integrated with vBulletin

added to this I am now able to integrate Wordpress effectively with vBulletin

vBdrupal has it own Blog system and I use this set-up in conjunction with providing forum users their own blogs as they only need to register and logon once

the same would apply to Wordpress when and if I provide this feature

coming back to B2evo .. I use this with one of the websites and is only for staff who also have a seperate account for vBulletin

The integration into the original site design with b2evo is the easiest out of the 3 and the presentation is good

That's the update ... and I suppose that integration with vbulletin will not happen

Cheers