Skip to content

Tag: drupal

Drush – Segfault fixFrustrated computer user

Drush – Segfault fix

Published by Stacie on June 25, 2019

TLDR: Delete the node_modules folder!

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

Delete the node_modules folder!

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.

Drupal tips (2)Man sites at computer desk, hands ready to type.

Drupal tips (2)

Published by Stacie on February 5, 2018

 #3 Why are blocks being deactivated on my site? Why is my copy site acting strangely?

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 )

DrupalCon 2016 – New Orleans

DrupalCon 2016 – New Orleans

Published by Stacie on June 2, 2016

Just returned from my first Drupalcon ever. It was held in fabulous New Orleans where the temps were in the 70s and 80s. Then I came back to Wisconsin where the temps are 40s and 50s, brrr.

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

 

Dev Ops -Workflow, Automation and Performance Tuning.

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!

 

Bad Node, Bad Node, whatcha gonna do?

Published by Stacie on January 12, 2016

I recently switched a site search from using external Google CSE search to using the internal Drupal Core search. This was fairly inconsequential.

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

Drupal tips

Published by Stacie on November 9, 2015

Drupal tip #1 – Locked out of site?

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.