Closed (fixed)
Project:
Drupal core
Version:
6.x-dev
Component:
profile.module
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
5 Dec 2007 at 23:17 UTC
Updated:
24 Dec 2007 at 09:23 UTC
Jump to comment: Most recent file
Comments
Comment #1
aozuas commentedBug is happening when ativating the module Profile, after installing.
Comment #2
keith.smith commentedAfter seeing your initial report, I installed a new copy from scratch of Drupal 6 Beta 4, without any problems. I've enabled the profile module, created a test profile field, went to the My Account page and entered a dummy value for that field, all without any issues.
Could there be something else causing this? Can you provide some details about your system (web server OS, version and type of web server --though you seem to be running XAMPP)? Do you have other contributed modules installed (i.e.: modules other than what shipped with the Beta 4)?
Comment #3
aozuas commentedAfter the first installation and the problem I installed five new copies from scratch and activated the modules one by one until detect the problem. Then I detected that the Profile module was crashing the system. I download this version here in the site, no additional modules, just the package I downloaded. I am running ok a new installation now, but without the Profile module activated.
Details about my system:
2Gb RAM
Windows XP
XAMPP 1.6.oa
PHP Version 4.4.5
XAMPP Status:
MySQL database ACTIVATED
PHP ACTIVATED
HTTPS (SSL) ACTIVATED
Common Gateway Interface (CGI) ACTIVATED
Server Side Includes (SSI) ACTIVATED
SMTP Service DEACTIVATED
FTP Service DEACTIVATED
Comment #4
alex ua commentedI'm getting the same error on a clean Drupal 6 install, I tried both beta4 and dev versions (December 7 version).
My specs are:
Apache/1.3.37 (Unix)
PHP 4.4.7
MySQL 4.1.22
mod_auth_passthrough/1.8
mod_log_bytes/1.2
mod_bwlimited/1.4
FrontPage/5.0.2.2635.SR1.2
mod_ssl/2.8.28
OpenSSL/0.9.7a
PHP-CGI/0.1b
(I also changed the title slightly)
Comment #5
alex ua commentedI'm not sure why profile_admin_overview was updated for 6, but switching
function profile_admin_overview(&$form_state = NULL)
back to it's 5.x iteration
function profile_admin_overview()
Seems to have fixed the problem on my site. But, I am far from a PHP programmer, so I am not really knowledgeable enough to know why this change was made for 6.
Comment #6
alex ua commentedNot sure if it's related, but editing the profile now gives me "notice: Undefined variable: w in home/MyWebSite/public_html/modules/profile/profile.module on line 350." If not I will open a new ticket...
Comment #7
alex ua commentedThat last comment is unrelated, but seems to be its own bug (possibly related to PHP4?). Changing line 350 from
$fields[$category] = array('#type' => 'fieldset', '#title' => check_plain($category), '#weight' => $w++);
to
$fields[$category] = array('#type' => 'fieldset', '#title' => check_plain($category), '#weight' => $weight++);
Fixes the error.
Comment #8
keith.smith commentedI've marked at least two other issues as duplicates of this, btw.
This [apparently] occurred during or is related to drag-and-drop ordering for profile module. http://drupal.org/node/193998
Comment #9
JirkaRybka commentedThat function argument was indeed introduced in http://drupal.org/node/193998 - through all the patches on that issue it goes in multiple variations (
&form_state,&form_state, $arg = NULL,&form_state = NULL...), the now existing one came in #9 in there, without any explanation.The argument (and all other variations in that issue, in fact) seems to be just leftovers from debugging the drag-and-drop feature, and no-one probably even noticed that it's in there.
- First of all, the default value combined with passing by reference is nonsence, http://www.php.net/manual/en/functions.arguments.php#functions.arguments... says clearly that it won't work, suggesting vaguely that perhaps php5 may accept it (only). Even throws a parse-error on php4, as the initial post reported (I can't reproduce, but I'm on php5).
- Funnily, the argument is NEVER ever used inside the function. It's simply not necessary at all.
- The function profile_admin_overview() is just a form definition, called only as page argument for drupal_get_form() callback. It doesn't receive any arguments, and even if it did, these will be extra arguments supplied to drupal_get_form() - the $form_state is not passed there. (And was it ever? Can't find slightest mention since 4.7. http://api.drupal.org/api/file/developer/topics/forms_api.html/6 )
So after this analysis, I just removed the argument, as suggested in #5, and everything seems to work fine, still.
Sorry for flooding the queue with criticals, but parse error IS critical IMO, even if just php4-specific.
Comment #10
JirkaRybka commentedOh, and #6-#7 is also correct, the problem reproduces for me (it's on the user account edit - profile tab), and the fix is also correct.
I wonder why no-one rolled a patch yet, when the solutions are sitting ready here in the issue. ;)
Comment #11
JirkaRybka commentedstatus fix...
Comment #12
chx commentedYes, PHP5 does support &$foo = 'default' but PHP4 does not. This issue clearly shows the age of PHP4 -- few developers work with profile and even fewer does so with PHP4...
Comment #13
gábor hojtsyThanks, committed.
Comment #14
cavemaster1969 commentedThanks to all of you for working on this issue. We have been beating our heads for days with the Profile Module parse error. I'm new to patching so if you don't mind how to I apply the above mentioned patches? (i.e. profile-arg-weight.patch and profile-argument.patch). Thanks for the input. Maybe I'm in the wrong section for this type of assistance?
Comment #15
gábor hojtsyUpdate to the latest Drupal 6-dev from http://drupal.org/node/97368 (and please do not hijack bug reports with support requests). Please also deassign yourself from this issue.
Comment #16
(not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.