Hi.
As the subject says, I just want expose what I did to integrate and express some opinions, for whoever it can help.
The starting point is to migrate a phpbb forum, and the goal is integrate it in an egw site, offering fudforum and other resources via egw site manager. So, I did a backup of phpbb, and from the egw fudforum, tried to run the phpbb migration script (which is for 2.6.0, luckily the same version than in egw), but had no luck since I got too many errors (I don't remember, but better to forget at this time, I think). So, I installed an standalone 2.6.0 and executed the migration. Things went much better (not perfect, but enought). I also got some errors (not too much, but didn't note down any), and I remember specially the avatar migration, specially with avatar galleries distributed with the same filenames in different directories (which caused not all being available). Then, I ran the consistency checks to make sure everything was not very bad, and they were (mostly?) sucessful. The fact is that I checked basic functionalities and all the users and posts seemed (still seem) to be ok. So, I performed another backup for this conversion. Then, I pretended to import the data from the standalone 2.6.0 into the egw fudforum using the import data utility, but all tries using admin panel options failed, because the egw port lacks scripts and has incompatible hacks. So, I dumped the tables into the egw db and tried to modify in order to make it work (one important thing is that fudforum uses md5 encryptioon, so egw must use md5 encryption, too). This did work, and what I did was these sql sequences for mysql 4.1:
1) The prefix is "phpgw_fud". I renamed manually the phpgw_fud_users table to phpgw_fud_users_old. This is to preserve this table for retries, and has to be done only once.
2) I ran this script:
-- Set the db name
use <your_db>;
DROP TABLE IF EXISTS phpgw_fud_users;
CREATE TABLE `phpgw_fud_users` LIKE phpgw_fud_users_old;
INSERT INTO phpgw_fud_users
SELECT * FROM phpgw_fud_users_old;
-- Add the egw_id field
ALTER TABLE phpgw_fud_users ADD egw_id int(11) UNSIGNED NOT NULL;
UPDATE phpgw_fud_users SET egw_id=0;
-- Insert manual changes (if necessary) and preserve existing accounts...
UPDATE phpgw_fud_users f,egw_accounts w SET f.egw_id=w.account_id WHERE f.login=w.account_lid;
-- End of manual changes
SELECT @existing:=COUNT(*) FROM phpgw_fud_users WHERE egw_id>0;
-- Get the last id in egw
SELECT @maxegw:=MAX(account_id) FROM egw_accounts;
set @diff:=@maxegw-@existing;
select @diff, @maxegw, @existing;
UPDATE phpgw_fud_users SET egw_id=id+@diff+1 WHERE egw_id=0;
3) These remaining lines can be executed, but I didn't use them because of what I'll explain later:
--Set manually the id in egw_account for the group you want your users to belong
set @group:=6;
insert into egw_accounts (account_id,account_lid,account_pwd,account_firstname,account_lastlogin,acc ount_email,account_type,account_primary_group)
SELECT egw_id, login, passwd, name, last_visit, email, 'u',@group FROM phpgw_fud_users WHERE egw_id>6;
-- Login of sitemgr user
SET @anon:='Anonymous';
INSERT into phpgw_fud_users (login,egw_id,passwd)
SELECT account_lid,account_id,account_pwd from egw_accounts WHERE account_lid=@anon;
delete from phpgw_fud_ses;
3b) Go to egw group manager, edit the group and re-add the users from the selection list to make sure the acls are properly set.
4) Copy the messages from the original messages/ directory to the new one. Make sure the webserver is the owner of these files.
This is all (not over yet, stay tuned!). Now what's left is to run consistency checks. Mostly works, but I get some random errors, but the result is that I can see all the users and data in their forums and can visit it all. Everything seems ok... Well, not really.
I checked this from my admin egw account, which isn't the real situation that everyone will handle. This caused some problems. The first one is that using sitemanager, the egw anonymous account must be used, but it *can't match* the fudforum anonymous account. Why? Very simple: any guest could edit, delete, etc most posts (yes, anonymous posts is a feature). This is the reason why in the second part of step 3b) I create an account for the egw anonymous user (which is usually 'Anonymous'), and must be changed if you have another user. With this, I pretend that the egw anonymous user can read but not edit, etc existing anonymous post, and also be able to allow guests post posts. Good solution? Well, the problem is the same: this way it shouldn't be able to edit the *existing* posts, but what about the new? This doesn't work, either. And another problem is that at this time there isn't a egw site manager module for integrating the fudforum as other apps as wiki or phpbrain. And the last problem I haven't been able to deal with properly is the account registration by egw autoregistrarion, which appears "too often".
Then, at this moment what I'm doing is to embed the standalone fudforum in an iframe in sitemgr, using the "frame" element. This seems good (I'm still trying to see if something doesn't work), and the steps 3 and 4 become unnecessary, since the fudforum users are in the standalone installation, and they're not really needed for accesing the site. Surely only a few accounts are necessary in egw for site maintainers of the egw added apps. This allows also to have the latest fudforum version (in fact, with an iframe, you can have anything, a phpbb or whatever), regardless the existing egw integration.
Now, and without even taking a look at the differences between 2.6.0 and the latest 2.7.x (my apologize for anything that is already done), there are some ideas to get a task like the one I intend to get:
- Find a way to restrict anynomus "power". By the expressed above, and depending on the target of the forum, I think that anonymous read access must be allowed, but without any extra privileges.
- Capability of using directories for avatars instead of using only one (which crowds one single directory, doesn't allow avatar categories, etc).
- For a "headacheless" integration with egw (and some others, said without looking at the code) and taking that, according to a post from Ilia, some hacks about authentication schema are necessary for this to work. I suggest to create an "auth_schema" (handling "fudforum internal" as default, "egw", and who knows what others) as a global value in fudforum, so a extended class is created for each "auth_schema" using generic api calls for getting the db connection data and don't have to worry about rest of the code when porting to an external app.
- Group handling. I might be blind, but I haven't found a way to create a group and add members to it. I want this for granting some people to certain exclusive groups (like I had in phpbb).
- Use variable definitions for global settings instead of hardcoding. The globals.php file contains many variables that can be used all over the scripts, even the code, for generating urls and several tasks. If some setting or location is changed after the installation, just modifying the value in the file should be enough, but this only generates the app files that hardcode the value in a literal, instead of using the value. I've had to do this and perform semi-automatic replacements all over the files, and I think this is bad.
Well, I think that's all. Happy new year!
[Updated on: Tue, 03 January 2006 01:08] Report message to a moderator |
Calendar
Search
Help
Members
Register
Login
Home
]