Installation without shell access?
I have created a prototype web site using Drupal 6.2 (my first), and now I need to install it on a server at my client's host. This is proving more difficult than I hoped.
The process, as I understand it, is:
1. Create the database on the host (already done for me).
2. Unpack and upload the Drupal distribution (done).
3. Ensure that sites/default and files are writable by the web server process.
4. Run install.php.
5. Drop all tables from the database.
6. Export all tables from my local database and import them to the host.
7. Upload the contents of my theme directory and the files directory.
Step 3 is the sticking point. The Web server process apparently does not have write access to sites/default, and there's nothing I can do about it, because the host does not grant shell access to customers, for security reasons. I will have to ask them to do it for me, and they will probably take a couple of days to respond.
So I'm wondering: can I perform the install to a new directory on my own machine -- using the database on the host, without disturbing my development environment -- and then upload it?
If not, is the installer liable to give me any more little surprises once I resolve this problem? If so, I really need to know now. Each request I make is likely to take another couple of days, and I suspect that the more requests I make, the longer they will take.
=-=
Step 3 has nothing specific to do with shell access, you can CHMOD aka set permissions using your host panel in some cases and an FTP tool in most cases.
insure that before you export your DB from dev, you drop all watchdog entiries and all cache entires.
also not that you will have to adjust $db_url in settings.php to point to new DB
chances are that the host will not allow you to remote connect to the hosts DB machine from your own. Typically you can only connect from within their environment.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
Yup, that worked
Yup, that worked. I thought it was impossible because the FTP program' s menu system says nothing about "permissions." I looked again and found that it calls them "properties." Once I realized that, no problem. Thanks for making me revisit it.
A Drupal bug?
The install is going well, but I encountered an oddity. I'm not sure whether this should be considered a bug or my misunderstanding. If a bug, I want to report it.
When I finished running the install, Drupal emailed me a message inviting me to click a link and change my password. This message was addressed (by name) to my administrative account, which made perfect sense to me.
However, by the time I received this message I had already dropped the tables in the installed database and imported the tables from my development database. These included definitions for several accounts with different roles.
When I clicked the link, I discovered that I was changing the password for the least privileged account (probably the last one I defined).
I'm guessing that whoever wrote this part of Drupal did not allow for the case of installing an existing site on a new host, or assumed that anyone who did so would respond to the email before replacing the database tables. Consequently the code assumes that when the user visits the link in the initial email, only one account is defined, and it does not check for the right one.
=-=
It's not a bug.
Ultimatley there is no reason to "install" drupal again just to drop the tables. You could have just did an entire import and altered settings.php to point to the new DB after importing the dev DB.
Then if you need to change UID to your client, you could have altered this in the users table manually of with some SQL
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
I tried that --
I tried that first. It did not work. When I tried to use Drupal, it told me that I did not have access to the database. Then I entered exactly the same database parameters when I did the install, and it worked.
I concluded that Drupal was doing more with the database parameters than just storing them in settings.php. Perhaps the problem was something else -- it's too late for me to investigate -- but I had to do it this way to get a functioning system.
=-=
The only place Drupal stores your DB connection string is in settings.php
perhaps on one of the two system php5 is being used and the mysqli was/wasn't altered as it should have been.
conmpare the new settings.php to the one in your dev environment. Specifially the $db_url string.
I've deployed dozens of sites from dev to production and never had to run the install first soley to drop the tables.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
Too late --
As I said, it's too late to do anything about this now because the installation is working. I'll have another try the next time I have to upload a new installation, and I hope I'll get more insight.
I don't think I made a mistake with the connection string, but I can't rule it out -- I've done dumber things than that in my career.
Shell access not needed
Although I do like having shell access (I run my own server, so my experience with hosts is limited).
FTP/SFTP/SCP etc clients let you change permissions. I've heard at least some hosts also provide a web interface for managing files and permissions etc. That shouldn't be a problem.
I doubt you'll be able to access their DB server from outside their own network. I imagine MySQL would be firewalled off from the internet.
Creating Drupal databases without the installer was pretty easy to do with older versions that had no installer and came with a separate SQL script to initialise the DB and you edited settings.php yourself (I kinda preferred it that way - even if newbies hated it). Basically the installer just changes a couple of settings in settings.php and creates the DB tables and some initial values.
You should be able to run the installer locally and then dump the database and restore it on the host and copy up the new settings.php file.
If the host goes out of their way to make these things difficult to do, I would try to convince the client to look for a more accommodating host. After all access to these kind of things can be important for disaster recovery etc too.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal