Cannot use update.php as anonymous user

subscribe.

Not just "some modules" - core needs this patch in order for update.php to complete for anon users. The code looks good, but it does not fix update.php for me ... I agree with critical here.

tagging

With this patch and #612920: {url_alias}.source required for upgrade I can get update.php to run.

I am only a newbie here, but I thought anonymous access to update.php was SUPPOSED to be denied.
It is/was possible, however, to change $update_free_access = TRUE to run update. Maybe that is the problem here.

Better comment.

This should be enough just to get update.php to run.

Yeah, that includes/session.inc stuff is a bit... eek. Yay for one-line changes, especially when they just make sense.

I committed this fix to HEAD to get the upgrade path going again. Damien, if for some reason this doesn't fix the Mollom/Ubercart/etc. problem, then go ahead and re-open, but I'd obviously love to not be changing APIs at this point in the release cycle.

Seems like we can downgrade this to Normal. If someone disagrees, please change it back and give some detail about what needs to happen.

Update fails in alpha 1. It gets through to update.php?op=info and returns a blank screen. This is using alpha 1 code with a copy of a database from d6.15. There are a variety of add on modules in the d6 version. The number of tables increased from 119 to 128. If I go from update.php to / I get a Table blocked_ips doesn't exist message.

I created the blocked_ips table as an export from another d7 install, a clean create, and the update.php page still ran to a white screen of death. The / page went to
Fatal error: Class 'SelectQueryExtender' not found in H:\home\example\public_html\includes\pager.inc on line 16

The two registry tables are empty.

tables taxonomy_vocabulary and file do not exist. Copied from d7.

Is it possible to turn on messages as a continuous stream during update.php so we can see what works and where it fails?

I manually added some tables and manually changed users.pass to 128 bytes and manually copied a password from the d7 version. the login produced:
* Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 108 of H:\home\example\public_html\includes\entity.inc).
* Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->cacheGet() (line 272 of H:\home\example\public_html\includes\entity.inc).
* Recoverable fatal error: Object of class stdClass could not be converted to string in DatabaseStatementBase->execute() (line 1940 of H:\home\example\public_html\includes\database\database.inc).

I do not know if any of this helps define where update.php failed. I think it would be easier to test the alpha versions with update.php displaying every step as it happens.

I was able to run update.php without being logged into my site, by adding the bypass variable into my settings.php, so I don't see what needs to be done here.

Hi,

I'm not able to run update on my site. I accidentally logged out after I changed the site to offline mode and then I tried to run update which stopped me with Access denied error as seen in this page: http://www.paradesi.org/update.php. As per the prompted page, I tried to apply this.

2.There is a line inside your settings.php file that says $update_free_access = FALSE;. Change it to $update_free_access = TRUE;.

But there is NO such parameter in settings.php file. I could change this in /~/sites/default/default.settings.php file instead of "/~/sites/default/settings.php". But there is no change in the result. Could someone unblock me by pointing final solution for this stopper.

tia
Paradesi

look in settings.php for $update_free_access = FALSE;

/**
* Access control for update.php script
*
* If you are updating your Drupal installation using the update.php script but
* are not logged in using either an account with the "Administer software
* updates" permission or the site maintenance account (the account that was
* created during installation), you will need to modify the access check
* statement below. Change the FALSE to a TRUE to disable the access check.
* After finishing the upgrade, be sure to open this file again and change the
* TRUE back to a FALSE!
*/
$update_free_access = FALSE;


change it to TRUE

Hi,

Like I mentioned in my previous post, I did not see that setting "$update_free_access = FALSE;" in settings.php.

But there is one more file named "default.settings.php" in which I can change "$update_free_access = TRUE;". But still I see the same result even though I relaunched the browser after clearning the cache, etc.

thanks

Add $update_free_access = true; to /~/sites/default/settings.php

@paradesi. If it's in default.settings.php, but not in settings.php, then your settings.php is out of date. You need make a backup of it, copy default.settings.php to settings.php, then move your database information in there.

hi catch,

Yes, I thought of copying default.settings.php to settings.php. Could you clarify what database information or what file that I need to move where?

thanks