<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet href="/assets/atom.xsl" type="text/xsl"?><feed
	xmlns="http://www.w3.org/2005/Atom"
	xmlns:thr="http://purl.org/syndication/thread/1.0"
	xml:lang="en-US"
	><title>Sacha Chua - tag - gotcha</title>
	<subtitle>Emacs, sketches, and life</subtitle>
	<link rel="self" type="application/atom+xml" href="https://sachachua.com/blog/tag/gotcha/feed/atom/index.xml" />
  <link rel="alternate" type="text/html" href="https://sachachua.com/blog/tag/gotcha" />
  <id>https://sachachua.com/blog/tag/gotcha/feed/atom/index.xml</id>
  <generator uri="https://11ty.dev">11ty</generator>
	<updated>2009-03-09T19:13:35Z</updated>
<entry>
		<title type="html">Drupal gotchas: watch out for Views dependencies</title>
		<link rel="alternate" type="text/html" href="https://sachachua.com/blog/2009/03/drupal-gotchas-watch-out-for-views-dependencies/"/>
		<author><name><![CDATA[Sacha Chua]]></name></author>
		<updated>2009-03-09T23:13:35Z</updated>
    <published>2009-03-09T19:13:35Z</published>
    <category term="drupal" />
		<id>https://sachachua.com/blog/?p=5870</id>
		<content type="html"><![CDATA[<p>One of the downsides of writing all configuration changes as update functions in .install files is that you need to watch out for static or cached variables and module dependencies. </p>
<p>For example, I just finished helping a teammate debug an elusive Views problem. The symptom: some views with blocks didn&#8217;t show up in the blocks table, even after a <a href="http://api.drupal.org/api/function/_block_rehash/5">_block_rehash</a> in the update function. Other views were there. If we ran the update function independently, all the blocks appeared in the blocks table. What was going on?</p>
<p><a href="http://api.drupal-contrib.org/api/function/_views_get_default_views/views">hook_views_default_views</a> is a great way to programmatically define views. By using the Views Export function, you can interactively create the view, then export the code so that you can make the view available on your production site without manual administration.</p>
<p>However, if your new view requires a table (<code>$view->requires</code>) that doesn&#8217;t exist, then <a href="http://api.drupal-contrib.org/api/function/_views_get_default_views/views">_views_get_default_views</a> discards it. By the time you enable the module in another update function (and you&#8217;re using update functions to do things like that instead of manually enabling modules on your production site, right?), views_cache.inc has cached the (incomplete) views list and won&#8217;t recognize that the requirements are now available.</p>
<p>To get around the view dependencies, comment out the <code>$views-&gt;requires</code> line. It&#8217;s a hack, but it&#8217;s probably better than hacking all the functions that cache data in static variables.</p>
]]></content>
		</entry>
</feed>