WebLoginPE v1.3.1 Bugfix (Released August 5th!)

The SessionHandler function (starting on line 2386 in the wlpe131modded version I’m working with) is where you need to start looking; I haven’t gone beyond tracing the code to this function. This should replace the SESSION values with the new values for the user, but it looks as if these are getting lost somewhere.

I’m about to start on a resume/job search type of application, so I’ll be digging into this snippet pretty hard this week.

FYI, just added the first initial build to the Google Code SVN (http://code.google.com/p/webloginpe/). Granted, it’s just a copy of version 1.3.1, but it’s a start. Will start layering in my changes into the code. Once that’s done, I’ll reply back and let everyone know. That way we can start doing bug fixes and the like.

Jeff

Quote from: Bravado at Sep 04, 2008, 02:35 PM

FYI, just added the first initial build to the Google Code SVN (http://code.google.com/p/webloginpe/). Granted, it’s just a copy of version 1.3.1, but it’s a start. Will start layering in my changes into the code. Once that’s done, I’ll reply back and let everyone know. That way we can start doing bug fixes and the like. 

Jeff

Looks like everything’s up now.

So to make edits, what’s the procedure? I’ve never messed around with a SVN before.

Once I know what I need to do to make revisions, I can start doing template/lang fixes. I might try my hand at splitting the messages into good (green?) and bad (red?), which is a feature I’ve been wanting to implement.

EDIT: Man, the changes feature in Google Code kicks ass. I <3 this thing. ^.^

EDIT2: Since we now have an issue tracker (which can be sorted, unlike the format of this forum), you guys think we should lock/archive (not remove yet, since there might be some bugs we missed), and add a sticky post that links to the issue tracker on Google Code? I think this would make "checking" off bugs a whole lot easier for us.

My idea would be to desticky+close the old bug report topics (bug/template/etc.), and link to them in the new topic (for archiving purposes only), for those who wanted to check them out. That way, we reduce the clutter, and we don’t have two places to check for bug reports, since a lot of the users here are skilled enough to be able to use Google Code to submit bugs.

(Which reminds me. How can we add milestones to this project’s issue tracker? We’d need one for v1.3.1, and another for the v1.3.2 release, in case anyone was running alpha/beta-level code.

EDIT3: I’ll also try my hand at porting over Scotty’s documentation to the Wiki there.

Got everything posted up including my changes. I went ahead and set the snippet and class files to version 1.3.2 Beta 1. Figured that would be a good identifier for now.

@Soshite: Not sure about how to set milestones in Google Code. Should probably look into that though.

However, to learn both Google Code and SVN, I would recommend creating a bogus Google Code project just for yourself and play around with it. And for learning SVN, doesn’t get any better than a good book. Here’s a good one: http://svnbook.red-bean.com/

What OS are you on? Could recommend a good SVN client for you.

Jeff

Quote from: Bravado at Sep 04, 2008, 04:42 PM

What OS are you on? Could recommend a good SVN client for you.

Jeff

I’m using TSVN on Windows Vista. Just a guess, but it is basically just uploading a new version of the file, and Google Code marks the edits?

BTW, I got a test page set up on the Wiki. Gonna see how porting Scotty’s documentation over works w/ this.

I just figured out how to do milestones. Lemme set them up, and I’ll edit this post.

EDIT: If you check under Administer, and then the Issue Tracking area, you’ll see what I added.

Just type in Milestone, and you’ll see ones for 1.3.1, 1.3.2, and 1.4.0. More can be added if needed, as well as other tags. I invalidated the "test" issue I made, so it doesn’t appear anymore.

In case anyone didn’t see it in my edits, anyone against unstickying the old bug report topics, and making a topic that links to the Google Code issue tracker (so everything’s in one spot). I’ll write up a quick guide to adding issues for the less technical users here.

We’ll still have links to the old bug report topics, but they’re won’t be stickied anymore (and it’ll remove the clutter) --- they would be for archivial purposes in case there were bugs we missed.

Make the link to Google code and to the legacy bug reports that are currently stickied, and I’ll make it so. Let me know when you’re ready. Thanks!

(You should put the links in your signature too!)

FYI, I have a few bugs I’ll be testing for and applying to the SVN. I also have a few other updates coming up as well. Had one yesterday with a client. They needed to set the notification email address to the one that is set in the User tab of the MODx configuration. Added a way to set it as the default if needed.

Jeff

to set the notification email address to the one that is set in the User tab of the MODx configuration

If we suppose WLPE to get integrated in MODx as much as possible - shouldn’t this feature/option be the default? Additional emails could be set in the optional parameter...

Different thing: my multiple instances solution (http://modxcms.com/forums/index.php/topic,27971.0.html) is fully backward compatible but its parameter names ’&instance’ could be ’&id’ and ’&shy’ could be ’&hide’ or something more speaking. (These parameters are optional.) This addition in it’s two formats have been downloaded for 37 times to date.
Do you think that it should be part of the release line by adding it to the svn?