I guess folks have been using Vagrant Drupal Development for a few years now to get a good local dev version of a Drupal install going.
Had initially installed locally using MAMP, and I think it had been working, but can’t totally remember. At any rate, after pulling in some of the changes from the git repo
, was getting an Apache error:
[Wed Jul 22 13:25:09 2015] [error] [client 127.0.0.1] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
An opportunity to play with Vagrant.
Following this VDD tutorial, and with my previous (limited) Vagrant/VirtualBox experience…
Since we’re using Drupal 7 (it was installed over a year ago), obviously I updated the following lines substituting 7 for 8:
git clone --branch 8.0.x http://git.drupal.org/project/drupal.git .
drush @drupal8 si standard -y
(Man, drupal is large!).
Pretty sweet drush (the Drupal command line library) is automatically installed.
Hey!
Your PHP installation is too old. Drupal requires at least PHP 5.5.9. See the system requirements page for more information.
Apparently /etc/apache2/mods-enabled/php5.load
tells which version of php Apache will load (as long as the version is installed), but all it contains is LoadModule php5_module /usr/lib/apache2/modules/libphp5.so
, which doesn’t do much for the point five point nine part.
php --version
PHP 5.4.4
Hmmm. Wait a minute. That’s the same version running on the host machine. Coincidence? Yes. The whole point of running a virtual machine is that it can match a different environment. (But I still had to confirm this by loading another vagrant box, which fortunately was not running the same php version.)
The tutorial’s a couple of years old and the latest “stable” VDD release is over a year old, which may be previous to the upgraded php requirement for Drupal so now I’m running the more recent (dev) release of VDD…
Looks like it runs the same Ubuntu box disc image, which Jamaaladeen (this computer) appreciates, memory-wise.
This time I was prompted for a password as it was installing. Failed three times trying ‘root’, ‘root’ and ‘vagrant’ then got a message ‘sudo: 3 incorrect password attempts’, so maybe I should have entered the sudo passwd for Jamaaladeen.
Great! Same php version in the new one.
As it turns out, Drupal 7 doesn’t require php 5.5.9 (no surprise there!). Maybe that wasn’t the correct git clone command above. Installed a new VDD box with most recent (dev) version of VDD.
Installed Drupal differently this time:
git clone http://git.drupal.org/project/drupal.git .
git checkout 7.0
New problems. When running drush @drupal7 si standard -y
:
WD php: Warning: Illegal string offset 'field' in DatabaseCondition->__clone() (line 1818 of
/var/www/drupal7/includes/database/query.inc). [warning]
Apparently a bug that was addressed in Drupal 7.14
. So:
git checkout 7.14
Finally a clean Drupal install on the new box.
Will probably stick with the newer dev version of VDD and run vagrant destroy
from the directory of the older one, but let’s wait a minute just in case.
Next step is to get our own Drupal install going in the VirtualBox.
First checked in the live site under Admin->reports->Status Report and we are running Drupal 7.38. Looks like running drush up
from the Drupal directory on the VBox might just do the trick to get from 7.14 to 7.38.
Looks like it worked!
Browser address:
http://drupal7.dev
Let’s get our code in here:
git remote rename origin drupal
git add remote origin git@bitbucket.org/etc
git checkout -b cleanDrupal7
git checkout -b master
git pull remote
> Permission denied (publickey).
> fatal: The remote end hung up unexpectedly
Right.
ssh-keygen -t rsa -b 4096 -C "mike@mzoo.org" #no password
eval "$(ssh-agent -s)"
> Identity added: /home/vagrant/.ssh/id_rsa (/home/vagrant/.ssh/id_rsa)
cat ~/.ssh/id_rsa.pub
Add it to the repository. Now we can git pull origin
.
You asked to pull from the remote 'origin', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.
git pull origin dev
> error: Your local changes to the following files would be overwritten by merge:
.htaccess
etc...
So…
git fetch --all
git reset --hard origin/dev #made a dev version first with git checkout -b dev
Now to import the MySQL database dump from the server. First let’s backup the clean install version.
mysqldump -u root -p root drupal7 > drupal7_clean.sql
> mysqldump: Got error: 1045: Access denied for user 'root'@'localhost' (using password: YES) when trying to connect
Really? So!
mysqld --skip-grant-tables
This generated some errors and a warning and even said it was aborting, but ended with shutdown complete
.
$ mysql -u root mysql
$mysql> UPDATE user SET Password=PASSWORD('my_password') where USER='root';
$mysql> FLUSH PRIVILEGES;
$exit
/etc/init.d/mysql restart
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service mysql restart
Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the stop(8) and then start(8) utilities,
e.g. stop mysql ; start mysql. The restart(8) utility is also available
service mysql restart
mysqldump -u root -p root drupal7 > drupal7_clean.sql
Enter password: #(root)
mysqldump: Got error: 1049: Unknown database 'root' when selecting the database
Hmmm.
mysqldump -u root drupal7 > drupal7_clean.sql
$ ls | grep drupal7_clean
drupal7_clean.sql
Yay.
So we’ll drop the original database
mysql
$mysql> drop database drupal7;
$mysql> create database drupal7;
$mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES ON drupal7.* TO 'root'@'localhost' IDENTIFIED BY 'password';
$mysql> exit
Now the VDD
setup created two symlinced directories between the VBox and the host machine so I can just grab the live_server.sql
file we exported yesterday and put it in the data/drupal7
directory on the host machine and there it is in the VBox (~/sites/drupal7
) as well.
Fingers crossed…
mysql -u root -p root drupal7 < ltv_live_server.mysql
mysql Ver 14.14 Distrib 5.5.44, for debian-linux-gnu (i686) using readline 6.2
Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
noise noise noise
$ mysql
> ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
Again!?!? Wait! Look above – accidentally changed the password the password. Ha.
mysql -u root -p
password: #(password)
$mysql>
Run above command with new password.
$mysql> use drupal7
$mysql> show tables;
>Empty set (0.00 sec)
Not there yet. Maybe what I downloaded wasn’t a sql dump? Open it up. Sure looks like it was.
Maybe having the -p root
isn’t necessary here.
$ mysql -u root drupal7 < ltv_live_server.mysql
Took a second or two. Good.
$ mysql
$mysql> use drupal7
$mysql> show tables;
+--------------------------------------------------------+
| Tables_in_drupal7 |
+--------------------------------------------------------+
| actions # plus dozens more...
Success. Finally!
Refresh browser window and…
Fatal error: Call to undefined function ctools_include() in /var/www/drupal7/sites/all/modules/context/context.module on line 487
Ah. Wait. We don’t have our profiles
directory in the repository.
$ rsync -azP ltv:dev3/profiles/ profiles/ # lowercase p doesn't give progress
Yes. Copying the Profiles directory solved that error. Now we need the files directory.
$ cd sites/default
$ rsync -azP ltv:dev3/sites/default/files files/
Something still amis:
( ! ) Fatal error: Unsupported operand types in /var/www/drupal7/profiles/commerce_kickstart/modules/contrib/entity/includes/entity.property.inc on line 113
Call Stack
# Time Memory Function Location
1 0.0001 128316 {main}( ) .../index.php:0
2 1.3996 7361560 menu_execute_active_handler( ) .../index.php:21
3 2.1486 9634848 drupal_deliver_page( ) .../menu.inc:534
4 2.1575 9644668 drupal_deliver_html_page( ) .../common.inc:2605
5 2.1575 9645216 drupal_page_footer( ) .../common.inc:2727
6 2.1707 9855448 system_run_automated_cron( ) .../common.inc:2754
7 2.1707 9855508 drupal_cron_run( ) .../system.module:3518
8 2.5012 10503484 module_invoke( ) .../common.inc:5351
9 2.5012 10503688 call_user_func_array:{/var/www/drupal7/includes/module.inc:866} ( ) .../module.inc:866
10 2.5012 10503780 commerce_recurring_cron( ) .../module.inc:866
11 2.5012 10503824 rules_invoke_all( ) .../commerce_recurring.module:587
12 2.5069 10504200 rules_invoke_event_by_args( ) .../rules.module:1000
13 2.5135 10750804 RulesEventSet->executeByArgs( ) .../rules.module:1056
14 2.5385 11985940 RulesActionContainer->evaluate( ) .../rules.plugins.inc:748
15 2.5385 11985964 RulesReactionRule->evaluate( ) .../rules.core.inc:2436
16 2.5385 11986296 Rule->evaluate( ) .../rules.plugins.inc:421
17 2.5447 12063780 RulesActionContainer->evaluate( ) .../rules.plugins.inc:216
18 2.5447 12063804 RulesAbstractPlugin->evaluate( ) .../rules.core.inc:2436
19 2.5533 12088884 RulesAction->executeCallback( ) .../rules.core.inc:1660
20 2.5533 12090228 RulesExtendable->__call( ) .../rules.plugins.inc:20
21 2.5533 12090228 FacesExtendable->__call( ) .../rules.core.inc:362
22 2.5533 12090584 call_user_func_array:{/var/www/drupal7/profiles/commerce_kickstart/modules/contrib/rules/includes/faces.inc:123} ( ) .../faces.inc:123
23 2.5533 12091128 rules_action_entity_query( ) .../faces.inc:123
24 2.5533 12091144 entity_property_query( ) .../entity.eval.inc:55
The commerce pages also all seem to have errors and won’t load.
You can view reports in the admin panel under Reports->Recent Log Messages
.
What’s my password? And the password reset’s not working yet. Create a new admin with Drush? Lemme just reset the password drush upwd mikek --password="newpassword"
.
Notice: Undefined index: status in entity_property_query() (line 113 of /var/www/drupal7/profiles/commerce_kickstart/modules/contrib/entity/includes/entity.property.inc).
Ah! The file permissions on the main config file for the site (sites/default/settings.php
) were set to 444
instead of 644
.
Now on to Unknown data property commerce_product. in EntityStructureWrapper->getPropertyInfo()
. Drupal forums? What are line items, and how do I find them? Ah. “product line item”s. Apparently this is what the Drupal folks are referring to as entity errors. Seems it is likely a database issue and comment #24 on the aformentioned tread proposes a possible solution. “The product reference field, that is installed on the product line item was deactivated (active = 0). The field itself was also locked, so I’m not sure how this happened. By changing the value of active to 1 and clearing cache the error disappeared.”
SELECT * FROM field_config;
mysql> describe field_config;
+----------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
OK.
mysql> SELECT field_name, active, locked FROM field_config WHERE locked=1;
commerce_line_items
is one of the returned items. Hey! “Line items”.
mysql> SELECT * FROM field_config where field_name="commerce_line_items";
mysql> UPDATE field_config SET locked = 0 WHERE field_name="commerce_line_items";
No no no no no. Hmmm. “Failures are easy to recreate if you try to enable a lot of modules at one time, especially if you have the default 30 second PHP max_execution_time.”
Let’s try disabling all the modules with Drush.
drush pml --no-core --type=module --status=enabled --pipe | xargs drush -y dis
#output output output...
>Drush command terminated abnormally due to an unrecoverable error. [error]
>Error: Unsupported operand types in /var/www/drupal7/profiles/commerce_kickstart/modules/contrib/entity/includes/entity.property.inc, line 113
Hmmm. Back to this error on front end:
( ! ) Fatal error: Call to undefined function page_manager_get_task() in /var/www/drupal7/profiles/commerce_kickstart/modules/contrib/ctools/page_manager/plugins/tasks/page.inc on line 266
Let’s try this one. The ack
version didn’t work.
drush pm-list --status=enabled --pipe | grep 'uc_' | xargs -i drush pm-disable '{}' -y
Same error. And on back end:
( ! ) Fatal error: Call to undefined function message_type_access() in /var/www/drupal7/profiles/commerce_kickstart/modules/contrib/entity/entity.module on line 657
Arrgh! Let’s clear the slate.
- repeat steps from above, delete the
drupal7
database and reinstall it from the .sql file. - reset the password again.
Yo! It’s working!
I think the problems were likely cause by importing the database before adding the filesystem with which it was intertwined. Better go to bed before I discover any new problems.
At one point when “re-up”ing this install I got error:
Fatal error: Call to undefined function ctools_include() in /sites/all/modules/context/context.module
The solution of which was to move the sites/all/modules
directory.
In the terminal, run
drush pm-enable `drush php-eval "echo 'ctools'"`
Which seemed to create a new modules directory containing ctools. But I think the error was actually caused by us having been missing the profiles
directory.