I've spent a few hours this past week cleaning up the module and made new tarballs, it still needs some testing but I will probably try it on a production domain tonight. The main change is really that the code is more tidy and only uses session keys rather than autologin cookies, but the update also makes it possible to access Drupal's user profiles. I think it's also good enough to start the work on Drupal 6.x. Some of SpectralDart's work will have to be redone, but the clean up was worth it.
Here is what has changed:
-configuration.inc has changed name configuration.inc.php and has some new entries
-phpbb.module has been split into phpbb.module, phpbb_diagnostic.inc.php, phpbb_sessions.inc.php and phpbb_block_recent_topics.inc.php
What has not changed:
-modifications to phpBB
-database
One catch: If you update the avatar through phpBB then it is not copied to phpBB, but the user will get a warning about this.
Comments
mm nice done arkepp, also
mm nice done arkepp, also good to hear that its time to work on a 6.x release :)
one question:
you say this: "If you update the avatar through phpBB then it is not copied to phpBB, but the user will get a warning about this."
dont you mean copied to drupal? :unsure:
No, I do mean from Drupal to
No, I do mean from Drupal to phpBB. This version no longer blocks access to the Drupal profiles. If you change the email address, signature or password then those are propagated properly.
I am looking into how to best share avatars, but if you have this working then it'll continue to work with this upgrade.
-Arne
Arne, i have a sugestion for
Arne, i have a sugestion for the module, can you make a settings page in the ACP(drupal or phpbb) so that the admin can choose to use the drupal profile or the phpbb profile or both..,
i know many users here prefer using the drupal profile but i like the phpbb profile and other people to (i hope :P)
i also have a little question:
is there much work for converting the module to drupal 6.0?, cause i did some tests on my localhost but the result was nothing els then errors.. i only replaced "$user" with "$account" (i did it so i could use it on my new project).
Anyway hope to see a 6.xx release soon and keep up the good work :)
Cheers
That annoying vsplice
That annoying vsplice kernel exploit, which you may have heard about, has cost me days (none of my boxes were hacked, but I still have to clean up other places), so Drupal 6 is a bit off my radar right now, but it's well within SpectralDart's capabilities I know ;)
If you want to help him out, check out http://drupal.org/node/114774 , if not, don't complain if it takes a while :)
An ACP thing would be too annoying to code up, but it could easily be done through a configuration variable. I'll try to keep it in mind for next time,,, easy to code, but takes a while to test.
thanks for the information
thanks for the information arkepp :), good luck
Let me know where I can help if you need
You already have all of the changes but if you need help from me, you just let me know. For now, I am still using the old module since I needed for the sites I have running ;-)
Cheers
Error mysql
I updated to this new version.
My admin user works.
I created a new user and I got this error going to forum or forum/user page:
SQL ERROR [ mysql4 ]
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE user_id = 1010' at line 3 [1064]
Edit: I got back to the previous version of the module, but i got the same error. It was a problem related to phpbb3 forum, non to the module. I solved deleting all phpbb tables and installing the forum again.
Important piece of information
Hi, sorry I forgot to mention this explicitly above:
When I refactored I tried to do away with the persistent keys, but I didn't quite realize how session length is interpreted.
So under Server Load settings (or similar name, bottom left on the front page in the ACP) please set session length to something longer than 3600 seconds, more like two weeks (1209600).
Good to know
Arne, I have a question/comment/suggestion concerning the login system. Before the refactoring, I used your module together with the module Persistent Login (http://drupal.org/project/persistent_login) and the combo worked just great.
After updating to the new version, persistent logins didn't work anymore. Then I came across your comment about session length, but at the same time I also have in mind what the Persistent Login guys say about the topic:
"Persistent Login is independent of the PHP session settings and is more secure (and user-friendly) than simply setting a long PHP session lifetime."
I found that quite interesting.
You really should start new
You really should start new topics, I almost didn't find back to this one.
Persistent logins are okay if you use this module, but they're a real problem if you don't. (Drupal doesn't like to log out people it doesn't think are logged in, so it's better that the system is consistent and both cookies expires roughly at the same time). Feel free to turn it into a patch, that can go into the archive, but I probably won't apply it as standard since most people don't have that module.
Note that they're also a bit of a security risk, since hijacking one of these is much more valuable than a regular session.
Ok
I thought the location of the reply doesn't matter as the system is sending out those notifications, but I'll remember it.
As for security, like I said the "other" guys say that using a longer session lifetime is less secure. There's a longer thesis with a discussion as well (http://www.jaspan.com/improved_persistent_login_cookie_best_practice). I'm fairly new to Drupal so I don't have a clear picture yet if and how the makers of different modules cooperate, but if they are right I'm wondering if maybe the phpbb module should rely more on persistent_login (or even make it a requirement).
As it's now, it seems like since the refactoring the phpbb module is incompatible with persistent logins (I had to switch back to the older version to make it work again) which is why I thought I'd bring it to your attention. And that's also why it's probably hard to go with a patch - either stick with the pre-refactoring version with persistent logins, or put your money on longer session times and use the refactored version (or any newer version down the road) without.
hi arkepp, i haven't yet saw
hi arkepp,
i haven't yet saw the new code; did you consider the ability to translate strings?
I mean, did you split sentences from code?
No, refactoring and changing
No, refactoring and changing features at the same time is like walking the tight rope with a shotgun in your mouth.
Though now that it's done, patches are welcome ;)
Hi arkepp. Thanks for doing
Hi arkepp. Thanks for doing such an awesome job maintaining this module. I have a few questions though.
If I upgrade, do I have to use both phpBB and Drupal profiles? I actually like how the old version redirects people from the Drupal profile to the phpBB one. Is there like an option that I can keep the old functionality the same? I think having two profiles would get a little confusing for users.
Also, I'm a little confused about the avatar relationship. Let me get this straight. If you save the user picture in Drupal, it is not copied over to phpBB, correct? What if you save the avatar in phpBB, I assume that won't change in Drupal either? If I change my password, email address or signature in either phpBB or Drupal, it will get copied over to both?
Everything is two-way,
Everything is two-way, except pictures which is only sync'ed from phpBB to Drupal. I hope to make it fully two-way when I get a chance.
As I said to demon above, I'll fix something for you guys. If you want you can download the latest version now, and it'll do what you want if you set
$phpbbcfg['allow_drupal_profiles'] = false;
However, I haven't reintroduced the special permission to see Drupal profiles, so you probably want to wait until I cover that case.
The changes compared to last week are all in phpbb.module and configuration.inc.php
This means time to port my changes
Hi,
I guess this means it will be time for me to port my changes? Or did you already implement them? If not, I'll download them tonight and put in my changes as soon as I have a chance. I think it might be a good idea to consider storing everything in Drupal's CVS. That way we can maintain all the versions and a checkin history can be maintained?
Regards..
ported to D6
Hi Arkepp, i just want to say i ported this version to drupal 6 with the help of SpectralDart :), but its only working frome the phpbb side cause of some code change in youre new version..., here is the code for updating the UID table:
ALTER TABLEtable.usersAUTO_INCREMENT = 100;and i had to change the check for exsting user ID's but i did that with the help of SpectralDart
the new code for that check:
function _phpbb_knows_uid($uid) {
global $phpbbcfg;
$query = "SELECT username, user_pass_convert FROM {$phpbbcfg['db_users']} "
." WHERE
user_id= $uid";$res = db_query($query);
//sequence table is removed in D6 so i use the code frome SpectralDart//
if(empty($result))
{
return FALSE;
}
else
{
return $result;
}
}
for the users that want the D6 version just send me an e-mail but using the module for drupal 6 isn on youre own risk
One little modification
I think you want it to be ALTER TABLE
table.usersAUTO_INCREMENT = 1000 not ALTER TABLEtable.usersAUTO_INCREMENT = 100; At least this is what was suggested with the installation instructions. Mind you, I don't think this would be a problem but anyways.I'll start testing the new code you sent me soon. See if I can find a way to make things work from the Drupal side. That is, as soon as I have some time. I'm sure by the time I get some more time some of you will already have a fix by then.
That said, Arkepp, I think it would be worth while to start maintaining the code from CVS. Of course this is up to you but it would be very helpful to maintain the code much more easily and to have some sort of trace of what happened (history).
Cheers
The CVS (which is painful
The CVS (which is painful enough on its own) and release system on Drupal.org does not lend itself to integration projects because it only cares about Drupal versions.
Some thoughts on that here: http://groups.drupal.org/node/9157 (consider subscribing to this group, you've been echoing other people)
I can make my subversion repository public after cleaning up a bit, if that's a solution?
I see...
Ahhhh ok. Thats too bad they don't support projects besides Drupal. Would be a centralized point for Drupal modules and for people to check-in fixes and check the history. The repository is not really a solution since it will only give us access to the files but there will not be any history. Didn't know it was such a pain to use the CVS. It was just a thought. I'll be maintaining an history of my own with sourcesafe on my side but that serves only me ;-). Well, one thing that could be done, if possible, is to have access to the repository and split the 3 phpbb versions we know, for Drupal 4??, Drupal 5 and Drupal 6. As for change submissions, we would need to go through you to get them approved and checked-in to the repository. Thats just an idea. Unless the repository system allows for people to submit changes and for you to reject or accept them?
By the way Arkepp, I'm looking into your refactored phpbb and I am integrating the changes now. Looks a lot cleaner in there. I'll submit my changes to you by email for a full review. Next, I am planning to attack the picture update problem. This will require for me to get into the mechanics of PHPBB and also my available time so.. ITs possible one of you will have a solution by then, who knows!..
BTW Arkepp, in 2 of your functions at least you use db_num_rows. I've had problems with that in the passed and went to check php.net's documentation and there is only db2_num_rows. Could it be it changed for php 5?? Anyways, thats why you will see changes like this for this function for instance :
function _phpbb_knows_uid($uid)
{
global $phpbbcfg;
}
It does basically the same thing except I don't use the db2_num_rows and then the fetch. Should save a little bit of execution time too.
Cheers
Hi, I am lookin at your
Hi,
I am lookin at your Drupal 6 code right now, so far so good :) I'll start a new thread when I have more. Can you email me info on how you'd like to be credited for your contribution? Previous contributors have only wanted Drupal nicknames, but I'd be happy to stick your real name / email address in there if it is of any use to you.
Regarding db_num_rows, you should be lookin at Drupal's abstraction layer, not PHP.net ( http://api.drupal.org/api/function/db_num_rows/5 ). Whether db_num_rows is implemented properly is another matter, but I would think so.
Let me get back to the repository issue when I have more breathing room, I don't think I received more than two patches while it was in CVS anyway. But I do want to make it visible that there are releases available for Drupal 5.x and 6.x.
Ok, back to Drupal 6 testing... :)
Thanks
Hi,
Glad I could help! As for how I would like to be credited, I think we can make due with my drupal nick and email for now. If ever I would need that to change, I will let you know.
As for db_num_rows, it will work if there is more than one row. At least that is how it was for me but.. Some some reason, I couldn't get the other column to show in the SQL QUERY.. It was really strange and it was late at night and I was tired. But anyways, I changed the code slightly but the purpose of that piece of code is maintained even if it changed.
Thats fine by me. When ever we have time, we can think about the repository stuff. It will become important in the not so far future, especially when drupal 7 comes out.
Cheers :)
Update on test
Ok, I've made the fixes necessary in order to support Drupal 6. Here is one of the things that has been giving me a big headache :
function _phpbb_knows_uid needed to be changed.. That was not a problem except that I needed to change a few things because Drupal 6 no longer supports db_num_rows. So I started by doing this :
db_fetch_array can be used when a query includes more than one column, in this case with Arkepp's query we have : $query = "SELECT username, user_pass_convert FROM {$phpbbcfg['db_users']} "." WHERE
user_id= $uid";So you would think that doing the above works. Nope. For some reason db_fetch_array returns NOTHING! I tested the query before saying this and I get 2 columns. Anyways, so I had to modify things to look like this :
In essence, I am asking for one column and db_result should be used when there is only one field. The purpose of function _phpbb_knows_uid is only to check if the user is un the phpBB's database so, is the table element user_pass_convert really necessary? I didn't see anywhere in the case where it was being used. But Arkepp, if you planned for using it one day for something then I'll need to code an extra function for that one.
For those who are experts with Drupal 6 code, maybe you can answer me why db_fetch_array didn't work? db_fetch_object didn't work either......
So thats it. So far so good. Like Arkepp said before, the only thing not supported ar pictures yet. I am not familiar with phpBB's avatar stuff so I'll have to take a look into it.
Cheers
bug?
Hello arkepp, when i was testing the 6 version of this module i was getting some strange erros when i changed user stuff in drupal, but now i'm using the 5 version on a new site and i just wanted the change my password, so when i changed it i got this error:
Query failed: 0 UPDATEphpbb_usersSETusername='demon',username_clean='demon',user_email='mymail@domain.com',user_email_hash='159393334417',user_password= '$H$9T9xivT4OuJWePokhY5qGW7r/U4epI0', user_pass_convert = 0 ,user_sig='' WHERE user_id = 1so the error is in the module i think...
Update : porting refactored version to Drupal 6
Hi everyone,
I'll be submitted by first draft to Arkepp tonight. Lots of work and bug fixes have been made in order to support Drupal 6. Although I'll be spending a few hours more testing to make sure everything is ship shape, I am confident that you can start testings of you own. It should only be a matter of days. If I have time, I hope to check the picture problem.
Cheers