Login upgrade / general best practices for package upgrades

So I upgraded my Login package on a production website last night, from 1.0.3rc1 to 1.1.0rc2. I was expecting to have a little bit of trouble, and I did - but it was very manageable. I think it was mostly due to my own not-best practices in how I implemented it on my site. So I have a few questions on how to best implement complex packages like Login (with multiple snippets and chunks) in order to maintain the cleanest upgrade path.

1. Is it best practice to duplicate the pre-packaged chunks and use the duplicates, rather than using the originals?

I had made duplicates of many of the Login chunks, purely out of a need to customize them. But a few, such as lgnForgotPassTpl (the form for the ForgotPassword snippet), I used as-is. It changed in the upgrade, now offering a "Forgot Username" option where you enter your email address. Well, my site uses the email address as the username, so the new chunk didn’t make sense.

I guess I’ve already pretty much convinced myself that the best practice is to make & use duplicates of packaged chunks. But I never read that anywhere, and learned it the hard way, so I guess I’m looking for affirmation or correction on that point.

2. What about the snippets?

I had made modified duplicates of a few of the Login snippets as well, out of need to do some customization. With snippets, I’m guessing that was the wrong approach, and that the best practice is to use the snippet as-is and found a different way to accommodate my custom needs. Otherwise, post-upgrade, I’m using a customized version of an old version of the snippet, but the back-end code has likely changed, potentially causing uncertain results.

3. Lexicon entries

When I modified the original registration chunk, I noticed that the field labels were generated with lexicon entries... [[%register.fullname]] = ’Full Name’, etc. I needed to add some additional fields to my registration form - profile fields like gender, phone, etc, and also ’first name’ and ’last name’. For the consistency’s sake, I created Lexicon entries for these fields as well, and called them in my form the same way.

My new/custom lexicon entries were removed when I upgraded Login.

I’m not 100% clear on why using lexicon entries is practical in the first place... but at any rate, I’m at a loss for what the best practice should have been for naming these fields. Should I have used a different namespace for my custom entries?

Sorry I’m covering so much ground here. Just thought it would be insightful to get some feedback on how to use package components safely.

Quote from: jrotering at Sep 09, 2010, 10:20 AM

1. Is it best practice to duplicate the pre-packaged chunks and use the duplicates, rather than using the originals?

Yes. This is why in my packages (excluding Login), there are no Chunks added to the DB by default - they’re all loaded from the file system, and you can override them with DB-based chunks.

2. What about the snippets?
I had made modified duplicates of a few of the Login snippets as well, out of need to do some customization. With snippets, I’m guessing that was the wrong approach, and that the best practice is to use the snippet as-is and found a different way to accommodate my custom needs. Otherwise, post-upgrade, I’m using a customized version of an old version of the snippet, but the back-end code has likely changed, potentially causing uncertain results.

You shouldn’t be adjusting Snippets *and* expecting a flawless upgrade. You should be submitting feature requests so you don’t have to edit them.

That said, best bet is to save your modified snippet, upgrade, and merge the changes you made manually.

3. Lexicon entries
When I modified the original registration chunk, I noticed that the field labels were generated with lexicon entries... [[%register.fullname]] = ’Full Name’, etc. I needed to add some additional fields to my registration form - profile fields like gender, phone, etc, and also ’first name’ and ’last name’. For the consistency’s sake, I created Lexicon entries for these fields as well, and called them in my form the same way.
My new/custom lexicon entries were removed when I upgraded Login.
I’m not 100% clear on why using lexicon entries is practical in the first place... but at any rate, I’m at a loss for what the best practice should have been for naming these fields. Should I have used a different namespace for my custom entries?

How’d you edit the Lexicon entries? I’m not sure why they erased - that’s strange. If you did it via Lexicon Management, they shouldn’t have erased. You definitely don’t have to use Lexicons on your internal chunks - they’re there for users who don’t override the chunks.

If you are going to use Lexicons, I’d recommend a custom Namespace to do them in, so that they stay within your own confines and never run the risk of getting wiped. Then just load them via a Snippet and reference them in your chunks. That said, if you’re just making an English site, don’t use Lexicons.

Quote from: splittingred at Sep 09, 2010, 11:00 AM

Yes. This is why in my packages (excluding Login), there are no Chunks added to the DB by default - they’re all loaded from the file system, and you can override them with DB-based chunks.

Funny, I was just cursing that approach a few days ago, when I had to go digging to find the sources of the Quip chunks so I could duplicate & customize them. Now I appreciate your reasoning...