Clicking on the "Select Default Widgets" link results in a Whitescreen with the following error message:

Parse error: parse error in C:\Users\David\Sites\acquia-drupal-site\acquia-drupal\sites\all\modules\dashboard\templates\dashboard-select-defaults.tpl.php on line 33

Comments

dddave’s picture

This issue is still standing after creating a clean install.

beretta627’s picture

Assigned:Unassigned» beretta627
beretta627’s picture

what version of drupal are you using?

edit: looks like some form of acquia drupal. I just did a local install of it and couldn't replicate this error. Please provide more information about your installation.

beretta627’s picture

Status:Active» Postponed (maintainer needs more info)
dddave’s picture

Status:Postponed (maintainer needs more info)» Active

D6.17
php 5.2.9-1
MySQL 5.1.34

It is a multisite install and it happens on each of my three test installs.

What more do you need?

beretta627’s picture

I need to know why this isn't working for you. :)

Did you try doing a base install of just drupal, dashboard + dependent modules? trying to narrow down the problem.

smthomas’s picture

I am getting this same error after a complete uninstall and dev re-install with Drupal 6.17, php 5.3.2-1, mysql 5.1.41.

i have tried this with Garland and Blue Marine.

reaneyk’s picture

Oops, I created a duplicate for this one: #889242: PHP short tag in dashboard-select-defaults.tpl.php . This has to do with the PHP short tag in the code. On line 30 switch the <? endforeach; ?> to

<?php
 
endforeach;
?>
smthomas’s picture

As a follow up I get this error when working on a website with Drupal 6.19, php 5.3, mysql 5.1, and nginx web server. However, this error does not appear (and everything works correctly) using Drupal 6.19, php 5.2, mysql 5.1, and apache web server. I have not determined the exact root cause but I am looking into it.

smthomas’s picture

I can also confirm that the fix in #8 above works.

nikosnikos’s picture

Fix in #8 solved the problem for me too.
Thanks.

vensires’s picture

Status:Active» Closed (fixed)

Fix in #8 solved the problem

dddave’s picture

Status:Closed (fixed)» Active

Correcting status.

This issue is active until code is committed or a patch attached which can be reviewed. Closing the issue doesn't help.

igorik’s picture

is there any maintainer of this module? if solution #8 works, it could be commited.

vensires’s picture

I don't know anything about the maintainer but the solution in #8 works like a charm.

Eranga’s picture

Thankz reaneyk. It fixed this issue.. But we can do the following change to fix all this kind of issues. Some people use Short Open tags for cording.. So we can't always find where the short open tags are and make it correct as above. We can simple do the following change.. It will fix this whatever the open tags are....
1. Go to C:\xampp\php
2.Open the php.ini file
3.Find for short_open_tag
4.If it is like -> short_open_tag = Off
Change it to -> short_open_tag = On
5.Restart apache.

hope this will help you guys...

vensires’s picture

You are right this is a solution, but definitely not the best one out there. I paste here part of the php.ini file.

This directive determines whether or not PHP will recognize code between <? and ?> tags as PHP source which should be processed as such. It's been recommended for several years that you not use the short tag "short cut" and instead to use the full <?php and ?> tag combination. With the wide spread use of XML and use of these tags by other languages, the server can become easily confused and end up parsing the wrong code in the wrong context. But because this short cut has been a feature for such a long time, it's currently still supported for backwards compatibility, but we recommend you don't use them.
Default Value: On
Development Value: Off
Production Value: Off
http://php.net/short-open-tag

So yes, short_open_tag could have the On value, but this isn't something that drupal developers (and php developers in general) should do. Writing <?=$foo?> is smaller and maybe simpler than <?php echo $foo; ?> but! Check here for more information.

ebeyrent’s picture

You shouldn't need to mess with your php.ini file. Comment #8 is the solution, and the maintainer of this module should fix the code. It's clearly a mistake.