Dear All,

I tried to update Drupal to 6.28 version but wasn't able to upload all the files. My webhoster found out that my internet connection speed was much slower than theirs and therefore the connection was repeatedly broken which prevented me to upload all the files. The webhoster said that the only way, is for him to upload the files for me and so he did. When I went on my website, I got the following message:

Drupal already installed
To start over, you must empty your existing database.
To install to a different database, edit the appropriate settings.php file in the sites folder.
To upgrade an existing installation, proceed to the update script.
View your existing site.

What did actually went wrong and how can I fix this?
I have no knowledge of Drupal and would appreciate it if anyone can guide me through the solution.

Many thanks in advance.

Comments

Assuming you started and finished with D6 (and did not try a major version upgrade), the first thing I would do is check you have a default.settings.php and a settings.php (you need both). Unless you have multisite installation it is at sites/default. And look at the .htaccess file in document root (often public_html, anyway the folder where all the Drupal code lives) and make sure it exists and is a Drupal one. There permissions on the files in sites/default or the folder itself may be wrong. I have seen this many times, it is usually something simple. There are several threads on it, including a long thread here https://drupal.org/node/127843 much of which is misleading or confusing but it contains some good suggestions.

Another solution is this. Roll back to your backup before you run the update. Get command line access to your server and install Drush. Then every update will take you 20 seconds: just issue command 'drush up'

If the site is mission critical always run updates on a development copy of the site first. If it is not mission critical, at least back up the site before you start.

Thank you very much for your reply.

I have both files and also settings.php.bak in /sites/default
.htaccess I have in /httpdocs (I believe this is the root document)

Could it be that settings.php.bak. is causing the problem? Do I have to delete it?

Hello

In case the settings.php file has been changed or somehow overwritten (even though it should not), check the file and see if it is configured to connect to the correct database. If not, you may want to restore your previous copy of the settings.php file.

If the above does not work as well or if the upgrade process did not complete successfully, the best option would be to restore the site to the state it was before you initiated the upgrade. You can do that by replacing the files with the backup files ( I assume you have created backup copy of your site files and database). The second step is to create new database and import the backup copy in it. You can do this using a database management tool like phpMyAdmin. Once you have imported the database, enter the new database details in the settings.php file. You may want to ask your host for assistance on that matter.

I hope this helps you restore the functionality of your website.

www.tmdhosting.com
---------------------
Drupal Hosting, Free Drupal Installations, Free Module and Theme Installations, Free Upgrades, Free Drupal

The problem is that you have a 'clean' (ie - uninstalled) settings.php file, but an installed Drupal site on the server. Because your settings.php is new, the system starts the installation process, but then it finds that there is already a Drupal installation in the database. When the host uploaded your files, they probably got an error for settings.php, as the permissions on it don't allow for it to be deleted/overwritten. So they renamed it to settings.php.bak, and then put the 'clean' settings.php file there instead.

I'd rename your current settings.php to something else (JIC), then rename settings.php.bak to settings.php. Refresh your browser.

When all this is done, make sure to set the settings.php permissions to 444 (r--r--r--).

Jaypan
Our newest Drupal site: PacificAikido.com (Drupal showcase)

I tried to rename the files as you suggested but I noticed that the settings.php.bak is a BAK file and not a PHP file like the settings.php file. The permission on settings.php is already on 444 but on settings.php.bak it is set on 644. I tried renaming the files in Filezilla but it didn't work. I want to try renaming the files on the site of the webhoster but wanted to know first if the BAK file is o.k.

First rename settings.php to something else. Then rename settings.php.bak to settings.php. See if the site works after that.

www.tmdhosting.com
---------------------
Drupal Hosting, Free Drupal Installations, Free Module and Theme Installations, Free Upgrades, Free Drupal

I tried to rename the files but are not able to. I get the error "operation not permitted". I have contacted the webhoster and asked him if he had renamed the file. If so, I'll asked him to rename them again. As soon as I get an answer from him, I'll post again.

Many thanks for the help so far.

It may have been an automated process.

.bak file is just an old way of saying .backup.

You will need to change the file permissions of settings.php before you can edit it.

Jaypan
Our newest Drupal site: PacificAikido.com (Drupal showcase)

It may have been an automated process.

.bak file is just an old way of saying .backup.

You will need to change the file permissions of settings.php before you can edit it.

Jaypan
Our newest Drupal site: PacificAikido.com (Drupal showcase)

I think you're right Jaypan. I received a reply from the webhoster and he said that he didn't see any error message and haven't renamed any file. I have my original website on a disk but do not have a recent backup. What can I do to solve this problem?

can someone help me, please?

I am not able to rename settings.php. I have changed the permissions to 777 but nevertheless, I still cannot rename or remove the file. I have noticed that there is a new .htaccess file in the /httpdocs folder but there is also an older .htaccess file in the /webspace folder. I have checked the files on my original website CD (not much has changed since then, except for a Drupal update) and have noticed that there is no .htaccess in the /httpdocs folder. Do I have to remove the new .htaccess file from /httpdocs folder?

I would appreciate a step by step guidance since I have no knowledge of Drupal or html at all.

Many thanks in advance.

Normally if you cannot remove the file, your attempt to change it 777 would fail. Did your attempt to change it succeed?

IIt is likely that you have lost ownership of the file (and your change to 777 may have failed). You need to contact the server administrator to check and correct the ownership.

If you are logged in from command line you can check the ownership yourself. Control panel file managers do not always give this information.

Bottom line: you need to get back to the server administrator to sort this out.

I did change the permission to 777. From the webhoster's control panel, I can see that the permission is set on 777. Also in Filezilla, I see the permission set on 777 but I still cannot rename or remove it. I will contact the webhoster about it and see if he can sort it out.

The webhoster made it possible for me to rename settings.php and replace it with settings.php.bak but when I go on my website, I get the following error:

Forbidden
You don't have permission to access / on this server.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.
Apache/2.0.52 (Red Hat) PHP/4.4.9 FrontPage/5.0.2.2635 Server at www.fashion-consultancy.eu Port 80

I contacted the webhoster about this and he recommended me to replace my Drupal files with the old ones. Do I have to replace settings.php and default.settings.php as well?

You should use the settings.php file that is configured to connect to the MySQL database.

As for the 403 error check the following:

- files are owned by the correct user. You may need to ask your host to check this for you
- files and folders permissions. You should use 644 for files and 755 for folders
- check if there is a "Deny from all" rule in the .htaccess. If such is present, remove it.

www.tmdhosting.com
---------------------
Drupal Hosting, Free Drupal Installations, Free Module and Theme Installations, Free Upgrades, Free Drupal

Just to underline what TMDHosting said, in case you spend time replacing files, the chances you need to replace the files are very low. And if the directory ownership is wrong it might not help. Sort out the ownership and permissions properly and possibly check .htaccess and your site will probably work.

I have checked the .htaccess file but there is no "deny from all" rule. I have also seen that the settings.php file has not been replaced in the first place but the default.settings.php might have been replaced. Could the install.php file be the problem if it has been replaced by the new version?

Normally where you are seeing a 403 it is not an error in Drupal code but a permissions problem on the server. One thing I try sometimes is putting an index.html in the document root (httpdocs or public_html or whatever) with Hello World. Then visit your domain with /index.html after it. If that does not work you know there is a problem with the web server much more simple and basic than a problem at the Drupal level because it means your server is not able to serve any website.

Thank you all for your help so far. The webhoster has rolled back the update and I was able to update Drupal. Now I am confronted with to following problem:

I run Cron and got the following message ":TCPDF Library requirements The Webform2PDF module requires you to set the TCPDF library directory." I click on "set the TCPDF library directory." and get the following warnings:

1. warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'theme_webform_token_help' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/theme.inc on line 669.
2. warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'theme_webform_token_help' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/theme.inc on line 669.
3. warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'theme_webform_token_help' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/theme.inc on line 669.

Why do I get these warnings and what do I have to do to solve this?

Many thanks in advance for your help.

You / your Webmaster have not accepted the advise above https://drupal.org/node/2114949#comment-7993021 which was that rolling back the code change was probably not the right solution.

If your Webmaster rolled back the code changes without rolling back the database update, he may have made things worse. Ensure that he rolls back the database to the state it was before the code updates were done, so that the versions of code and the versions in the database match. Once you have done that you will have successfully rolled back to your old, working site.

If you still have the problem after completing the rollback correctly, it may be from some other cause so please post again.

Please, help me get a clearer picture..

When the webhoster rolled back the update, my website was working fine. If the database has to be rolled back as well, shouldn't I have had warnings right away on my website?

After the rollback, I updated the website to Drupal 6.28 without a problem. I added the webform2pdf folder to /sites/all/modules and this is when I got the above warnings. I added the tcpdf folder to /sites/all/library but the warnings remained. I have checked the uploaded tcpdf folder and seen that not all the files in the folder were uploaded. I have tried to upload the missing files but were not able to because somehow the connection is repeatedly disconnected. Couldn't this be the reason for the warnings?

Yes that is probably the reason for the warnings.

We can leave aside the issue of database updates for now, though it is something to be aware of. Some updates involve changes to the database as well as to code, and where this is true, the version of code often cannot simply be downgraded without rolling back to an earlier copy of the database too.

If you have shell (command line) access to your hosting, you can quickly overcome your upload connection problems by taking code directly from drupal.org onto the server using relevant commands. I am not sure if the availability of module downloads in this way will be affected by drupal.org's scheduled downtime tomorrow.

I just received an email from my webhoster confirming that I do not have shell. I have tried uploading the files one by one also without any success. Is there anything else I can try to get the files uploaded?

I have managed to finally get all the files uploaded but now I am getting the following message when I click on "administer":

Status: 500 Internal Server Error X-Powered-By: PHP/5.3.3 Expires: Sun, 19 Nov 1978 05:00:00 GMT Last-Modified: Tue, 05 Nov 2013 05:40:57 GMT Cache-Control: store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Content-Type: text/html; charset=utf-8.

Does this has to do with the database problem you mentioned before?

Probably not. It could be some wrong permissions. If it only happens on admin pages I would suspect some faulty or missing code. Looking at the latest entries in the server error log shortly after trying to visit that page will probably reveal the problem, or at least pointers to help find the problem.

I have checked the server log and found the following:

[Tue Nov 05 06:40:20 2013] [error] [client 84.163.164.235] (13)Permission denied: file permissions deny server access: /usr/local/pem/vhosts/104997/webspace/error_docs/404.html
[Tue Nov 05 06:40:57 2013] [error] [client 84.163.164.235] PHP Fatal error: Call to undefined method TCPDF::getTCPDFVersion() in /usr/local/pem/vhosts/104997/webspace/httpdocs/sites/all/modules/webform2pdf/webform2pdf.install on line 320, referer: http://www.fashion-consultancy.eu/?q=users/manager

What does this mean?

The first problem points to a permissions issue which the person running the server should fix.

The second error message points to the fact the webdform2pdf module does not support the latest version of the library. See here https://drupal.org/node/2029527 and https://drupal.org/node/2029527 on the Drupal 7 equivalent of the problem.

I have done the patch and the 3rd error message doesn't appear anymore in the logfiles but I still have the 1st two error messages and a new one:

[Thu Nov 07 15:32:05 2013] [error] [client 5.9.108.235] File does not exist: /usr/local/pem/vhosts/104997/webspace/httpdocs/"javascript:window.close()

Does this message has to do with the patch not being done correctly?

I have contacted the webhoster about the permission problem but he says, he doesn't have a clue what's wrong. In the logfile I found following message:

[Fri Nov 08 08:09:40 2013] [error] [client 84.163.163.64] File does not exist: /usr/local/pem/vhosts/104997/webspace/httpdocs/favicon.ico

Is this the missing file causing the problem? I have checked every single file manually to see if I have missed uploading a file but everything is uploaded except for this favicon.ico.file that I couldn't find anywhere in the update files.

1. Probably not. You can try debugging javascript files using console in Firebug or any other modern browser. There seems to be faulty code.
2. missing favicon message is normal and harmless.

I tried Firebug but have no clue how to find an error. So I tried the W3C validator and it gave these two errors:

URI : http://www.fashion-consultancy.eu/sites/all/themes/fusion/fusion_core/cs...
1374 div.view div.views-admin-links ul.links li a:link, div.view div.views-admin-links ul.links li a:visited Parse Error opacity=75)
URI : http://www.fashion-consultancy.eu/sites/all/themes/jc_theme/css/jc-theme...
168 #block-block-19 Value Error : margin-top px is not a margin-top value : px

What do they mean and how do I fix it?

These errors in CSS are totally irrelevant and at worst will cause minor errors in styling.

If you open the page with Firebug and with Console tab clicked, and reload the page, if you see no error messages there is nothing to worry to about.

I have slightly lost track here. Can you say what immediate problem you are facing with the website at this stage?

The problem I am facing right now is the error message I get when I go to my website:

Status: 500 Internal Server Error X-Powered-By: PHP/5.3.3 Expires: Sun, 19 Nov 1978 05:00:00 GMT Last-Modified: Sun, 10 Nov 2013 15:35:45 GMT Cache-Control: store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Content-Type: text/html; charset=utf-8

I get the above message when I click on "administer".
I also have a permission problem that the webhoster doesn't know how to solve it.

With Firebug I got a list of errors:
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'webform_menu_load' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/menu.inc on line 409.
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'webform_menu_component_load' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/menu.inc on line 409.
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'webform_menu_load' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/menu.inc on line 409.
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'webform_menu_component_load' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/menu.inc on line 409.
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'webform_menu_load' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/menu.inc on line 409.
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'webform_menu_component_load' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/menu.inc on line 409.
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'webform_menu_load' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/menu.inc on line 409.
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'webform_menu_component_load' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/menu.inc on line 409.
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'webform_menu_load' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/menu.inc on line 409.
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'webform_menu_component_load' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/menu.inc on line 409.
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'webform_menu_load' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/menu.inc on line 409.
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'webform_menu_component_load' not found or invalid function name in /usr/local/pem/vhosts/104997/webspace/httpdocs/includes/menu.inc on line 409.

What does all these warnings mean?

The second lot of errors probably mean that the file webform.module (if not the entire Webform module) is missing. It is just possible it is present but corrupted, or you are using a very old version of Webform.

I would fix that first, and if there is still a 500 error, return to that afterwards.

I have noticed that I get the first error (status...) now when I enter the url of my website. Also I am not able to login because the password has been changed. Could it be that my database is hacked and the second list of errors is due to changes made to the database?

I did change the permission to 777.I I see the permission set on 777 but I still cannot rename or remove it. I will contact the webhoster about it and see if he can sort it out.

The permission here is for the settings.php file. It has nothing to do with changing my password does it?

I was able to access the Admin menu through mysite.com/admin/appearance and I noticed that I am able to access all menus except for the "reports/status report", "content management/webforms" and "site configuration/webform settings". When I click on these, I get the same error:

Status: 500 Internal Server Error X-Powered-By: PHP/5.3.3 Expires: Sun, 19 Nov 1978 05:00:00 GMT Last-Modified: Thu, 14 Nov 2013 09:09:42 GMT Cache-Control: store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Content-Type: text/html; charset=utf-8

I was able to run cron manually and it is completely up to date without any error messages.
I updated the webform folder and the list of errors at the login page disappeared.
I also noticed that a similar list of errors appears once in a while but disappears when I refresh the browser. I got this list of errors when I clicked on the menu's "users" and "reports" but once I refreshed the brower, I didn't get it again.

Does anyone have an idea what the problem could be?

I don't know but will give a tip from experience. When I have seen odd behaviour which diseappears on page reload or cache clear, then comes back for no apparent reason, sometimes it has been because I or someone had left a second renamed copying of a module lying around in a the modules folder (perhaps for backup reasons). Maybe not your issue but worth keeping an eye out for.

Thank you for your reply John_B.

I have checked the module folder but couldn't find anything. I have never cleared the cache. How do I do this?
I also found 3 files of .htaccess. One in /webspace, one in /httpdocs and one in /sites/default. Is this correct?

Clearing caches is basic stuff for which you turn to the documentation or Google https://drupal.org/node/42055, the Drupal basics cannot practically be covered in the context of a forum conversation.

I do not know what connection your /webspace has with your site. In your main document root (probably /httpdocs) there should be one .htaccess which looks like the one which comes with a Drupal download. Not sure about in sites/default, it seems odd. It is normal for there to be a .htaccess in the folder you have chosen for the private file system (again something you would have set up when you built the site, just refer to documentation, or whichever books or video courses you used when you were studying Drupal basics).