We’ve been working on standardizing our local environments here at work, and have recently started using Grunt and SASS and some image processing as part of our local Drupal development.

Recently I added a Drush command for us to use to easily get Grunt running from any folder in the docroot. It works great! just a little drush grr and off we go!

It’s a pretty simple, and builds off a lot of work I did making a drush command for us to engage visual regression with BackstopJS. (checks for dependencies, grabs git branch name, passes variable flags into JS) I’ll make a different post about that sometime.

Anyway, since all the grunt files live in the theme folder, the most important part was telling drush where that was, so it we could run npm install, and get everything running locally, including live reload, which is awesome.

We’re still using Drupal 7 and by using :

$path_to_grunt = drupal_get_path('theme', 'mc_main');

Now, we can tell drush where to run grunt for us! Of course, we did need to make sure to change the working directory, so the command would actually run there,

chdir($path_to_grunt);

So then we just run`npm install , with a few checks, and we’re good to follow that up with :

grunt --color

Hooray! right?!

Ok, but then I found running drush on things started crashing my PHP with SEGFAULTS all over the place. ugh!

What was going on? How do I fix it, I just wanted to test our latest release and I’m looking at error logs and …

Ok, after some research, and digging through my bash/zshrc files, and getting some strange errors from the command line after trying to drush updb like :

sh: line 1: 36818 Segmentation fault: 11  /Applications/DevDesktop/php5_5_x64/bin/php /Applications/DevDesktop/tools/vendor/drush/drush/drush.php --php=/Applications/DevDesktop/php5_5_x64/bin/php --backend=2 --root=/Users/me/sites/devdesktop/mcmain-dev/docroot --uri=http://default pm-updatestatus 2>&1
     pm-updatestatus failed.

I mean, what? Why is drush trying to even use php 5_5 at all? where is that setting? (I still don’t know.)

I finally ran across this article: Drupal’s Drush Segmentation fault:11

Arvind explains that when npm install runs on your package.json file and creates the node_modules folder in your theme folder…

Drupal freaks out because many node modules include their own .info files. Drupal is looking for only one .info file per theme to exist.

He provides a solution to add a postinstall line to your package.json to remove all the additional .info files inside the node_modules folder.

but! short term, super simple solution for anyone who is experiencing drush weirdness after running an install on a package.json

At least while you’re trying to run other drush commands, feel free to get your grunt on when you’re done.

—update Dec 2, 2019

So, I ran into another strange segfault, this time:

/Applications/DevDesktop/tools/drush: line 11: 77368 Segmentation fault: 11  "/Applications/DevDesktop/tools/vendor/drush/drush/drush" "$@"

Which again, seemed very strange. But, happily, the same solution (removing the node_modules folder from the theme I was testing) still works!

It doesn’t seem to be an issue with my teammates, but I’m leaving this little update to remind me, and maybe you that sometimes the solution is not what the error is complaining about.

If you copy an entire site in order to split apart some of its content, make sure you investigate the cache folder and remove any remnant of the previous site cache. There may be a folder for the previous site.

Otherwise, for a little period of time, you’ll be getting some strange behavior that makes it seem like the old site is still hanging around on the new install.

Even if that description didn’t make sense, if you are having strange theme behaviors that flushing the cache, rebuilding permissions and/or a restart don’t seemed to have fixed… check out the cache folder on your server. 

Additionally, if you a splitting a site into two, and intend to use both sites on the same machine, and in the same database instance(ie, two databases on the same machine), make sure you check that the copy site isn’t pointing to any shared folder on the server, ie your cache folder. If somehow, both sites are using the same cache folder, changes on one site may affect the other site.

You are better off changing your site into a multi-site instance, for Drupal 7, because that should mitigate most of these problems. Multi-sites use different cache/files directories unless explicitly sharing modules/themes/frameworks out of the sites/all folder.

#4 git loses track/won’t overwrite settings.php file. (combo drupal + git tip)

error: unable to unlink old 'sites/default/settings.php' (Permission denied)
fatal: Could not reset index file to revision 'origin'.

Repairing/resetting my mac home directory permissions seemed to fix things. ( Resolve issues caused by changing the permissions of items in your home folder )

Here is a quick run down on the tech I learned about, I have so much to dig into and learn!

Drupal 8:

Quick rundown for Drupal 8 -Kickstart Video

Drupal 8 Kickstart Session Video

• Symfony – Drupal 8 is now using the Sf PHP library.
  • Twig Templating – Designers (Templates) – Developers (api)
    • Sublime Twig Text Bundle 
• Composer – a Package Manager for PHP, uses JSON.
  • helps find what you need and installs it, and  any missing dependencies.
  • can download and keep current all software with 2 commands.
  • Using Composer to install Drupal/modules.
• Drush
  • Industry Standard best practice CLI tool
  • Does things 3x-10x faster than thru working through admin web.
  • Requires PHP 5.5+ for current version 9, 5.3.0 for Drush 7
• Drupal Console
  • New command line interface tool for Drupal
  • Creates boilerplate files for modules/themes
  • install into every website or globally.
  • ‘make a blank module scaffold, do some admin tasks’
• YAML
  • stands for ‘YAML Aint Markup Language’
  • new drupal config file format – for default settings
  • .info becomes .info.yml

Dev Ops -Workflow, Automation and Performance Tuning.

• Vagrant – builds complete virtual dev environments, share them
  • ZivTech VM – https://github.com/zivtech/vagrant-development-vm
  • Charging Hawk Lightweight VM https://github.com/charginghawk/vagrant
  • Drupal VM http://www.drupalvm.com/
• Testing & Automation
  • Selenium/Behat
  • Jenkins
  • Probo.CI
  • Ansible
• Caching
  • Varnish

My overall takeaways:

We need to get our workflow in order, and we have so much to dive into for 8. Lots of the optimization will help our Drupal 7 installs as well.

I’d really like to get some common/version controlled local environments setup, like with Vagrant, so we can all be using the same local, and keep that under version control.

Standardize! Automate! Version!

I switched to Node search under Config -> Search and Metadata, swapped the CSE block out of my sidebar in Content ->Structure, made a few theme CSS changes to match and I should have been done.

Except for indexing the content, trivial, right? Just run cron a few times and you should be all set!

Only, no. That didn’t seem to work. I kept getting a couple strange errors in the log messages.

Warning: Creating default object from empty value in node_build_content() (line 1398 of /Users/user/sites/sitename/modules/node/node.module)

and

EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7879 of /Users/user/sites/sitename/includes/common.inc).

After a good deal of searching, and some helpful hints from the #drupal channel I tried a few different modules but none of them addressed the one issue I was having, which was increasing the indexing. I was stuck at 8%.

I finally found this post http://tappetyclick.com/blog/2013/01/14/how-find-bad-node-makes-search-indexing-cause-drupal-cron-fail

Which mentioned that they had found a solution on a Portuguese site, and translated it for us.

My drupal version is a little bit different than the example at tappetyclick, but the gist is: Output the indexing process to the log by adding a watchdog line to  the core file modules/node/node.module”

'watchdog ('cron', "indexing node {$node -> nid}"); // ADD THIS LINE'

This made my node_update_index() look like this:

function node_update_index() {
 $limit = (int)variable_get('search_cron_limit', 100);

 $result = db_query_range("SELECT n.nid FROM {node} n LEFT JOIN {search_dataset} d ON d.type = 'node' AND d.sid = n.nid WHERE d.sid IS NULL OR d.reindex <> 0 ORDER BY d.reindex ASC, n.nid ASC", 0, $limit, array(), array('target' => 'slave'));

foreach ($result as $node) {
 watchdog ('cron', "indexing node {$node -> nid}"); // ADD THIS LINE
 _node_index_node($node);

}
}

Then I ran cron manually and checked the log messages, filtering for cron types only.

cron 01/11/2016 - 5:00pm indexing node 1803 Anonymous 
cron 01/11/2016 - 5:00pm indexing node 702 Anonymous 
cron 01/11/2016 - 5:00pm indexing node 7676 Anonymous 
cron 01/11/2016 - 5:00pm indexing node 6801 Anonymous

Everytime I ran into EntityMalformedException: Missing bundle property on entity of type node in entity_extract_ids(), I’d look at the last node we’d tried to index, this was the bad node, and delete it from the database.

After removing about 40 of these bad nodes the core search index actually reached 100%. /kermitarms

Empty the ‘sessions’ and ‘cache’ tables and login at

yoursite.com?q=user

Drupal tip #2 – random Ajax Error in the workbench?

Check your server memory settings, you may need to increase either the mysql memory or the limits in the php.ini

Find your current php.ini from Drupal Admin -> Reports – > Status Reports. 

Scroll down to the PHP line and click ‘more information‘ this will take you to a standard PHPINFO() page for your server.

Look for the Loaded Configuration File line to find where your current php.ini file is.

Consider increasing the Input_Vars limit.

Make sure to restart the server after making changes to the php.ini file.