Hi Tom,
Great news! We had a discussion already half a year ago on this topic.
Did not have the time to do it myself as I was full of deadline
projects.
Had a peak in de code, and have a small request: Can you enhance the
schema.yml also with a 'middle_name'? In Holland, and maybe other
countries, we have these akward names like
'Jan de Jong', where 'de' should not be in the last name, e.g. it
should be sorted on 'Jong'.
Maybe you can make an app_setting for it. Or I can commit some code
for it. Let me know,
Thanks, Lambert
On Jul 1, 9:28 pm, Tom Boutell t...@punkave.com wrote:
The svn trunk of sfDoctrineApplyPlugin will soon contain bleeding edge
code. You should NOT pin the svn:externals of your project to the
trunk.
Instead, you may pin them to the new 1.1 branch, which contains the
stable release you're used to. Change your externals to read like so:
sfDoctrineApplyPluginhttp://svn.symfony-project.com/plugins/sfDoctrineApplyPlugin/branches...
You could also pin them to the new 1.2 branch, but that would require
considerable work on your part (read on).
I will leave the trunk in its current boring state for one month to
give folks a chance to take notice of this change. I have also placed
a warning file in the trunk.
Development of the 1.2 branch is quite far along, and in fact there's
a fully working version in the 1.2 branch now, with the following
major changes, many of which are breaking changes unless you do some
migration work on your database:
* Relies on extension of the sfGuardUser table rather than a profile
class for better database normalization
* Forms are now empty extensions of Base versions so you can do the
usual Symfony thing to override them at the project level (you can
also use my app.yml approach)
* Forwards and backwards compatible with sfDoctrineGuardPlugin's
current stable release and its new trunk version
* First name, last name and email address fields now consistent with
sfDoctrineGuardPlugin's new trunk
* Uses Symfony's built-in SwiftMailer support, removing the Zend
Framework requirement
FAQs:
But I'm already using it and I don't want to make changes!
Don't. Keep using the 1.1 branch. Upgrading is pretty tough, in
particular because the old version only has a fullname field and you
have to migrate fields from profile to sfGuardUser.
But sfDoctrineGuardPlugin's new trunk has its own register feature!
Yes, but it has no email confirmation of new accounts, so it does not
currently meet the needs of most sites that are currently using the
apply plugin.
Doesn't sfDoctrineGuardPlugin's trunk have its own Forgot Password
feature?
Yes, and it does do email confirmation. It's pretty much equivalent to
the same feature in the apply plugin. Use it if you like it.
What is the future of sfDoctrineApplyPlugin?
We'll see! If sfDoctrineGuardPlugin incorporates email confirmation
for new accounts, it might not be necessary to maintain a separate
plugin anymore.
Do I have to use the svn trunk of sfDoctrineGuardPlugin?
No. sfDoctrineApplyPlugin's 1.2 branch works with both the 1.3 branch
(aka the 1.4.x release versions) *and* the trunk of the guard plugin,
thanks to schema merging.
When will a stable 1.2 release appear?
Shouldn't be long, since we need this in a finalized form for our own
projects.
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups symfony users group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
