Store users and channels in the database
Fully customizable web chat created using AJAX.
Brought to you by:
frug,
madblueimp
Patch
Script to migrate users from php files to the DB
Well, apparently the upload button submits the patch and there's no way to edit the details, so I'll put them here.
This patch allows you to store your users and channels in the database when using the standalone version. It adds a /password command that anyone can use to change their own password. Admins can use it to change other users' passwords. The patch is on 0.8.2 standalone.
not sure what you mean about To apply the patch, change to the chat directory and run:
patch -p1 < db_users.patch
can you not fix so that you just do something like http://mywebsite/chat/db_users.path
The command is to modify a stock copy of 0.8.2 standalone using the patch command (on unix anyway, I assume there's something similar on windows). If you don't have shell access to your web server, I'm not sure how you would patch it. Maybe there is some standard technique that php programmers use that I'm not familiar with.
I'm hoping that frug will introduce the change into the core code so that end users can use it without patching. It's going to take some time for him to determine if it's appropriate and whether I completely made a mess of it or not, though.
Hah. I doubt you made a mess of it. But I do need to make a decision on whether this should be in the core code or not. I think, ideally, it would be an optional module. Why? Because it could make it more difficult for people to use the standalone chat as a basis for integration with other systems.
If they create database tables for users/rooms and then don't use those tables because they've used chat for a custom integration job, it's not ideal.
So either this should be a new release, or it should come 'bundled' with the standalone, so people have the choice to use this (actually I would make this the default) and then if they want to custom integrate it, then can start from the old core.
Yes no maybe?
Yes, I see what you're saying. You know better than I how people will use it. I considered implementing it so that you could specify the table/column name for each field, but it seemed like that would get really complicated.
I'm not familiar enough with the codebase (or PHP) to know how this would be implemented as an optional module, so if you'd like me to change things around I'll need an example to look at. If it's easier for you to just do it yourself than to try to explain it to me, that's fine too. Just let me know what you want me to do :)
I'm going to release 0.8.3 first because it's about time and has some good changes, and then consider this for the next release along with a few other database changes I'm considering (for a welcome message, and possibly user statuses) . So all changes to the database will get left until next release. I don't think there will be conflicts with this patch except for the new language files.
Not sure what the best route to make this change optional is. You put a lot of work into this patch (even included the languages) so it'll take me a while to look through it.
That sounds like a good plan.
The language changes I made are all bogus except English. I inserted the English entries into all the other language files, since it seems to throw an error if there's no entry found. I figured an English message was better than no message.
So with the move to github this is the last remaining unused patch that is pending implementation. I have come back to this for consideration after so many years because I'm slow that way.
For now I will leave this open. It won't be in 0.8.6 but the files are still available.