Mac OS X: Resize off-screen window
When I switched from a large monitor to one with a smaller resolution, the resize handle on the bottom of the window was out of reach. When I tried maximizing, it wouldn't make the resize handle available, either. I also couldn't just move it higher on the screen to get the bottom part of the window I wanted.
The fix: hold Option while clicking the green zoom (maximize) button on the top left of the window.
Submitted by deekayen on Thu, 04/09/2009 - 9:54pm
deekayen's blogNode navigator code snippet
Create a new block or page with Full HTML input format access. The following javascript will redirect you to the node number without having to highlight just the right part of the URL.
Enter a node number in the box below. Clicking Submit will redirect you to it.
<script type="text/javascript">
function handleThis(formElm)
{
window.location="/node/" + formElm.nid.value + "";
return false;
}
</script>
<form onsubmit="return handleThis(this)">
<input type="text" name="nid" />
<input type="submit" value="Submit" />
</form>Depending on your site configuration, you might need to alter the window.location value for not redirecting directly to the root of the URL, in which case an absolute URL might work best.
Submitted by deekayen on Tue, 03/24/2009 - 5:30pm
deekayen's blogViews object from a different multisite.
I have an installation with multiple Drupal sites in one install (Drupal multisite). One of the multisites needs information from another multisite's nodes which use CCK. I've done such things before with direct, custom queries, but it's always bothered me that the CCK fields could shift around on me and my queries break. This time I'm trying to use Views2.
Let's say the site that has the information I want is #1 and the site querying the data is #2. I made the view that gets the data I want in site #1. It works perfectly. Then since I don't really want a formatted display of the data, I whipped up a tiny module to use views_get_view_result() in site #1 to make sure it returned an array that would be something I could use; it was.
Note here that the view is configured to be unrestricted access. It queries nid, author, a rolereference field, and a date field. The fields are managed in #1 by content_permissions module and the node by workflow_access. With all that node configuration and filters for the rolereference and workflow of the node, it still showed the view correctly on #1 through views_get_view_result().
I took exactly the same code I used for views_get_view_result() and put it on site #2, but I wrapped it in a db_prefix changer. The idea I thought would be that Drupal would just temporarily switch database tables and then switch right back transparently. Then I activated all the same workflow, CCK, and views modules on #2 to make sure there wouldn't be any missing modules that #1 needed to put up the same view result.
<?php
$old_db_prefix = $GLOBALS['db_prefix'];
$GLOBALS['db_prefix'] = 'number_one_';
$view = views_get_view_result('my_view_name');
$GLOBALS['db_prefix'] = $old_db_prefix;
?>This almost works to query the data I want from #1, except it doesn't return the CCK fields, only the nid and author. I did a little bit of debugging and found that in views_get_view_result(), the $view object handler for the CCK fields is listed as views_handler_field_broken.
Before I did some debugging to find the reference to views_handler_field_broken, I thought perhaps with the permissions modules on #1, it was a field access issue. I'm logged in as UID 1 on #2, I copied a $user object from a UID 1 session on #1, I inserted a session in the sessions table on #1, and I tried faking a masquerade, so I'm pretty sure it's not a permissions issue since I should be pretending to be UID 1 on #1 when that view executes.
I've tried re-installing views, CCK, the widgets, and workflow on #2 to make sure all the various parts were available to views when it came time to execute the view on #1 during the db_prefix switch. What I'm wondering now is whether CCK does some sort of hook_init() static variable field caching on #2 so that when it gets time to find those CCK fields I want on #1, they're not in the cache. Someone else suggested that perhaps I needed to re-execute some part of bootstrapping after I switch db_prefix, and then again after I switch back. I'm really not sure where to go next for getting those CCK fields to display and the doxygen stuff I found on views_handler_field_broken isn't very detailed on the reasons why it would be used as the handler. Perhaps there's an even better way than swapping out db_prefix and I can't see it cause I'm stuck in db_prefixing land.
A solution:
I figured out a hack that involves refreshing some CCK cache and preventing views from caching by hacking views.
After switching to the #2 db_prefix, I call content_clear_type_cache(TRUE); then comment out the static $cache variable in _views_fetch_data(). I see that _views_fetch_data() calls hook_views_data_alter, but that is executed before I switch to the #2 db_prefix and does not run again as long as the static $cache variable is set.
I still have a little bit of hope there's a way to do this without hacking up views. I saw this in view::execute() that makes me think perhaps there's something I could do when configuring a view in #1 perhaps that would reference data in #2:
<?php
// Allow for a view to query an external database.
if (isset($this->base_database)) {
db_set_active($this->base_database);
$external = TRUE;
}
?>Submitted by deekayen on Sat, 03/21/2009 - 12:30pm
deekayen's blogCCK Content Permissions patch feature
The current distribution of CCK 6.x-2 provides a new module from 5.x that sets view and edit permissions at the field level. Certain roles might be only able to see a few fields of all that is available on a content type and edit none while others might be able to edit a few of those.
Content permissions has one glaring flaw IMO, which has to do with the read-only view status of a field. Let's say, for example, you have permission to view all fields on a content type, but only edit a few. The view page will look like normal, and the edit page will only show those fields which you have permission to edit. What's missing in that picture? You can't see the read-only fields on the edit form. In the cases I use content permissions, seeing the values of the read-only fields is valuable context to know what to change in the editable fields.
Luckily, cYu wrote a patch that adds the values of the read-only fields back to the edit form. I think since yched is such a busy person, he would feel better if other people tested the patch to leave their experiences as well.
Workflow Fields is another module that can set fields to be invisible or read-only, but depending on workflow state, however it does not use the new CCK 6.x field permissions hooks. Instead, it tries to search through the form's FAPI array to find various field settings such as #access and #disabled along with changing to a markup field type to change the handling of content. While more powerful than Content Permissions with regards to workflow awareness, the implementation might benefit from some patching to utilize more of the new CCK field access hook since it has a known buggy history trying to support the various features of the Date widget.
Submitted by deekayen on Thu, 02/26/2009 - 10:49am
deekayen's blogI unmaintained my Drupal 5 modules on purpose
On Feb 15th, I unmaintained all Drupal 5 support on modules where I'm the node owner. I did it on purpose too, even though I know the supposed havoc, disruption, and calamity it causes with the update status module. It's a personal time management issue for me - it's not because I don't like your face or the way you asked me to care. It's not fair to keep 5.x support checked off and give people the false illusion that if they file a 5.x bug, I'll do anything about it. I just don't have time to support all possible versions of the 50 or so modules I either maintain, co-maintain, or patch regularly, and all the other Drupal stuff I do.
Each project page has its own "View all releases" link where all of those 5.x releases are still available. I have not, in the words of one dramatic complainer, "take[en] this module away from the Drupal 5 community." Anyone who doesn't like it should go ahead and look at upgrading your site to Drupal 6, because Drupal 7 will be out this year and I'm in a forward-looking state.
Moreover, running an unsupported module does not mean that it no longer works, or that all of a sudden its full of bugs. Keep using it on your Drupal 5 installation as long as you want. Visit the front page of the module's project page and click "View all releases" (it has the feed icon next to it) to see all the old releases are still there. So when you read this and find out that I don't care about your update status notices for old versions of Drupal, perhaps you'll decide maybe I'm not the only one and you'll find others like me, and that it's time to upgrade your site.
If you have gone so far as to code a bunch of custom modules that you never shared with the rest of drupal.org and you "have no upgrade path", well that's what you get for not sharing with the rest of us. You cannot use open source in a bubble by yourself and be successful. You must not only share, but get others to use your module too so they have a shared interest in getting it upgraded as Drupal grows.
Now go to admin/logs/updates/settings for your update status module and set "Warn if out of date" to Never for whatever modules have been unsupported for your install. By navigation, that is Administer - Logs - Status Report - Settings tab. That feature was added by merlinofchaos in 5.x-1.1.
Submitted by deekayen on Mon, 02/23/2009 - 11:25am
deekayen's blog
