Hardcoded path to /usr/share/drupal6

Hi all,

When I test creating a new symlink to the "webroot", to point to another folder further inside the subfolders under the drupal6 folder, by renaming the original webroot and creating a new one, then even after that there are errors saying that there are no valid Drupal installation on /usr/share/drupal6...

This tells me that there must be a hardcoded setting somewhere that is not pointing to the webroot folder (the symlink), but to the actualy default folder. Where is that setting?

I try to work around the following problem:

When I install drush, and try to use it from/in other drupal installations in subfolders (even 3 levels deeper) under /usr/share/drupal6/othersites/site2 ... etc. , then the drush environment only deals with the drupal site at /usr/share/drupal6, and not with the one from where I issue the drush command. Therefore I figured I could use some scripts to switch around several symlinks instead, but then I need to get to the bottom of the issue with the hardcode path.

Replies (3)

I think the symlink is just there to point you to webroot

Reply 1 2011-10-24

So that users who are expecting to find the webroot at /var/www/drupal don't go WTF!?! I'd check the apache2 config (sites-enabled?). Although I'm only guessing...

Yes, it is hardcoded in the Virtualhosts sections of apache.conf

Reply 2 2011-10-24

Thanks for the pointer - found it in /etc/drupal/6/apache.conf :

Virtualhosts points to that hardcoded folder for both port 80 and 443/ssl.

I will try to set them to point to symlinks instead, so I can alter easily what is the "current" webroot via aliases and scripts, until the underlying problem has a solution. So the symlink is one side of this, the other main issue is how to get drush to run happily with multiple hosts, preferably in subdirectories of the "current" path.

I reckon that among the most important reasons to use virtualisation is indeed to be able to test many things conveniently. This suggests that it is important for many people to be able to administer multiple sites conveniently also in TurnKeyDrupal, IMO. However, this is not necessarily a TKDrupal issue, though (even if it would not hurt if we could work around the main problem here (too); There are several reported issues that seems related to this, discussions are ongoing:

"Command pm-enable needs a higher bootstrap level to run"
http://drupal.org/node/1016268

"Drush Bootstrap Problem Using Localhost in Settings.php file"
http://drupal.org/node/703454

"Cannot Use drush pm-enable on current site"
http://drupal.org/node/757386

Hm, one step further, but which copy of htaccess is in effect?

Reply 3 2011-10-25

The .htaccess file in the drupal6 root folder is a symlink, and ends up pointing to:

/etc/drupal/6/htaccess

After adding these lines: (the latter 2 lines is irrelevant for this issue, but including them here anyway in case someone finds it useful)

php_value memory_limit 128M
php_value php_value post_max_size 30M
php_value upload_max_filesize 20M

I get this error when trying to run drush:

"Allowed memory size of 33554432 bytes exhausted"

- which may be an indication that there is another memory setting or htaccess file somewhere? (that number represents the default 32MB limit and is surely from a default setting somewhere)

I do not mean in the settings.php file, which did NOT have any such setting until now, must be somewhere else. However, when I now actually ADD the following line in just that sites/default/settings.php file in Drupal:

ini_set('memory_limit', '96M');

- then drush works... (seemingly, havent tested thoroughly yet)

(in case someone wonders why I use 128M one place and 96M another, that is just to be able to tell them apart, to see which source takes effect)

Now I will continue to test if it works alltogether, and how I can adapt this to my needs.

My initial impression is that IF all this dealing with symlinks (both files, profiles and sites are symlinks) is to make it possible with multisite setups, then it seems like a strange approach, or at least one that simply leaves too much manual work just for this purpose. If it is NOT done with multisite in mind, then I fail to see why this setup is done with symlinks at all.