node add/edit

Variants and Node Add/Edit Overrides

Variants in Drupal allow you to reuse Panel Page layouts to make your life easier. You use Selection Rules to allow the system to decide what variant to use based on any number of criteria. In my case, I use Variants on the node add/edit form to provide a consistent interface between several different content types. As with many things Drupal, there are a few idiosyncrasies.

I have a custom content type called member-galleries. This holds images in a gallery like display. To render the add node properly, I had to learn the hard way that using

the “Node Being Edited: Gallery Image form” is not the correct form to use. Even though Gallery Image is the field name that I gave the Image field on the content type that I created. It just seemed to make sense, right? And even worse, it appears when you test the functionality that this is the way to go. But, I kept getting a red herring error about file size when I would try to save an image. It turned out that the Variant really needed the “Node Being Edited” Base form instead. It appears to be exactly the same until you try to save a node of the content type.

Turn Aggregator items into true Drupal Nodes

Drupal 8 should address the longstanding issue with items from the core RSS aggregator module existing as simple db objects rather tahn nodes, which limits what you can do with them in many ways.

The core Aggregator is really a big deal for me. the db created from these items is one of the biggest draws to my site. So I have tried many things to work around the limitations of DB objects.

I flirted with the idea of dumping the table to a flat file then importing it. That would work, can be CRONed and all that. But I really want to keep my solution specific to Drupal and not engage in a one-off like that.

The core mod has a categorization interface that I really like. It allows me to go through 100s of items every day pretty quickly and assign relevant topics to one of about 20 categories.

So, this is what I did to get the aggregator db items into nodes.

I created a View of the Aggregator Items. I created an RSS feed based on this View. then I used Feeds Importers to import that RSS feed into a content type that I created just for that. This will work and you will be able to get quite a bit of data from the importer. But it isn’t as flexible as I wanted. UI simply could not get all the fields that I wanted to come across, even when forcing fields. That will work, but I always got undesirable formatting for the links. Or the links would come across malformed, with the name of my site prepended to the URL for example.

I really can’t use the Feeds Importers module to import all of the items in natively either. It will work, And you can build an interface of sorts in Views using VBO to assign taxonomy terms to the items, but it is cludgy and doesn’t scale well. But that can be a viable method too if you don’t have a lot of volume.

So, I want to use the core module for its stability and ease of categorization. but I need to be able to do things like allow users to see the items and make comments on them. I say comments but I really mean take notes. So, I used a Views Content Pane (with override URL and AJAX enabled) with a Node Add/Edit Variant in a Panel Page to allow user to see the Aggregated items, drag URLs from the View, take notes and alter the View (that’s where AJAX is magic) from the same place. Here is a SS of what it looks like.

Then, I created another View of the Content Type “Research” which is used to hold the notes, links and such. I created a simple Content Pane View that shows the title of the Nodes (I use the Private Module to keep these posts completely private) and enabled AJAX so that the View Content Pane refreshes without having to refresh the whole page. Now I have a very nice research interface for my member with an easy way to reference my data.

More on Variants for the node add/edit forms

So I have Forums, Blogs and Galleries. And I want to style each one differently. So my first thought is to put the form inside of a Panel Page so that I can add other content. And that is the right direction, but it isn’t enough.

The Node Add/Edit form is already in the Page Manager as a Panel Page. It is disabled by default. By enabling it, I will have the ability to customize the form’s display. I already explained the part about the contexts

method of determining what node type will be affected by the change. But here is something to keep in mind.

If you enable the page, and then create a variant for a content type to be used (when you add a node to that content type for example) you will find that the add form for ALL content types looks like the variant you created for example, for the Blog entry content type.

You will need to create a variant for each of the content types individually or they will all inherit the one variant’s customizations. and what I had to do to make THAT work properly was to use a selection rule for the variants that come at the beginning of the list. Since variant order determines in a large part, what is applied, you have to create selectors so that the “filtering” process works properly.

This is one of Drupal’s great strengths, but it is also kinda strange to me and took a while for me to get my head around. Look at the SS. Each of the three content types has a variant. and a context that applies to it. But, without a Selection Rule that also applies to it, the variant will simply inherit its appearance from a rule above it, the first one that happens to apply. There are other ways to do these same things with selection rules