Stacie Arellano

Artist, Author, Web Maven

Tag: tips

Drupal tips (2)

 #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 )

How to fix Xcode Crashes

Tips for when your Xcode/beta crashes when you try to run.

TLDR: Xcode was crashing after building successfully but before running. Deleting my User Prefs fixed my error, but I’ve listed the steps I tried, and some other best practice options below.

My problem was this: Xcode 8 beta 2 arrived, and I went merrily on my way playing with all the great stuff we learned about at WWDC.

However, everytime I tried to build and run in the new Xcode beta 2 (and later in beta 3) I would get a successful build and then the whole program would crash without opening the simulator or deploying to a device.

I talked to a lot of people in my knowledge network, and did all sorts of searching on the error I was getting:

“Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
ProductBuildVersion: 8S162m
_ASSERTION FAILURE_ in /Library/Caches/”

This was strange, because the app I was working on was not using SpriteKit at all.  It was from a tutorial from Paul Hudson from his new Practical iOS 10 book. (which is great so far, fyi)

To test that it wasn’t something I’d done in the project, I made a new blank one, cleverly named ‘dontcrash’, and tried to build and run it. Xcode crashed again.

I actually ended up with several blank apps: dontcrash2, dontcrash3 dontcrashXcodebeta3 and finally- CrashyApp, before I hit on the solution. 

Basic Options for Xcode Crashes

  1. Clean the project.
  2. Target a different simulator you haven’t tried with the project yet.
  3. Delete Derived Data directory
  4. Delete app, re-install.
  5. Delete User Preferences
    1. As mentioned here:
    2. Note: Deleting the app and reinstalling does not remove the user preferences.
    3. This fixed my problem.Not sure how my prefs got confused in the first place.

Advanced options (I didn’t get this far)

  • Monitor memory usage in the Debug navigator
  • Inspect a few malloc generations in Instruments


Bad Node, Bad Node, whatcha gonna do?

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)


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

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

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

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

© 2018 Stacie Arellano

Theme by Anders NorenUp ↑