core user_login customization -- getting breakout theming AND custom validator working at the same time?
i'm trying to: custom theme my user_login form AND add a custom validation step to my user_login form rather than re-inventing the wheel, i'm following the theming method @ "Theming the Drupal 6 User Login Form" http://blog.aphexcreations.net/2009/04/theming-drupal-user-login-form.html and the Authentication example @, "Pro Drupal Development" Ch6: External Login: Simple External Authentication i'm confused about their combination -- specifically, getting the themeable login form to USE the custom login authenticator. so far i've: added to a custom.module ... function custom_theme() { return array( 'user_login' => array( 'template' => 'user-login', 'arguments' => array('form' => NULL), ), ); } function custom_user_login(&$variables) { $variables['rendered'] = drupal_render($variables['form']); } ... as well as the form element "breakout" function, ... function get_user_login_form() { $form_id = 'user_login'; $form = array(); $form['name'] = array( '#type' => 'textfield', '#maxlength' => USERNAME_MAX_LENGTH, '#required' => TRUE, '#attributes' => array('tabindex' => '1'), ... $form['#validate'] = user_login_default_validators(); $form['#build_id'] = sprintf('form-%s', md5(uniqid(mt_rand(), TRUE))); ... return $out; } ... in my user-login.tpl.php, i have ... <div> TESTING 1 2 3 TESTING 1 2 3 <?php $login_form = get_user_login_form(); ?> <?php print $login_form->form_start; ?> <div><?php print $login_form->name; ?></div> <div><?php print $login_form->pass; ?></div> <div><?php print $login_form->submit; ?></div> <?php print $login_form->form_end; ?> </div> ... which DOES display correctly @ "user/login". that's good. from "Pro Drupal Development", I'm adding a custom validation step ... in my custom.module: ... function custom_form_alter(&$form, $form_state, $form_id) { switch ($form_id) { case 'user_login': case 'user_login_block': // If the user login form is being submitted, add our validation if (isset($form_state['post']['name'])) { // Find the local validation function's entry so we can replace it $array_key = array_search( 'user_login_authenticate_validate', $form['#validate'] ); if ($array_key === FALSE) { // Could not find it. Some other module must have run form_alter() // We will simply add our validation just before the final validator $final_validator = array_pop($form['#validate']); $form['#validate'][] = 'custom_login_validate'; $form['#validate'][] = $final_validator; } else { // Found the local validation function. Replace with ours. $form['#validate'][$array_key] = 'custom_login_validate'; } } break; } } ... But, what gets used/displayed by my user-login.tpl.php continues to use the 'standard' authenticator, NOT my custom one. I suspect that's because of: @ function custom_form_alter --> $form['#validate'][$array_key] = 'custom_login_validate'; "versus" @ function get_user_login_form --> $form['#validate'] = user_login_default_validators(); They likely need to be sync'd up. My question is -- how? Any pointers appreciated. Ben
Have you given thought to adding a '#theme' attribute to the form in hook_form_alter E.g. $form['#theme'] = 'my_theme_function' Then either use your template (defined in hook_theme for the my_theme_function) or make the function stitch the fields together in the required format See http://drupal.org/node/751826 under 'Theming forms' for examples/details etc
But, what gets used/displayed by my user-login.tpl.php continues to use the 'standard' authenticator, NOT my custom one.
Hi again Lee, On Wed, May 19, 2010 at 2:45 PM, Lee Rowlands <leerowlands@rowlands-bcs.com> wrote:
Have you given thought to adding a '#theme' attribute to the form in hook_form_alter
I'd looked at, but, tbh, I'm not at a point yet where I've 'internalized' this enough to make a sound decision. Seems that there's almost _always_ another way to do it ;-) I'm bouncing around from doc snippet to doc snippet, generally getting each one working relatively quickly & easily. That's good. Trying to stitch this all together is proving challenging so far ... waiting for the 'lightning bolt'! I'll share the overall context of what I'm trying to achieve here -- and ask for comment as to approach. Here we go: I want to change the process workflow of form submission & user auth, using, as much as possible, available core tech'y & modules. Using 'Search' as an example action: I've 3 user roles, Anonymous VerifiedHuman RegisteredMember On front page, display search bar/box any/ALL users @ text entry & Submit of search, interrupt/redirect BEFORE submitting to search backend, 'store' original search criteria check logged in state (1) if LoggedIn as RegisteredMember push original Search to search backend present search results include advanced_search option to modify/filter/resubmit search in search result form. (2) if LoggedIn as VerifiedHuman display selector (a) LogIn as RegisteredMember continue @ (1) (b) Create new Account exit search to launch (User Reg) process (c) Continue as VerifiedHuman present simple/unmodifiable search results (3) if !LoggedIn, currently Anonymous display selector (a) exit to home page (b) display/submit (re)Captcha (i) if success continue @ (2) (ii) if fail >= 3x ban IP from Search form access for 180 min. exit to home page To get 'this' done, I'm hoping to leverage as much as possible of core's user.module & contrib'd Captcha.module. I've also started looking at core's Trigger, and contrib Rules.module -- but am not convinced they're helpful, or not. So, that said -- is your suggestion of '#theme' still a good approach? In the meantime, I'll dig @ http://drupal.org/node/751826. Thanks! Ben
The #theme will allow you to redesign the output of the login form, if that is what you want to do.
So, that said -- is your suggestion of '#theme' still a good approach? In the meantime, I'll dig @ http://drupal.org/node/751826.
On Wed, May 19, 2010 at 5:23 PM, Lee Rowlands <leerowlands@rowlands-bcs.com> wrote:
The #theme will allow you to redesign the output of the login form, if that is what you want to do.
Actually, that's not the primary goal -- as above, the goal is to change the workflow of submission & authentication. Overstayed my welcome I think :-) I'll need to get this figured out on my own. Thanks for your time and suggestions, though! Ben
Hi ben In which case you are looking at a multi-step form again I'm trying to think of a good example to refer you to but are coming up blank :-(
Actually, that's not the primary goal -- as above, the goal is to change the workflow of submission & authentication.
On Wed, May 19, 2010 at 5:43 PM, Lee Rowlands <leerowlands@rowlands-bcs.com> wrote:
Hi ben In which case you are looking at a multi-step form again I'm trying to think of a good example to refer you to but are coming up blank :-(
np! appreciated :-) as 'flexible' as Drupal is, I find the same lack of 'real world' examples for anything but the simplest matters ... "Pro Drupal Development" sums it up nicely: "If you come from a background where you have created your own forms directly in HTML, you may find Drupal’s approach a bit baffling at first." Imo -- amen! In DIY HTML/PHP, 'this' is all trivial. In Drupal, Creating a new form with Webform is trivial. Creating a new form programatically via module takes a bit of reading-up.. Altering a core-form is pretty straightforward. Building a non-standard workflow around core forms, using Drupal internals and 3rd party module extension is ... a bit challenging. Trying to contact the developers whose modules I'm trying to understand/extend has been less than fruitful, receiving a sometimes cool reception ... though I _have_ received offers to take my money for paid consulting ;-) This list, and Pro Drupal have been the best help so far. Cheers, Ben
I am shooting here but have you tried changing: @ function custom_form_alter --> to @ function get_user_login_form_alter --> </ryan> On Wed, May 19, 2010 at 8:04 PM, Ben DJ <bendj095124367913213465@gmail.com>wrote:
On Wed, May 19, 2010 at 5:43 PM, Lee Rowlands <leerowlands@rowlands-bcs.com> wrote:
Hi ben In which case you are looking at a multi-step form again I'm trying to think of a good example to refer you to but are coming up blank :-(
np! appreciated :-)
as 'flexible' as Drupal is, I find the same lack of 'real world' examples for anything but the simplest matters ...
"Pro Drupal Development" sums it up nicely:
"If you come from a background where you have created your own forms directly in HTML, you may find Drupal’s approach a bit baffling at first."
Imo -- amen!
In DIY HTML/PHP, 'this' is all trivial.
In Drupal,
Creating a new form with Webform is trivial. Creating a new form programatically via module takes a bit of reading-up.. Altering a core-form is pretty straightforward.
Building a non-standard workflow around core forms, using Drupal internals and 3rd party module extension is ... a bit challenging.
Trying to contact the developers whose modules I'm trying to understand/extend has been less than fruitful, receiving a sometimes cool reception ... though I _have_ received offers to take my money for paid consulting ;-)
This list, and Pro Drupal have been the best help so far.
Cheers,
Ben
Ryan, On Wed, May 19, 2010 at 6:45 PM, Ryan LeTulle <bayousoft@gmail.com> wrote:
I am shooting here but have you tried changing: @ function custom_form_alter --> to @ function get_user_login_form_alter -->
iiuc, the form of hook_theme_alter() is module_name_theme_alter as it's custom.module, that'd have to be custom_theme_alter Ben
as 'flexible' as Drupal is, I find the same lack of 'real world' examples for anything but the simplest matters ...
Generally I think of a module that does the same thing and then look to their code, for a huge multi-step form, have a look at node_import
"If you come from a background where you have created your own forms directly in HTML, you may find Drupal's approach a bit baffling at first."
Yes but the XSS, CSRF, session mgmt, user mgmt, permission mgmt and so on and so on benefits make it worth the time.
In DIY HTML/PHP, 'this' is all trivial.
Yes but see previous point, getting 'this' with 'those' features done properly is not trivial
Building a non-standard workflow around core forms, using Drupal internals and 3rd party module extension is ... a bit challenging.
Yes you are jumping in at the deep end
Trying to contact the developers whose modules I'm trying to understand/extend has been less than fruitful, receiving a sometimes cool reception ... though I _have_ received offers to take my money for paid consulting ;-)
Well in general with custom requirements you can have it now or you can have it free, but rarely both
On Wed, May 19, 2010 at 8:25 PM, Lee Rowlands <leerowlands@rowlands-bcs.com> wrote:
Yes but the XSS, CSRF, session mgmt, user mgmt, permission mgmt and so on and so on benefits make it worth the time.
Yes but see previous point, getting 'this' with 'those' features done properly is not trivial
i was , of course, NOT suggesting that one should build said solution in Assembler ;-) There are _plenty_ of robust frameworks out there that provide the "deep end" as cleanly as, or arguably more so, than Drupal. again, yes, there are interesting downstream benefits to be had ...
Well in general with custom requirements you can have it now or you can have it free, but rarely both
Heh, sure. Shame, though, a simple user login workflow is so "custom". I'm just ... amused ... by the 'sales pitch': "Hi. Let me be short with &/or rude to you. But if you'd like to pay me to work with you, I'm sure you'll find me cuddly and a joy to work with!" ;-D Ben
"Hi. Let me be short with &/or rude to you. But if you'd like to pay me to work with you, I'm sure you'll find me cuddly and a joy to work with!" lol
Another module to look at is the CTools suite (http://drupal.org/project/ctools) by the man who brought us views. It wasn't my cup of tea in the end but there's also a pretty good example at http://www.nicklewis.org/using-chaos-tools-form-wizard-build-multistep-forms... which takes you through it in some depth. On 6:59 AM, Lee Rowlands wrote:
Generally I think of a module that does the same thing and then look to their code, for a huge multi-step form, have a look at node_import
Anth, On Thu, May 20, 2010 at 8:25 AM, Anth <malkouna@yahoo.com.au> wrote:
http://www.nicklewis.org/using-chaos-tools-form-wizard-build-multistep-forms... which takes you through it in some depth.
Thanks for the reference! Hadn't seen that one, yet :-) For the moment, I'll use it as just that -- a reference. I need to hold-off on crowbarring yet another module into the mix until I've got a solid handle on what I'm doins so far ... Ben
Made progress ... mainly an exercise in what NOT to include from the various examples out there :-/ hook_alter-ing the user_login form from inside my module (custom.module), I can correctly replace the local login validation handler with my own custom handler. I have validated the switch (simply with, <?php print print_r($form['#validate']); ?>), and can add my own validation criteria. Captcha module integration/use works in display & submission using standard validator; I haven't yet figured out how to _move_ the Captcha validation "into" my custom validator -- that's next ... In the process of switching to a/my "module-based" implementation, what gets 'referenced' and what gets 'printed' changes a bit. i'm looking for a bit of clarification on the changes ... in the module-based implementation, instead of @ template.php -------------------------------------------------- ... function get_user_login_form() { $form_id = 'user_login'; $form = array(); $form['name'] = array( '#type' => 'textfield', '#maxlength' => USERNAME_MAX_LENGTH, '#required' => TRUE, '#attributes' => array('tabindex' => '1'), ... $form_state = array(); drupal_prepare_form($form_id, $form, $form_state); drupal_process_form($form_id, $form, $form_state); $out = new stdClass; $out->form_start = sprintf("<form method='post' accept-charset='UTF-8' action='%s'>", url('user/login')); $out->form_end = "</form>"; $out->name = drupal_render($form['name']); $out->pass = drupal_render($form['pass']); $out->submit = drupal_render($form['form_id']) . drupal_render($form['form_build_id']) . drupal_render($form['submit']); return $out; } ... -------------------------------------------------- and, @ user-login.tpl.php -------------------------------------------------- ... <?php $login_form = get_custom_user_login_form(); print $login_form->form_start; print $login_form->name . '<br />';' print $login_form->pass . '<br />'; print $login_form->submit; $login_form->form_end; ?> ... -------------------------------------------------- I've, @ custom.module -------------------------------------------------- ... function custom_form_alter(&$form, $form_state, $form_id) { switch ($form_id) { ... case 'user_login': case 'user_login_block': $form['name'] = array( '#type' => 'textfield', '#maxlength' => USERNAME_MAX_LENGTH, '#required' => TRUE, '#attributes' => array('tabindex' => '1'), ); ... $form['#build_id'] = sprintf('form-%s', md5(uniqid(mt_rand(), TRUE))); $form_state = array(); break; } } ... -------------------------------------------------- and, @ user-login.tpl.php -------------------------------------------------- ... <?php print drupal_render($form['name']) .'<br />'; print drupal_render($form['pass']) .'<br />'; // print drupal_render($form['form_id']) . // print drupal_render($form['form_build_id']) . print drupal_render($form['submit']); ?> ... -------------------------------------------------- As a result of NOT declaring a new $login_form object, wherein I've defined $out = new stdClass; ... and, instead, 'using' the altered, existing user_login form, I've (1) 'lost' the convenience of object notation, ... print $login_form->name . '<br />';' print $login_form->pass . '<br />'; ... and, (2) seemingly made unnecessary use of x $out->form_start = x sprintf("<form method='post' accept-charset='UTF-8' action='%s'>", x url('user/login')); x $out->form_end = "</form>"; $out->submit = x drupal_render($form['form_id']) . x drupal_render($form['form_build_id']) . drupal_render($form['submit']); Questions: (A) How/where would I declare, and use, object notation in the module-case? Simply referencing $form->name in user-login.tpl.php is clearly not correct/sufficient. (B) I'm a bit confused by being able to do without the $form start/end/form_id/form_build_id, but gather that the Drupal engine, via use of the native user_login form, is handling that ... Am I causing any problems by NOT referencing those in my 'new' module-based approach? Ben
Hi Ben I think this is overcomplicating it, from what I gather, you've got everything except the Theming/output/appearance working. To add new elements to your form, just add them using hook_form_alter, the $form variable is passed by reference. In your theme function (#theme), stitch the fields together in the order you want using drupal_render and make a final call to drupal_render($form) before returning the output, that way all of the remaining elements (including form_id, form_build_id etc get rendered). A good example of Theming a form the way you like it is the user list. E.g. this function http://api.lullabot.com/user_admin_account builds the form which is just a huge long list of fields then this function http://api.lullabot.com/theme_user_admin_account stitches the output together as a table using selective calls to drupal_render followed by a final call on the $form element to output the supplementary stuff Lee -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Ben DJ Sent: Friday, 21 May 2010 2:02 AM To: development@drupal.org Subject: Re: [development] core user_login customization -- getting breakout theming AND custom validator working at the same time? Made progress ... mainly an exercise in what NOT to include from the various examples out there :-/ hook_alter-ing the user_login form from inside my module (custom.module), I can correctly replace the local login validation handler with my own custom handler. I have validated the switch (simply with, <?php print print_r($form['#validate']); ?>), and can add my own validation criteria. Captcha module integration/use works in display & submission using standard validator; I haven't yet figured out how to _move_ the Captcha validation "into" my custom validator -- that's next ... In the process of switching to a/my "module-based" implementation, what gets 'referenced' and what gets 'printed' changes a bit. i'm looking for a bit of clarification on the changes ... in the module-based implementation, instead of @ template.php -------------------------------------------------- ... function get_user_login_form() { $form_id = 'user_login'; $form = array(); $form['name'] = array( '#type' => 'textfield', '#maxlength' => USERNAME_MAX_LENGTH, '#required' => TRUE, '#attributes' => array('tabindex' => '1'), ... $form_state = array(); drupal_prepare_form($form_id, $form, $form_state); drupal_process_form($form_id, $form, $form_state); $out = new stdClass; $out->form_start = sprintf("<form method='post' accept-charset='UTF-8' action='%s'>", url('user/login')); $out->form_end = "</form>"; $out->name = drupal_render($form['name']); $out->pass = drupal_render($form['pass']); $out->submit = drupal_render($form['form_id']) . drupal_render($form['form_build_id']) . drupal_render($form['submit']); return $out; } ... -------------------------------------------------- and, @ user-login.tpl.php -------------------------------------------------- ... <?php $login_form = get_custom_user_login_form(); print $login_form->form_start; print $login_form->name . '<br />';' print $login_form->pass . '<br />'; print $login_form->submit; $login_form->form_end; ?> ... -------------------------------------------------- I've, @ custom.module -------------------------------------------------- ... function custom_form_alter(&$form, $form_state, $form_id) { switch ($form_id) { ... case 'user_login': case 'user_login_block': $form['name'] = array( '#type' => 'textfield', '#maxlength' => USERNAME_MAX_LENGTH, '#required' => TRUE, '#attributes' => array('tabindex' => '1'), ); ... $form['#build_id'] = sprintf('form-%s', md5(uniqid(mt_rand(), TRUE))); $form_state = array(); break; } } ... -------------------------------------------------- and, @ user-login.tpl.php -------------------------------------------------- ... <?php print drupal_render($form['name']) .'<br />'; print drupal_render($form['pass']) .'<br />'; // print drupal_render($form['form_id']) . // print drupal_render($form['form_build_id']) . print drupal_render($form['submit']); ?> ... -------------------------------------------------- As a result of NOT declaring a new $login_form object, wherein I've defined $out = new stdClass; ... and, instead, 'using' the altered, existing user_login form, I've (1) 'lost' the convenience of object notation, ... print $login_form->name . '<br />';' print $login_form->pass . '<br />'; ... and, (2) seemingly made unnecessary use of x $out->form_start = x sprintf("<form method='post' accept-charset='UTF-8' action='%s'>", x url('user/login')); x $out->form_end = "</form>"; $out->submit = x drupal_render($form['form_id']) . x drupal_render($form['form_build_id']) . drupal_render($form['submit']); Questions: (A) How/where would I declare, and use, object notation in the module-case? Simply referencing $form->name in user-login.tpl.php is clearly not correct/sufficient. (B) I'm a bit confused by being able to do without the $form start/end/form_id/form_build_id, but gather that the Drupal engine, via use of the native user_login form, is handling that ... Am I causing any problems by NOT referencing those in my 'new' module-based approach? Ben Internal Virus Database is out of date. Checked by AVG - www.avg.com Version: 8.5.406 / Virus Database: 271.1.1/2686 - Release Date: 02/13/10 19:35:00
Hi Ben, I feel your pain here. I just went through something similar to have a timesheet application up and going. One content type representing a timesheet but users with different roles accessing different versions/parts of it at different stages of a workflow. What I found a reasonably elegant solution and gave me a bit of re-use was to set up different templates in the preprocess function (using template suggestions) that will load the same content in a completely different way. Using this with a multi form/step I got it all working without doing any theme work or worrying how it looked and then added all my theme stuff afterwards. I do totally agree that this can feel harder than just writing your own stuff from scratch sometimes though. Anthony. On 6:59 AM, Ben DJ wrote:
Hi again Lee,
On Wed, May 19, 2010 at 2:45 PM, Lee Rowlands <leerowlands@rowlands-bcs.com> wrote:
Have you given thought to adding a '#theme' attribute to the form in hook_form_alter
I'd looked at, but, tbh, I'm not at a point yet where I've 'internalized' this enough to make a sound decision.
Seems that there's almost _always_ another way to do it ;-) I'm bouncing around from doc snippet to doc snippet, generally getting each one working relatively quickly& easily. That's good. Trying to stitch this all together is proving challenging so far ... waiting for the 'lightning bolt'!
I'll share the overall context of what I'm trying to achieve here -- and ask for comment as to approach.
Here we go:
I want to change the process workflow of form submission& user auth, using, as much as possible, available core tech'y& modules. Using 'Search' as an example action:
I've 3 user roles,
Anonymous VerifiedHuman RegisteredMember
On front page, display search bar/box any/ALL users
@ text entry& Submit of search, interrupt/redirect BEFORE submitting to search backend,
'store' original search criteria
check logged in state (1) if LoggedIn as RegisteredMember push original Search to search backend present search results include advanced_search option to modify/filter/resubmit search in search result form.
(2) if LoggedIn as VerifiedHuman display selector (a) LogIn as RegisteredMember continue @ (1) (b) Create new Account exit search to launch (User Reg) process (c) Continue as VerifiedHuman present simple/unmodifiable search results
(3) if !LoggedIn, currently Anonymous display selector (a) exit to home page (b) display/submit (re)Captcha (i) if success continue @ (2) (ii) if fail>= 3x ban IP from Search form access for 180 min. exit to home page
To get 'this' done, I'm hoping to leverage as much as possible of core's user.module& contrib'd Captcha.module.
I've also started looking at core's Trigger, and contrib Rules.module -- but am not convinced they're helpful, or not.
So, that said -- is your suggestion of '#theme' still a good approach? In the meantime, I'll dig @ http://drupal.org/node/751826.
Thanks!
Ben
Anth,
I feel your pain here. I just went through something similar to have a timesheet application up and going. One content type representing a timesheet but users with different roles accessing different versions/parts of it at different stages of a workflow.
What I found a reasonably elegant solution and gave me a bit of re-use was to set up different templates in the preprocess function (using template suggestions) that will load the same content in a completely different way. Using this with a multi form/step I got it all working without doing any theme work or worrying how it looked and then added all my theme stuff afterwards.
That's certainly an approach I've considered -- for 'new' form content. My "hurdle", atm, is (re)using the existing forms & modules (user_login, search, captcha, etc -- in my case) to the greatest extent possible. normally, i'd talk to the module designers about extending their modules -- but, so far, they're basically not interested. which is fine.
I do totally agree that this can feel harder than just writing your own stuff from scratch sometimes though.
Tbh, I can get all this 'back end' controller workflow and logic, as well as site-wide theming, MUCH faster & easier using just about any PHP framework (Zend, Cake, Symphony), or even some of the newer CMS (apostrophe). A matter of days-to-weeks -- not this weeks to months business. I keep telling myself that the *eventual* payoff -- huge community and mgmt of the community/content -- will make itself known using Drupal. For quick up-n-running out-of-the-box stuff, Drupal really can't be beat. But for non-standard extension, although the inner workings are there, i'm finding it's not the 'friendliest' environments. Like I said earlier -- *maybe* a lighting bolt will hit. But, atm, I'm having a Margarita and re-considering the wisdom of my choice -- or lack thereof. Ben
Hey Ben, which Pro Drupal Edition are you referring to? </ryan> On Wed, May 19, 2010 at 9:18 PM, Ben DJ <bendj095124367913213465@gmail.com>wrote:
Anth,
I feel your pain here. I just went through something similar to have a timesheet application up and going. One content type representing a timesheet but users with different roles accessing different versions/parts of it at different stages of a workflow.
What I found a reasonably elegant solution and gave me a bit of re-use was to set up different templates in the preprocess function (using template suggestions) that will load the same content in a completely different way. Using this with a multi form/step I got it all working without doing any theme work or worrying how it looked and then added all my theme stuff afterwards.
That's certainly an approach I've considered -- for 'new' form content.
My "hurdle", atm, is (re)using the existing forms & modules (user_login, search, captcha, etc -- in my case) to the greatest extent possible.
normally, i'd talk to the module designers about extending their modules -- but, so far, they're basically not interested. which is fine.
I do totally agree that this can feel harder than just writing your own stuff from scratch sometimes though.
Tbh, I can get all this 'back end' controller workflow and logic, as well as site-wide theming, MUCH faster & easier using just about any PHP framework (Zend, Cake, Symphony), or even some of the newer CMS (apostrophe). A matter of days-to-weeks -- not this weeks to months business.
I keep telling myself that the *eventual* payoff -- huge community and mgmt of the community/content -- will make itself known using Drupal.
For quick up-n-running out-of-the-box stuff, Drupal really can't be beat. But for non-standard extension, although the inner workings are there, i'm finding it's not the 'friendliest' environments. Like I said earlier -- *maybe* a lighting bolt will hit. But, atm, I'm having a Margarita and re-considering the wisdom of my choice -- or lack thereof.
Ben
nm I see it in ch 6 now </ryan> On Wed, May 19, 2010 at 9:27 PM, Ryan LeTulle <bayousoft@gmail.com> wrote:
Hey Ben, which Pro Drupal Edition are you referring to?
</ryan>
On Wed, May 19, 2010 at 9:18 PM, Ben DJ <bendj095124367913213465@gmail.com
wrote:
Anth,
I feel your pain here. I just went through something similar to have a timesheet application up and going. One content type representing a timesheet but users with different roles accessing different versions/parts of it at different stages of a workflow.
What I found a reasonably elegant solution and gave me a bit of re-use was to set up different templates in the preprocess function (using template suggestions) that will load the same content in a completely different way. Using this with a multi form/step I got it all working without doing any theme work or worrying how it looked and then added all my theme stuff afterwards.
That's certainly an approach I've considered -- for 'new' form content.
My "hurdle", atm, is (re)using the existing forms & modules (user_login, search, captcha, etc -- in my case) to the greatest extent possible.
normally, i'd talk to the module designers about extending their modules -- but, so far, they're basically not interested. which is fine.
I do totally agree that this can feel harder than just writing your own stuff from scratch sometimes though.
Tbh, I can get all this 'back end' controller workflow and logic, as well as site-wide theming, MUCH faster & easier using just about any PHP framework (Zend, Cake, Symphony), or even some of the newer CMS (apostrophe). A matter of days-to-weeks -- not this weeks to months business.
I keep telling myself that the *eventual* payoff -- huge community and mgmt of the community/content -- will make itself known using Drupal.
For quick up-n-running out-of-the-box stuff, Drupal really can't be beat. But for non-standard extension, although the inner workings are there, i'm finding it's not the 'friendliest' environments. Like I said earlier -- *maybe* a lighting bolt will hit. But, atm, I'm having a Margarita and re-considering the wisdom of my choice -- or lack thereof.
Ben
Ben, Are you sure your case statement is correct? You have: switch ($form_id) { case 'user_login': case 'user_login_block': // If the user login form is being submitted, add our validation ... PDD: if ($form_id == 'user_login' || $form_id == 'user_login_block') ... emphasis being placed on the || (or) </ryan> On Wed, May 19, 2010 at 9:29 PM, Ryan LeTulle <bayousoft@gmail.com> wrote:
nm I see it in ch 6 now
</ryan>
On Wed, May 19, 2010 at 9:27 PM, Ryan LeTulle <bayousoft@gmail.com> wrote:
Hey Ben, which Pro Drupal Edition are you referring to?
</ryan>
On Wed, May 19, 2010 at 9:18 PM, Ben DJ < bendj095124367913213465@gmail.com> wrote:
Anth,
I feel your pain here. I just went through something similar to have a timesheet application up and going. One content type representing a timesheet but users with different roles accessing different versions/parts of it at different stages of a workflow.
What I found a reasonably elegant solution and gave me a bit of re-use was to set up different templates in the preprocess function (using template suggestions) that will load the same content in a completely different way. Using this with a multi form/step I got it all working without doing any theme work or worrying how it looked and then added all my theme stuff afterwards.
That's certainly an approach I've considered -- for 'new' form content.
My "hurdle", atm, is (re)using the existing forms & modules (user_login, search, captcha, etc -- in my case) to the greatest extent possible.
normally, i'd talk to the module designers about extending their modules -- but, so far, they're basically not interested. which is fine.
I do totally agree that this can feel harder than just writing your own stuff from scratch sometimes though.
Tbh, I can get all this 'back end' controller workflow and logic, as well as site-wide theming, MUCH faster & easier using just about any PHP framework (Zend, Cake, Symphony), or even some of the newer CMS (apostrophe). A matter of days-to-weeks -- not this weeks to months business.
I keep telling myself that the *eventual* payoff -- huge community and mgmt of the community/content -- will make itself known using Drupal.
For quick up-n-running out-of-the-box stuff, Drupal really can't be beat. But for non-standard extension, although the inner workings are there, i'm finding it's not the 'friendliest' environments. Like I said earlier -- *maybe* a lighting bolt will hit. But, atm, I'm having a Margarita and re-considering the wisdom of my choice -- or lack thereof.
Ben
Ryan,
switch ($form_id) { case 'user_login': case 'user_login_block': // If the user login form is being submitted,
just a different approach to form_id match than the book. since those two share a _single_ break statement, the effect is "in either case" ... i.e., OR. Ben
So you've confirmed that your validation function is not firing at all? </ryan> On Wed, May 19, 2010 at 9:45 PM, Ben DJ <bendj095124367913213465@gmail.com>wrote:
Ryan,
switch ($form_id) { case 'user_login': case 'user_login_block': // If the user login form is being
submitted,
just a different approach to form_id match than the book.
since those two share a _single_ break statement, the effect is "in either case" ... i.e., OR.
Ben
participants (4)
-
Anth -
Ben DJ -
Lee Rowlands -
Ryan LeTulle