The Challenge:  First off Solr doesn’t index the node/add/your-content-type-here pages by default – I’m certain there’s some workaround, however it’s not obvious (dear readers are welcome to retort).  Secondly none of the form results should be indexed by solr in the first place – we certainly don’t need our patron’s requests showing up anywhere ever.

The Hack: Form Block allows you to make content types available as blocks.  Pretty straightforward, click a few buttons, go to the context editor, and woo-ha = forms in a block = we took the pages that were already returning for the queries we were interested in and just added the form to those pages.

Here’s the VERY brief overview – 1:30 seconds or so worth http://www.youtube.com/watch?v=gzvq-t1m03A that goes over turning a content type into a block as well as adding the block to a context using the context editor that comes with the admin toolbar

Form Block settings in content type

Now is also a good time to mention that if you are using context’s the Admin toolbar is almost required – it really extends the UI giving you a drag and drop interface for your blocks within every context active on a given page.

Adding node form in the context editor

Form Nodes in context Editor

A form in a block!

Quick solution: Using Jammer (admin/settings/jammer) we are able to easily remove the preview (delete, or submit) button on selected content types.  This is also a place to remove path, menu, author and several other fields.

Jammer - remove preview

Saving makes sense for admins, however our patrons really don’t think of saving their work – they’re submitting requests. Making a happier UI is part of the work we do to keep our patrons around, so we use more vernacular terms to mo betta stuff.  The obvious limitation here is that it overrides EVERY string rendered

Simple string overrides simplify succinctly

in drupal (not in the content, of course)

If anyone knows of a module that’ll let us customize buttons on a per content basis please chime in – not interested in writing tpl.php’s for every one of these though – it’s just not that big a deal yet. Speaking of UI thanks Vid @ the University of Oregon (rss added to the left here) for their work with Taxonomy Super Select Styling http://pages.uoregon.edu/vid/2011/01/21/put-taxonomy-super-select-check-boxes-into-1-2-or-3-columns/

For the two minute magic here you go http://www.youtube.com/watch?v=yc9Uc-2WczI

Usually when we write up documentation it’s to explain something we understand reasonably well (or at least think we do) on this post we’re grateful to Doug Chestnut over at Alderman for recommending JSON, twistor and infojunkie at drupal.org for banging up some code.

This is just a brief review of a simple views plugin with a lot of potential. In general it is becoming more and more apparent that having web services is rapidly eclipsing the value of web sites.  Web services means being able to extend your integral core data to other developers without the shrouds of silly design and such that stem from institutional committee design.  Put the data in the hands of designers and let them run with it.

Settings for JSON

All said and done what this means for developers who may have a use for our electronic journals and books data is that by changing a URL they may have direct access to our work as JSON objects – something that SOLR may ingest directly as of 3.1 – for an example on our development server http://drupal.hsl.virginia.edu/e-resource-journals-json/Biochemistry now returns the JSON output of the regular taxonomy view http://drupal.hsl.virginia.edu/e-resource-journals-taxonomy/Biochemistry

JSON Style in views

Of course now that we have all these lovely services who is it we’re servicing?  That’s a question we’re still working on the answer to, however given that UVa’s main library is outputting JSON and running SOLR we’re hoping we may be able to streamline and consolidate some of our work for our patrons  (fyi for the VIRGO JSON the string change is slightly different http://search.lib.virginia.edu/catalog?q=chestnut now becomes http://search.lib.virginia.edu/catalog.json?q=chestnut- still a simple way of handling data objects.

Additional resources:

http://jsonviewer.stack.hu/ a handy tool for JSON viewing

Views Fluid Grid Output

It’s a bit long winded at ~3 minutes, but hopefully thorough enough for anyone following along http://www.youtube.com/watch?v=j0fnqBOAj7k

As a result all our archivists must do to add a new exhibit to the home page is add a new taxonomy term to the archival taxonomy and the image and term description are posted to the fluid grid page.

Taxonomy term with a single term field

The settings within the view itself are pretty straightforward -

Views Fluid Grid settings

and the main thing to remember is that you’ll want to go to imagecache and create a scaled and cropped fixed width preset- this keeps all your pictures the same size and works well with variable sized images.

ImageCache Presets scaled and cropped

and you’ll also want to change the link output to reference your term field.  Any questions or comments welcome, take care and have a great day.

Replace the link with your term field

http://www.youtube.com/watch?v=Ual2-oPLIko

To start with you’ll need to go to /admin/build/activity/create and add activity templates.  Because of how this module was designed I believe it would be pretty simple to extend this module to monitor almost anything.. we just needed to know when certain roles updated or created certain node types, so that was pretty simple.

Setting up an activity template

The use of tokens in the message display section makes for readable and useful messaging

Add tokens for readability

After creating your template(s) you now need to go over to views and add an “Activity” type view – here again – it’s just so cool that you’re extending what is already there and working well… it just makes for an easier time + one less thing to learn!

Adding the Activity in Views

With the View going the rules are pretty much the same as for all views – it’s worth noting that if you want to filter by User Role you’ll need to add the “Activity: User” relationship – this adds all of the typical user fields to your filters as well as your fields.  Likewise if you need more information on the nodes you may add the Activity: Node relationship – it’s not always that important since many of the information may be stored in the tokens.  It’s nice to know that you may access those fields if you need to though – just add the relationship and fields + filters as desired.  Nice work on this module folks = well thought out and well implemented.  Thanks!

Setting up the activity views

The final outcome = another view

Adding the token for a referenced node

We also set the build mode to “Edit page” as well as “Full Node” for convenience in editing.

Views Attach build modes

now we can add all the fields we need from the referenced node and have them appear in your full node and node edit pages.

We have chosen to use a token from the node – a node reference field – as our argument that we pass along to the view.

The view loaded into the content type

The views is loaded into the content type which makes it pretty simple to organize.

The final output has our tabled view inserted into our content = yay

Attached table view in our content

for the video inclined here’s the two minute walk through – http://www.youtube.com/watch?v=pWE78xQK3Z0

A bit sleepy this morning and forgot coffee.  It shows, I know.

Use case: we have some old data – some of it comes in with the number 0 meaning blank, some of the rows contain the word NULL and some of the rows are empty. All three variations mean the same thing. We want to create a single view with all three options open – if it’s the number 0 OR the word NULL or simply empty.

Views Or adds to your filters options

Installation and usage: Install as usual – obviously you’ll need views installed…. To use you will need to add all three of the new fields into your filters block. First will be the “Begin alternatives” then the “Next alternative between your filters, (repeated for as many alternatives as you need) and lastly you’ll need to “end alternatives.”

Views or fields in the filters area

All the pretty fields need to be reorganized

As a lazy lad I like to just add them all at once and then move the options around afterwards, do whatever your gods tell you to…

The final views or arrangement

Programmatically what this has achieved is

AND ((UPPER(node_data_field_er_acq_uid.field_er_acq_uid_value) = UPPER(‘NULL’)) OR (node_data_field_er_acq_uid.field_er_acq_uid_value IS NULL))

In any case it’s a pretty simple module – installs well and saved us from cruddy data. Merci a bunch to all

For the video inclined here’s the 2 minute feed http://www.youtube.com/watch?v=dUoL_ARPLcI

Use Case:  we’ve got a lot of variables being tallied in different views.  Views in general seems an awkward tool for tabulating values.  Tools like views calc and group by work ok for getting a sum or count here and there, but try mixing several together in one view and the errors start to fly.  May just be I don’t have my head around them, in any case they are not intuitive.   For a given organic group node I need to know how many posts there are total (not a problem, that field comes with organic group views integration), and how many of these posts have been completed in a certain way.

Views field view added to fields in view

Choose a view and add fields from the view as argument tokens

Creating this separate view is simple, but now I want to link the main view to the small view tally.  Views Field View let’s you pick a view and pass it an argument to filter the results per row.  In this case we load a node id into our main view and pass the argument over to the Views Field View – creating a new field with the correct info on a per row basis = Nice!

The only thing that doesn’t work is that it does not actually load this view in the order the rows are listed.  Because of this it does not work well with Views PHP.  Although the rows are listed in this global php field the actual data is not available because for some reason the field is not loaded in the order one might imagine it to be.   It’d be really handy to be able to use these variables in calculations, however it’s just not obvious at all how to do that.

Views PHP and VIews Field View don't work together

Custom apachesolr results

We’ve been getting some questions about how we customize our apachesolr results by content type.  The answer:  very simply.  We use views php.  Views php allows us several new field type in views including a place to put custom PHP. It also has the advantage of allowing you to pull in variables already loaded into your view.  Thus while it is possible to write queries to the database in the php area, it is not necessary.  Moreover if you have need to tables not typically available in views you may use the data module to gain access.

For the video inclined here is a link to our 2 minutes on views php http://www.youtube.com/watch?v=cAehdUVrVDs

While there are several fields available in the Views PHP field I tend to use the output field area.  To hide the actual complete results

Using available variables in views php

this makes it so that you can add a few lines of logic and have the results better reflect the information.  For our librarians we output their profile picture linked to their email address, for our web results we provide link descriptions etc.

Excluding results from display allows the results to be available to views php without cluttering the patrons view

Just remember to exclude your fields from display so that the user isn’t presented with  hundreds of fields and you’re good to go.

Organic groups is a great way to organize groups and cascade permissions – in this example we tested against 45,000 users in 3 different roles going in to 500 groups.

While the end result is pretty obvious here’s the 2 minute vid http://www.youtube.com/watch?v=M0uYvlmIGps

While Node import did the heavy lifting for the group node creation feeds came ahead for user imports.  Node Import just has a few more settings for group node creation than does feeds.

This project came about as a conversion from an unmaintainable drupal 6 site that we converted into off-the-shelf drupal.
Modules used:

• Feeds patched with http://drupal.org/node/857424#comment-4038128 for organic groups (originally tested with the node reference patch here http://drupal.org/node/724536#comment-4347036 – i thought that referencing the node was enough to join a member to a group… wrong)
• Feeds Role ID Map – added organic group user roles during the import
• Feeds Tamper – required for adding organic groups via the patch (with the “explode list” filter) and for use with Feeds Role ID Map
• Feeds User Map – allows you to map the author of the node – applied to the survey for permissions
• Feeds View Parser – some data was exported and then reingested to correlate the relationships that were present in the original data
• Organic Groups
• OG Hide Membership – members are not meant to interact with eachother – we’re really just using OG for permissions
• OG User Roles – needed to clean up permissions
• Organic Groups Access Admins – more permissions for the node groups

feeds tamper for role id

Something to remember with feeds – it can get a bit wonky over file line endings and encoding – more so than node import from what I’ve seen. These are the settings that have worked for me coming from mac excel -> open in text wrangler and resave with windows cr/lf and utf-8 encoding

Feeds Settings

The settings are pretty straightforward.

A few things to remember before you upload:

• if you plan on making node aliases do that before you upload – views bulk operations is slower than molasses updating url aliases.  Same goes for auto node titles if you’re using them.
• In general every node reference or user reference you have is going to slow something up

text wrangler settings for feed import

Feed mappings - remember to have a unique id in there

• 

  Permissions settings

Modules tested: although a lot of modules were tested not all really made the cut. Some because they didn’t really seem useful in our case. Others (organic subgroups) because I really couldn’t get a response on IRC or the forums about how to ingest them en masse – if anyone has done this please feel free to chime in) organic groups access permissions settings

• User Import – it only allows you to map your users to a single group.  Thankfully feeds tamper allowed us to map multiple groups per user and group post
• User Import for Organic Groups – these two seemed promising, however UI4OG only allows the users to be mapped to one group… no good for our use case
• OG Subgroups – ok – wanted to see this in action, never really got it working at least not through the import interface- might make a good use case for using the migration modules
• Node Access by User Reference - I really like a lot of Node one’s ideas, and Johan Falk in particular comes up with some very clever ways of re-arranging drupal mods – so I thought I might give this intuitive technique a go – the caveats mentioned in his post indeed became insurmountable – with the need to have 16 user references in each group post my virtual machine came grinding to a halt.