Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough

Hedron: Or my dissatisfaction with local development.

Jan 13 2017
Jan 13

A response to Maxime: On Drupal and Drupal Commerce

Nov 28 2016
Nov 28

Migrating my blog from Drupal 6 to 8

Nov 07 2016
Nov 07

On pursuing new things.

Apr 01 2014
Apr 01

A Drupaler in Symfony Land

Aug 18 2013
Aug 18

Drupal 8: Blocks & Layouts Everywhere

Mar 02 2012
Mar 02

Using Google+ Pages for Modules

Nov 16 2011
Nov 16

Site Building Super Tools (AKA my Drupalcon/camp Sessions)

Nov 06 2011
Nov 06

Changing How You Administer With Contextual Administration

Oct 21 2011
Oct 21

Drupal Core's Future and Current Problems

Sep 05 2011
Sep 05
Mar 21 2010
Mar 21

If you've been following my blogs about the various administrative interfaces we've been playing with, you'll know that I've proposed the idea of building a system through which these sorts of administrations could be deployed by site administrators without the need to understand what it would take in terms of module development to do so for themselves.  Since I started playing with this stuff ctools has really become very common place, and it's page_manager module is perfect for doing this sort of work.  With that in mind we're announcing Contextual Administration module.

Contextual Administration is a ctools dependent module designed to deploy single page interfaces that would be impractical to deploy in a panels type interface.  It comes with a number of built in plugins for things like node creation, user creation, and taxonomy administration.  Creating your own plugins is easy (though I'm still working on the documentation for that particular feature).

Why not just use panels?

This is a completely legitimate and understandable question because well... panels is awesome.  The reason our plugins don't just interface with panels is because while having node_creation forms as plugins to panels would be cool, it gets impractical pretty quickly if people start trying to utilize multiple forms together.  For the sake of simplicity (and sanity) we chose to just provide our own interface to page_manager.  The upside to this is that we get the ability to mix our variants with panels variants so we still get the best of both worlds and it's simple enough that anyone can deploy a context_admin page without needing to understand everything that panels can do.

What features come with it out of the box?

Our main focus in developing context_admin was to provide a menu based administration system that could be deployed anywhere at any time.  Personally I use this to deploy new administrations through "tabs", or MENU_LOCAL_TASKs for the more technically inclined.

Since we've interfaced with page manager, these page definitions can already be exported, and will bundle into features module with no additional work.  You can bundle them just like you would a panel.

Out of the box we currently (beta4) provide plugins to allow for:

  • node creation of node type X
  • node creation of node type X as a menu child of the parent node (requires a node/%node/* path currently)
  • node creation of node type X with an automatic node reference (requires a node/%node/* path currently)
  • taxonomy term edit
  • taxonomy vocabulary edit
  • taxonomy vocabulary term list
  • taxonomy vocabulary term add
  • taxonomy term add as sub term (requires taxonomy/term/%term/* path currently)
  • user creation (with tons of configuration here, you can auto-assign roles, status, and more)
  • Node administration of node type X via a views_bulk_operations style view (requires views_bulk_operations module)
  • Administration Sections (these can only be used in conjuncture with a /admin/something path.  You simply add one of these, and then add links to that through the typical menu system, and it will build up your own administration section just like "site building" or "site configuration")

We intend on doing a user administration via VBO as well but it's not in the current beta release just yet.  We may also provide our own actions that don't require various user perms to make the VBO based administration a bit more usable without having to hand out administrative privs to users.

WHOA?! Isn't that a security issue?

Uh... "YES", yes it is a "security issue". With that said, let's cover that topic for just a moment.  Any time we're allowing for nodes to be created w/o the user having the perm to do so, that's a "security issue" as well.  What is worth pointing out here, however, is that there's still security here, it's just up to the site administrator instead of being hardcoded by drupal core.  Drupal 7 has already been altered to work this way in a number of places, not the least of which is node creation and user creation.  It's frankly sad that VBO was forced to alter its existing functionality to cripple this power to begin with.

What that really means is this:  Drupal 6 utilizes a number of additional checks over those already provided by the menu system to determine if user X should have access to perform task Y.  Now the menu system actually did this check already (for example, "create page nodes").  The menu system is already running a user_access() check against that perm, and if it's NOT it's because some other module has altered the menu to do something else.  The node_add() function does an additional check against this same set of parameters before it will allow a user to actually even visit the node creation form for pages.  If the menu is altered, then this blows up spectacularly (which is why context_admin is actually providing its own version of node_add()).  This same is largely true for user creation, except it's a lot messier there.  Both of these functions have gotten some love in drupal 7 so that the menu system is the one in control, and thankfully this means that as developers we got a LOT more flexibility out of drupal core.  It also represents a bit of a shift from a security perspective in that we're recognizing that the menu system really should be in charge of these things.  Thus I would say the logic goes for VBO (and context_admin) in the same way.  The site administrator is in charge of preventing users from visiting these administration pages, and if he doesn't it's not actually a security issue for the module.

Why are you bringing this up?

It's sort of odd to be pointing out issues in a module I just released, but I'm afraid I need to make my argument FOR my approach before I start getting security issues filed against me.  I feel VBO was unfairly picked out in this regard as well, as views provides a perfectly good solution for access control to a view.  The point is, drupal 7 has already embraced this logic in many places, and we get a LOT more development power out of it.

Quick aside, I've been using this in production for a while and am quite happy with it.

Kris "EclipseGc" Vanderwater

Oct 10 2009
Oct 10

If you've ever used the drupal views module, chances are at some point you've needed to suppress any output until AFTER the user has made a selection from one of your exposed filters.  Views actually DOES make this possible, but it's not exactly self-evident.  I'm going to run you through a quick "howto" on this as I'm sure many people have needed it at some point.

As I mentioned above, this is possible but not particularly self-evident.  Views has a number of different "global" group items.  The most common of these is probably the Random Sort.  Within arguments you also have another member of the global group, the global NULL argument.  This is basically a way of attaching your own rudimentary argument to a view.  Through the use of the default value (as custom php) and custom validation (again through php) you could cook up just about anything.

With our global NULL argument in place, the following settings are about all we need to make this really work:

1.) Provide a default argument
2.) Argument type -> Fixed entry (Leave the default argument field blank as what gets passed is irrelevant to our needs, we simply needed to make it to the next level which is validation
3.) Choose php code as your validator
4.) Check through the $view->exposed_input array.  I recommend using devel module's dsm() function here because it will respond on the ajax that view is using (unlike drupal_set_message()).
5.) Set "Action to take if argument does not validate:" to "Display empty text"

You can get as fancy in step 4 as you need, but it's just down to good old php if statements at that point.

I hope this howto helps other people.  We've found it rather useful, and since it's sort of arcane, I wanted to share it.

Thanks to Earl Miles (merlinofchaos) for pointing me in the right direction on this one!

Oct 09 2009
Oct 09

Currently there's a pretty in depth discussion surrounding hosting install profiles on drupal.org and what the legal/other implications of such a thing are.  I feel this is an important issue to highlight to the community at large, and since I feel rather strongly about it, I'm using this forum to point it out, and also to focus a bit on my own feelings concerning this.  For those of you who would like some context, read this post on drupal.org.

This specific issue is surrounding the wonderful new possibilities revealed by the new drush make library on drupal.org.  In short, drush make provides the ability to build a simple file that drush will process and from which, build a full drupal platform.  In terms of install profiles, this could be exceptionally useful as authors could easily build a robust platform of all dependencies that their install profile will need to work properly.  Now the work of building the profile still has to be done, but install profiles are essentially a set of configurations for the various modules your profile specifies. 

Currently install profiles are distributed "as is" on drupal.org.  There is a proposal to start providing profiles as fully built tarballs that are simply ready to be installed, and drush make would make this rather simple to do, however there is a bit of fear that this will open up drupal.org to a large level of legal issues due to various licenses of the softwares involved.  This may seem like a "what?!?" at first, until you understand that drush make can actually pull software from external sources.  In short, if you were inclined to have a fully functional wysiwig editor in your install profile w/o the need for custom configuration/installation, this would be totally possible.  However, the community typically utilize tinymce, or fckeditor which are all external programs from drupal itself, thus the legal issues ensue. (In fact this is just the tip of the iceberg, drush make can even apply patches posted to specific issues on drupal.org, but I digress)

So, all the legal mumbo-jumbo is... non-trivial.  And I'm certainly not trying to trivialize it, however we HAVE to recognize that this is THE killer feature of drupal in years to come.  If we nail this profile thing, you could literally build profiles that replicate the other platforms we compete against, and we'd all still be benefiting from the same core/modules as necessary.  Want a wordpress clone? Want a Joomla! clone? Want a profiles with a simple UX approach to the same core you know and love?  We know that where competition thrives, so does innovation, and the drupal 7 release, while I'm sure it will help significantly with some of our UX woes, is not the "be all, end all" of UX bliss.  Make profile distribution on d.o easier, more powerful and come up with a solution that doesn't exclude external code libraries and we will be well on our way.

In short, fully realized install profiles are a game changer for the entire CMS market (in my opinion).  It essentially reduces "Drupal" to a development platform, and leaves the "content management" needs up to the profile developer. Drupal.org needs to step up and support this as much as possible.  If d.o doesn't I can guarantee that some other site WILL, and that will not benefit the community at the same level.

Sep 19 2009
Sep 19

It's about freaking time!  As a professional web development shop, sometimes your website can suffer from the "cobbler's kids" effect, namely you're so busy working on other people's websites, that you haven't taken any time for your own.  I've been working to remedy that for a little while now, but I'm always up for trying something shiney and new, so... I decided to do it in the (fairly) newly released Panels 3 module. For those of you who have not yet tried Panels I can offer no stronger encouragement than to say it is the best thing since cck and views. I've not yet had the pleasure of exporting panels into their own module (think views export) but the maintenance possibilities here are very exciting.

I can tell you that the vast majority of the public facing portions of the site are built entirely in panels.  The front page is it's own special layout, as well as the internal pages.  Panels has made creating your own layout plugins incredibly simple (never mind the flexible layout that's included in core).  I've tried to donate back what knowledge I've gained as I've done this through a couple of patches (some documentation for panels, and the footer message page element for ctools).  It's sad to me to see panels show up so late in the D6 cycle, but despite that, it's so promising with the various features and powers it provides, this alone could revolutionize the way you build Drupal sites.  Panels has ACTUALLY simplified my theme.  The ability to represent the layouts I wanted within panels, without the need to build a page-front.tpl.php and a page-blog.tpl.php etc etc was really empowering.  I utilized Zen for this version of our look (which we'll be updating soon) and I actually simplified zen's default page tpl file by removing $title, $tabs, $footer_message and a few more things.  True, I had to re-configure these things within panels, but the simplicity of doing so, and the flexibility of the end product made it well worth the effort.

There were a number of SEO wins as well.  The primary win was that of node titles and h1/h2 issues.  There are a number of ways to solve this particular problem, but as I mentioned before, I removed title from the page tpl file in zen.  This is because panels allows me to override the individual node's title (with nothing in this case) and then have it displayed in the page title (h1) instead of the typical node title (h2).  This is great for singular nodes, again panels simplified any sort of alterations I might normally have made to my theme layer by just providing the options I wanted right out of the box.

The removal of tabs from the page tpl was an administrive aesthetic one.  I didn't want my tabs over the entire panel, I wanted them in with the content to which they pertained.  Again the panels tabs page element provided this right out of the box (you need to be running dev version of ctools to get more than one page element on screen at the same time).  In addition to this, I wanted my footer message as a page element, but it wasn't part of ctools plugins yet.  Merlinofchaos has made it very easy to add in new plugins of these types.  With just a little bit of work, I had my own footer_message plugin built very quickly. It worked exactly as I had hoped it would, and allowed me to build a great footer minipanel.

Minipanels really are a wonderful tool as well.  I built an additional layout style specifically for my minipanels so that I could utilize them with the most efficient markup possible.  Panels, by it's nature, adds a little bit of markup to whatever you may be doing layout wise, but most of this is helper markup for node edit links and things of that type.  Howere, if I know for certain that the content I'm dealing with is going to end up in a div of its own at the end of the day, having minimal (or no) markup surrounding it, but still having the ability to group it together is very powerful.  For the footer I built an "empty" layout, that was literally one region with no markup.  This meant that utilizing minipanels to build up grouping of content that would be the same from one page to the next made a great deal of sense.  With that in place, I built my footer once, and simply included it into the same region of the various panels again and again.

In all, panels is an amazing tool.  I will certainly be utilizing it more.  The new apis it provides are very empowering, and can simplify your maintenance needs pretty significantly.  If you haven't tried panels yet, I'd heavily encourage you to do so.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web