After installing Fancy Login 1.0-Beta2 (on local WAMP) Drupal 7.0 site give a warning:
Strict warning: Only variables should be passed by reference in fancy_login_page_alter() (line 109 of sites\all\modules\fancy_login\fancy_login.module).
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | fancy_login-variables_passed_by_reference-1090982-12.patch | 1.38 KB | deetergp |
| #10 | fancy_login-variables_passed_by_reference-1090982-10.patch | 972 bytes | deetergp |
Comments
Comment #1
NetStar commentedTheme is custom, made from scratch, but i think that is not the problem here.
Its somewwwhat trivial error, but i just can't find out from where it comes.. anyone have a better eye from me?
Just tell me where and what to look and maybe i can fix it and publish changes here.
Due to this error Fancy Login module simply can't be used on live site.
Comment #2
rubaka commentedI have the same error, using the theme of MAYO. Very urgent need to find a fix ... The author laid out this solution before release.
Comment #3
jspotswood commentedI have the same error using the Bartik default theme. Thus it does not seem theme dependent.
This message might not be seen by others if they disable php reporting of strict warnings.
Comment #4
fraguas commentedwhat worked for me was to take this part of the fancy_login.module:
and change to this:
Comment #5
caponey commentedsame error here
Comment #6
latulipeblanche commentedTnx @fraguas .
This works for me.
Comment #7
reo-2 commentedtnx it works
Comment #9
webengr commentedFYI, Nov 2012,
I upgraded a server from freebsd8 to freebsd9
and from php 5.3 to php 5.4.7
Then I saw this issuse,
I did the above change in the module and it seems to work for us also.
So I concur if this module is ever updated, we should do consider this for the release candidate
Comment #10
deetergp commentedThe changes fraguas suggested in comment #4 solved the issue I was having on my site, so I thought I would roll it into a patch and put it up on this thread for review and hopefully inclusion in future versions of this module, if there are to be any.
EDIT: Ignore this patch, it is no good. Please try the patch in comment #12 in this thread.
Comment #11
deetergp commentedComment #12
deetergp commentedPlease disregard the patch I posted in comment #10 fails a
git apply --check.This patch passes and applies cleanly and should be the one to be used to address this error.
Comment #13
ramrpl commentedits work for me.. thank very very very much,,,
Comment #14
drupaljohngo commentedworked for me as well.
Could it also be that the php.ini settings are set for developmental errors? I take it this error is not found
on production servers?
Comment #15
keti-1931 commentedworks for me as well.
Comment #16
zura_lanch commentedYES - this works perfectly
I had the same error when I moved the site from wamp to acquia dev-desk.
Comment #17
GrantI commented#4 This worked for me, thank you very much indeed!
Comment #18
jaypanVersion 7.x-2.0 returns this whole section of code as a render array, and doesn't call
render()on the form, therefore fixing this issue.Comment #19
jaypanThe issue causing this bug was a result of calling code like this:
The problem here is that drupal_render() expects a variable to be passed to it, that it can then alter directly. I was passing it the result of a function, drupal_get_form(). PHP with strict enforcement doesn't like this (rightfully so).
It is a non-issue now however, as everything is done with render arrays in the new version, and nothing is actually rendered in this function, removing the issue altogether.