jcfiala | Entries tagged with drupal planet

This is a blog post copied from John's Website - please feel free to join him there and post comments. He has set up openid, so you can post there with your livejournal account using your openid, which is the same as your journal url minus the http://. You can find this entry at http://www.jcfiala.net/blog/2012/08/27/useful-drupal-module-stage-drupal-proxy.

Here's a useful module that I keep forgetting the name of, so I wanted to note it down: Stage File Proxy. It's not something you use for a live site, it's something you use while developing.

The basic idea is this: you're working on a site that's since gone live, making changes for the client. It's easy enough to get a copy of the database, but the files can be a pain to keep replacing, interlacing test files with live images. Stage File Proxy fixes this by snooping in on imagecache and, when a file is missing, then it grabs it off of the live site, copies it to the local directory, and then you've got the file locally and all your imagecache files get generated for you!

There's a version for six and for seven, and there's no ui for it yet, although there is a patch for it. Then again, once you've got the simple settings done, you don't need to worry about them again!

Here's a quick snippet I just found out today: The jquery cookie plugin is presented as part of Drupal 7. This is really cool and useful, but I must note that it's not automatically included on every page load, so you'll want to include it if you want to use it, and as well it doesn't seem to actually be documented anywhere on drupal.org.

Happily, the original documentation for the plugin is at https://github.com/carhartl/jquery-cookie/blob/master/README.rdoc, and is pretty good, although I suggest reading it through at least twice, as at first I missed that you can read, as well as set, cookies with this. Basically the parameters are the cookie name, the cookie value, and then an options object which says the expiration, the path, the domain, and such. Note that the expiration can _either_ be a date, or a number of days.

Hopefully this will help other folks out with using the jquery cookie plugin with Drupal 7.

(I originally wrote this for G+, but since it's long enough, I'm making it a blog post too.)

So, I'm making a new component for webform in Drupal, called 'Multigrid'. It's based on the grid component, which if you don't remember it, allows you to define a set of common options (like, neutral, dislike, hate beyond rational thought) and define a set of questions, and then it sets up a grid of radio buttons, where the answers are across the top and the questions go along the left side.

If you're picturing the online survey you filled out recently in the mistaken hope that you might win $500 after eating at sit-down-chain-restaurant-326, then that's pretty much it.

( Read more... )

It's been a very long week to me leading up to Drupal Camp Colorado, but it's been a successful and satisfying one. Over the weekend I complained a few times at people not to let me run three presentations, but honestly, I loved it! Really, I quite like standing in front of folks and trying to teach them something I'm passionate about, and I was lucky enough to do it three times. I may not get to do that again, really - with the way the Drupal community is growing these days in Colorado, more and more people will be available to step up and help out with sessions like this.

( Read more... )

Something useful sounding from #drupal-colorado:

<cyberswat> drush php-eval '_field_info_collate_fields(TRUE); _field_info_collate_fields()' ... arrrrrggggghhhh /me curses loudly
<cyberswat> should never have to run that
<cyberswat> c4rl: if you ever have an instance where your installing new fields and instances and every piece of code tells you that everything worked from the update hook but you still don't see the instance then run the above
<cyberswat> that took between 4:00am and now to figure out

<cyberswat> for some reason field_cache_clear(); in field_create_instance() didn't do the above as it should have
<cyberswat> field_read_instances() reads from the db not cache
<cyberswat> so when your drush_print_r ing away you'll see wrong information telling you everything is golden

This sounds like an important thing to remember.

So, I like working on Drupal in virtual machines, and my favorite is to use Ubuntu 8.04, because it's got PHP 5.2.x, which Drupal 6 works with better than it does PHP 5.3.x. Unfortunately, the git that Ubuntu provides us with is from 1.5.x, which doesn't allow use of git clone --branch. And the git
instructions seem to require those. What to do? Happily, you can compile git yourself:

First, get rid of git if you've already installed it - sudo apt-get remove git-core should do that.
apt-get install build-essential
Download the latest version of git. http://kernel.org/pub/software/scm/git/git-1.7.4.1.tar.bz2 works currently.
sudo apt-get build-dep git-core
tar xjf git-1.7.4.1.tar.bz2 (or whichever version you downloaded)
Change directive into the new directory.
./configure
make

( Read more... )

I continue my work with the Migrate Module, and recently ran into needing to migrate a value to the Link Module. If you haven't gotten into it yet, Migrate generally expects other modules to handle migrating special bits for nodes, except for the CCK module, and that's included both (I think) because it's in D7 core and because it's so bloody common. Field-specific handling is dealt with by implementing a MigrateFieldHandler, which basically sets up the arrays properly. Again, migrate comes with a number of MigrateFieldHandler classes for the core cck fields, but not for custom CCK fields, like Link.

So, having recently run into a link field I needed to migrate, this is a first swing attempt at handling it. Do note that any module that includes this class will need the Migrate api hook that I discussed in my last post, and also note that I intend on including this fix in the next release of the Link module.

( Read more... )

I'm currently in the midst of setting up a migration from a pretty huge MS SQL database to Drupal, in D6. This migration not only involves Microsoft SQL Server, as I mentioned, but it also involves using mongodb, so we're basically touching three different databases here.

So, I've been using the 2.0 branch of Migrate for 6.x, because I was curious about seeing it again, and I know it worked quite well for Examiner. (Yes, they were doing Drupal 7, but it was still the same basic idea.) It's been going very well.

Today I updated to the 6.x-2.0-beta3 version of the code, and I had to make a couple small changes to my existing module. I'm reproducing them here, in hopes that it can prevent others from having trouble like I did.

( Read more... )

Here's where I'm posting the various files that I promised to deliver - these are the files I used in my DrupalCamp Colorado 2010 presenation on extending Solr.

Today is exactly one week before I leave for San Francisco for Drupalcon, and so I decided I needed to go by MicroCenter and pick up a few supplies.

For one, when I'd been typing up some notes in Open Atrium the other day, my house's power blinked, and my computer shut down, and restarted. I almost had a heart attack, and the waited on the edge of my seat to see if the browser (Google Chrome) would somehow magically remember what I'd been typing. Happily it had, and I quickly saved the entry before finishing it up. But that really taught me that I need to have a UPS if I"m working from home.

For two, my KVM switch had been dying slowly recently and this morning it had taken three successive restarts of my computer for the switch to work. That was pretty much the end of the line for me - I suspect that's why it wasn't working with my Mac recently either.

( Read more... )