Drupal 4.7

[elmuerte]

I think it's best to hold of the port for Drupal 4.7 untill it's officially released.
There are quite some changes in the functionality, code and database structure.

[tamarian]

Yes, until it's out of beta, released, and maybe even 4.7.1 for major bug fixes :)

[myetalk]

Yes, until it's out of beta, released, and maybe even 4.7.1 for major bug fixes :)
yup, good idea...

[alexanderpas]

AND... there he is... now officially released... i present to you: Drupal 4.7!
http://drupal.org/drupal-4.7.0

[sifuhall]

That's great news!

[alexanderpas]

so... when can we expect vbDrupal v4.7? :D just kidding

[myetalk]

so... when can we expect vbDrupal v4.7? :D just kidding
yeah, I am also wondering this? :)

[elmuerte]

You can first expect a vbdrupal 4.6.6.1 release
after that I might consider looking at what all has to be done for vbdrupal 4.7
there are quite some major changes between drupal 4.6 and 4.7 so I might consider doing some stuff in a different way

[elmuerte]

I've started working on the drupal 4.7 port. I'm going to build the port up somewhat from scratch. I'm going to try keep the vbdrupal code as much as possible seperated from the drupal code, so it would be easier in the future to keep the system up to date.
Another reason so start from scratch is that something don't work in the same way as before. For example they completely changed the bootstrapping.

What I've done so far:
- redone the bootstrap for vbulletin
- redone the settings, now we only have 1 file in the sites directory called settings.php this is pretty much the current config.php, the rest of the initialisation is done by code in the vbdrupal.inc file. As for the settings, only one thing is really required and that is the vbulletin path.
- new database driver
instead of hacking the mysql driver I simply wrote a drive that forwards everything to the vbulletin database backend.

As for the CVS, I'm not going to branch from the current trunk. As I said I'm going to start somewhat from scratch. This would allow us to start from a more clean install, so we can make a cleaner selection of standard modules and optional modules.
I've not submitted any of the code of vbdrupal ng (ng = next generation) to the CVS yet. Before I do that I have to figure out a nicer way for drupal updating.

On my todo list:
- find a way to hook up drupal's updater from within vbulletin, this saves quite some effort when it comes to database modifications.
- figure out a way to support the user table so vbdrupal is more compatible with other drupal modules that use the user table.
- make the rest work

[peach]

will it be at all possible to upgrade from 4.6 to 4.7? Im personally indifferent about this but if it's not possible I'll hold up development of my VbD sites until VbD 4.7 is out.

[elmuerte]

yes, you will be able to upgrade from 4.6 to 4.7
I would be cutting my own throught if I didn't make that possible

[peach]

yes, you will be able to upgrade from 4.6 to 4.7
I would be cutting my own throat if I didn't make that possible
Ok, good to know :)

[tamarian]

I've started working on the drupal 4.7 port. I'm going to build the port up somewhat from scratch. I'm going to try keep the vbdrupal code as much as possible seperated from the drupal code, so it would be easier in the future to keep the system up to date.
....snip
- figure out a way to support the user table so vbdrupal is more compatible with other drupal modules that use the user table.


If you accomplish the second paragraph, the first would be easy.

The problem with most Drupal contributed modules is that they query the user table directly, instead of using the services available from the user module. This is responsible for most of the headaches, IMHO.

One way to solve this problem is to populate the Drupal user table from vB user table with a vB plugin. This seemed too ugly for me when I started with 4.6. Looking back at this option now, it's not that ugly, considering the amount of changes in drupal that have to be done to avoid it. If this method is implemented, all that's left is the user group permissions, and a vB theme. This way vBDrupal will only need modify the user module, settings, and the extra modules and plugins. A much easier upgrade path.

[peach]

One way to solve this problem is to populate the Drupal user table from vB user table with a vB plugin. This seemed too ugly for me when I started with 4.6. Looking back at this option now, it's not that ugly, considering the amount of changes in drupal that have to be done to avoid it

would that not give problems when you want to add user profile fields in Vb, I can imagine that it would take lots of computing power if you have over 50k members.

[tamarian]

would that not give problems when you want to add user profile fields in Vb, I can imagine that it would take lots of computing power if you have over 50k members.

Not really. Profile feilds don't matter. It would only update for one user if email or other drupal related feilds have changed. A single query.

[peach]

Not really. Profile feilds don't matter. It would only update for one user if email or other drupal related feilds have changed. A single query.
Yes but I mean if you extend the basic profile fields from Vb.
For example I might want to make a website revenue sharing website, wich would run of the revenue sharing plugin for vbulletin. Then I would need to add an adsense id/YPN id or whatever to the profile.
that's what I meant, don't know if that is even possible, but it would be nice.

[elmuerte]

I think we have to replace the user.module completely and write a vbulletin plugin for user management.

Anyway, I've almost got the drupal update process working. Have to figure out a way to execute this from vbulletin. Or maybe request to visit the drupal updater page.

[elmuerte]

ok a point of discussion

user_roles


I think we can do a best of both worlds, the current system AND the drupal system. This way you can easily assign a user to a certain role without needing to create a special vb usergroup.

[Southpaw]

I think we have to replace the user.module completely and write a vbulletin plugin for user management.

Anyway, I've almost got the drupal update process working. Have to figure out a way to execute this from vbulletin. Or maybe request to visit the drupal updater page.
Sounds like a beta is just around the corner ;)

[elmuerte]

an alpha maybe