sfForkedDoctrineApply plugin
Forked from sfDoctrineApply plugin (version 1.1.1).
It's stripped of Zend Mail dependencies as proposed by stephenrs on symfony forums,
here
Thanks to punkave guys for the original plugin, and Big thanks to stephen for
the modifications.
Requirements
- symfony 1.4
- sfDoctrineGuardPlugin 5.x - installed and configured
Requirements should be similar as the original plugin, although I can only be
sure of symfony 1.4.
When sfDoctrineGuardPlugin will introduce email in official package, our current
plugin should be modified to use sfGuardUser's email field, not it's own.
Changes to sfDoctrineApplyPlugin
- removed all Zend Mail dependency
- created a general library with all sfApplyActions functions
- introduced inheritance to Profile model.
Installation
Installation should be simple as:
symfony plugin:install sfForkedDoctrineApplyPlugin
However it is also possible to install it through archive:
symfony plugin:install sfForkedDoctrineApplyPlugin-1.3.0.tgz
just place downloaded package in your project's root first.
You can also install it manually, unpacking archive, placing it's content in your
project's plugin/ directory, and enabling it in your ProjectConfiguration.class.php file:
config/ProjectConfiguration.class.php
class ProjectConfiguration extends sfProjectConfiguration
{
//....//
public function setup()
{
//....//
$this->enablePlugins('sfDoctrineGuardPlugin');
$this->enablePlugins('sfForkedDoctrineApplyPlugin');
//....//
}
}
After that create migrations:
./symfony doctrine:generate-migrations-diff
Review your migration files after this step, and run:
./symfony doctrine:migrate
./symfony doctrine:build --all-classes
All you need to do now is to enable sfApply module in your settings.yml file:
apps/APPLICATION/config/settings.yml
all:
.settings:
#...#
enabled_modules: [default, ... , sfGuardAuth, sfApply]
Doing this will also automatically add necessary routes to your app
That's pretty much all you have to do. If you're not satisfied with the model
provided, you can extend it using e.g column_aggregation inheritance:
config/doctrine/schema.yml
MyProfile:
inheritance:
type: column_aggregation
extends: sfGuardUserProfile
You can add your own columns, relations, behaviours or even model names if needed.
With doctrine inheritance you can have different profile types.
You can also add your own columns or redeclare to the provided model instead of using aggregation:
config/doctrine/schema.yml
sfGuardUserProfile:
columns:
my_column: { type: int }
#...
Upgrade
sfForkedDoctrineApply 1.4.x series and sfDoctrineGuard 5.x
Upgrading to sfDoctrineGuard 5.0.0 from pevious release can be tiresome and lengthy operation.
Here are few tips to help with that task:
* Remember to drop all relations to sfGuarduser model from your models, and all
relations between sfDoctrineGuard's models first.
* Change your model's foreign key feilds declaration to integer (not int(4) anymore).
* Create migrations, migrate your database, rebuild your models.
* upgrade sfDoctrineGuard.
* redeclare email field in sfDoctrineGuard, since you'll have it empty at first.
sfGuardUser:
columns:
email_address:
type: string(255)
# notnull: true
unique: true
- Run migrations, migrate and rebuild your models.
- Once that's completed, run symfony sfForkedDoctrineApply:upgrade-proiles
- Starting next version (1.5.x probably) sfGuardUserProfile will be dropping
it's own email field in favour of sfGuardUser's one.
1.3.x
If you're upgrading from release earlier than 1.3.0, remember to create migrations:
./symfony doctrine:generate-migrations-diff
Review your migration files after this step. It'll probably try to drop and
recreate sf_guard_profile table, you can remove those two operations from up()
method and down() as well. After that migrate your database, build your model classes
again:
./symfony doctrine:migrate
./symfony doctrine:build --all-classes
./symfony doctrine:clean-model-files
You'll have left sfGuardUserProfileBasis* model, filter and form files inside your project's
lib/filter/doctrine, lib/form/doctrine and lib/model/doctrine. Remove them as
these classes extends ones that no longer exists within plugin.
IMPORTANT: Since there are no longer any Basis files, you have to move any logic
that you kept in those files to sfGuardUserProfile models, forms and filters.
You can extend profile either with doctrine inheritance or just by merging your
profile definition with sfForked's one (just define what you need
Configuration
To configure this plugin to actually send registration emails,
You need to set up email settings according to
day 16 of Jobeet tutorial.
Basic
In order to send emails with confirmation codes you've got to add these settings in your app.yml:
apps/APPLICATION/config/app.yml
sfApplyPlugin:
from:
email: "your@emailaddress.com"
fullname: "the staff at yoursite.com"
You should also turn on i18n engine, as this plugin, like the project it rooted
from is fully internationalised (You might have to prepare i18n files for your language though):
apps/APPLICATION/config/settings.yml
all:
.settings:
i18n: true
You can modify URL's for the sfApply module's action. To do that, simply add this options to your app.yml file:
all:
#...
sfForkedApply:
#...
routes:
apply: /user/new
reset: /user/password-reset
resetRequest: /user/reset-request
resetCancel: /user/reset-cancel
validate: /user/confirm/:validate
settings: /user/settings
Each key's value represents route's url, you can change them as you want.
sfForkedDoctrineApply:clear-validation-codes task
Now sfForkedDoctrineApply makes use of the initialy created validate_at field,
allowing you to expire validate codes. To remove all codes older than a required time just run:
./symfony sfForkedDoctrineApply:clear-validation-codes --d="number_of_days"
You can ommit the --d parameter, to leave the default value of 1 day.
CAPTCHA
Starting from 1.1.0 version, sfForkedDoctrineApplyPlugin integrates reCaptcha. To use it, you have to install sfFormExtraPlugin to get access to reCaptcha widget and validator. Second step is to be conducted in your app.yml file, and add these:
apps/APPLICATION/config/app.yml
all:
#...
recaptcha:
enabled: true
public_key: YOUR_PUBLIC_reCAPTCHA_KEY
private_key: YOUR_PRIVATE_reCAPTCHA_KEY
enabled property is for enabling and disabling captcha. After setting this,
reCaptcha will appear on apply and reset request pages.
Custom forms
It's possible to define custom forms, however all custom forms must extend the
Apply ones. To use custom forms, you need to define them in your app.yml file:
apps/APPLICATION/config/app.yml
all:
#...
sfForkedApply:
applyForm: sfApplyApplyForm
resetForm: sfApplyResetForm
resetRequestForm: sfApplyResetRequestForm
settingsForm: sfApplySettingsForm
The above example uses standard sfApplyForms.
Email editing
To allow users to edit their emails, you've got to add app_sfForkedApply_mail_editable setting:
all:
#...
sfForkedApply:
#...
mail_editable: false
Now, when user will try to edit their email, he'll receive confirmation email on his old address. editMail action will also get route generated which will be composed from settings URL to which "/email" end will be added.
Confirmation disabling
It is possible, although not recommended to disable email confirmations for the following actions:
- Apply (apply) - new users will be registered and logged as soon as they submit valid apply form.
- Password reset (reset) - this will disable the reset request, password change will be possible only for logged in users.
- Email edit (email) - new email will immediately replace old one.
- Password reset for logged users (reset_logged) - this will send confirmation email for logged users (default is disabled).
To disable confirmation emails for any of this actions, simply add and modify following options to application's app.yml file:
all:
#...
sfForkedApply:
#...
confirmation:
reset: true
apply: true
email: true
reset_logged: false
Login redirect
There are two settings regarding directing user after actions he takes within sfApply module:
all:
#...
sfApplyPlugin:
afterLogin: after_login_route
after: after_route
You can use these settings to direct user to your own pages after user loggs in, or in other cases with second setting.
Displaying Login and Logout Prompts
(fragment of sfDoctrineApplyPlugin's README)
You probably have pages on which logging in is optional. It's nice to
display a login prompt directly on these pages. If you want to do that,
try including my login/logout prompt component from your
apps/frontend/templates/layout.php file:
<?php include_component('sfApply', 'login') ?>
Note that you can suppress the login prompt on pages that do include
this partial by setting the sf_apply_login slot:
<?php slot('sf_apply_login') ?>
<?php end_slot() ?>
Credits
sfDoctrineApplyPlugin was written by Tom Boutell. He can be contacted
at tom@punkave.com. See also www.punkave.com and
www.boutell.com for further information about his work.
Changes resulting in forking the original plugin were written by stephenrs.
sfForkedDoctrineApplyPlugin was created by Grzegorz Śliwiński as a result of those changes with some additions.
You can contact him at fizyk@fizyk.net.pl or through
jabber/xmpp at fizyk@jabbim.pl and follow his adventures on his homepage.
Translations
- French - Pierre Grandin
- Italian - Alessandro Rossi
- Polish - Grzegorz Śliwiński
- Russian - Serg Puhoff
