[development] core user_login customization -- getting breakout theming AND custom validator working at the same time?

[Ryan LeTulle]

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 at gmail.com> wrote:

> nm I see it in ch 6 now
>
> </ryan>
>
>
>
> On Wed, May 19, 2010 at 9:27 PM, Ryan LeTulle <bayousoft at 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 at 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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20100519/ccded402/attachment-0001.html