Planet Drupal

If you are a graphic designer or Drupal themer, you don't need to be stuck using Arial on your website; you can easily use a great typeface from one of several providers and implement them using a Drupal module called @font-your-face.

read more

Today we are releasing the final videos in the Page Manger series! And, yes, these are FREE videos brought to you in conjunction with NodeOne.

We will explore:

• A helper module that enables you to auto-populate node reference fields for new nodes using Contextual Administration.

January 27, 2012 - 6:00am

read more

Some problems that you stumble upon when building Drupl sites could be unique for that project, maybe some special mix with the modules that create errors that you do not get in another mix, this could be one of unique problems.

One of the Drupal 7 projects we are working on right now had some strange problems with the Public file system path. The file path did not work when we installed site (drush si profilename). If we after a site install tried to upload images to content, that did not work, and the path got screwed up (with null in it - this i believe comes from the Media module) We are using a workflow where we do site installs a lot, to handle problems early in the project.

We had to go to the settings page (that showed the right file path), change the file path, save, change the path again to what we had before. Save. And it worked. But we do not want to do that every time, do we?

So we had to solve the problem, some how. I do not where the problems come from, and did not have the time to investigate further. But we solved it with setting the variable for the path in the from the setup_config function in the .profile file of the profile we use to install the site. So you could do it like this:

function profilename_setup_config() {
variable_set('file_public_path', 'sites/default/files/');
}

I just works. Not so much a hack, just configuration. But configuration that I think we should not need to configure ourselves. Anyhow. Problem solved. In this mix.

configurationvariablessite install

Drupal.org is great to maintain a solid number of issues but all of us trying to wrangle a huge number of issues need way better tools to have overviews of what is going on and how is work structured. We need to be able to help new people join in quick, let them have an overview of current tasks and also on the place of tasks in a bigger picture. So we need to have the bigger picture documented with the possibility for people to dive in on demand and we need to keep it always up to date and relevant.

The Drupal.org issue queue is great to see a status of issues, but it is not good at all in maintaining relations and especially bad at providing support for hierarchy and in-context structural information. All we get is basically a list of issues like this one: http://drupal.org/project/issues/search/drupal?issue_tags=D8MI

Recap of predecessors

Different people got to different approaches to these problems. Here are some previous solutions that Jacine and I looked at and tried and the reasons I think they did not work the way I wanted them to work for me and people working with me.

1. Documentation pages. Jacine did a superb work in the HTML5 initiative collecting tasks into documentation pages with explanation on how can one contribute. One such page can be seen at http://drupal.org/node/1183606. This is great for getting some overview of the tasks at hand, but there is not a lot of metainformation on the issues and it needs manual editing to keep up to date. It cannot be dynamic in itself to show current tasks. Regardless, the documentation tree for the initiative (starting at http://drupal.org/community-initiatives/drupal-core/html5) works well for the people working on it as far as I've heard. I was just looking for a more dynamic solution.

2. Issue trees. I started to make up an issue tree for the Drupal 8 Multilingual Initiative back in August (in preparation of the London code sprint), so there would be an overview of the perts of the initiative. Turned out there are so many levels required that META-issues needed a META-META issue (http://drupal.org/node/1260534). Many people don't know what's a meta issue, let alone meta-meta. Also, again, the hierarchy (up-down) requires manual maintenance, and gradually got outdated as work focused on patches instead of maintaining the whole structure.

2a. Issue tree visualization. To make the issue tree more friendly for people I talked to some of my great Hungarian Drupaler pals who went on and created the Issue tree module to visualize the tree represented by the data from above. See http://drupal.org/project/issue_tree. Unfortunately this did not get much support for deployment on drupal.org and the topic pages efforts are in full force to propose something much bigger and better (http://groups.drupal.org/node/144584) so this has fallen through the cracks.

3. Mindmap. So given the issue tree did not have a chance for deployment and I wanted to provide an overview of the initiative, the initiative mindmap was born (and posted on the META-META issue at http://drupal.org/node/1260534). This was also plagued by the data disconnect. When tasks changed the map needed to be updated. Current tasks were only marked here, not on the issues themselves, so I need to manually keep a list of current issues updated elsewhere. This was/is a more up to date version of the structure compared to the issue tree, but is/was still lot of work to update and lacking features like pulling out current tasks or helping people find tasks that need testing or are easier to do.

Enter the Rocketship!

So in frustration of not having a good overview on all tasks even myself and not being able to sleep due to that frustration, the ambitiously labeled "codename rocketship" was born. Experience for yourself at http://hojtsy.hu/d8mi.

Basically rocketship comes from the idea that we need structure and higher level organization for huge sets of issues while at the same time be able to have an overview of both metadata on the issues and current state. It is a combination of all things I liked about the HTML5 book solution with a lot more automation based on metadata exclusively pulled from drupal.org. The initiative hub consist of a hierarchic book at its core, where each book page can have a taxonomy term name specified. If a term is specified, the issue nodes tagged with that term are pulled and sorted into 6 groups based on their status. For the first version I lumped "active" and "needs work" for example under a "To do" label, and did some more complex mangling to sort backport issues into a group as well (i.e. issues that were worked on for Drupal 8 before but are being worked on for Drupal 7 or 6 now).

Pulling issues based on taxonomy terms lets us create a page for example, that does the same sorted overview for current focus issues (D8MI and sprint tag at once, again an idea lifted from Jacine): http://hojtsy.hu/d8mi/current-top-priority-tasks

Then based on "lower level" tags we can dive into only the issues that deal with converting to "langcode" from "language" in schemas and APIs at http://hojtsy.hu/d8mi/migrate-schemas-and-apis-langcode for example.

We can also tag things for different areas, so they show up in different areas of the structure tree in their respective place.

Then when looking at let's say the base language issues (http://hojtsy.hu/d8mi/base-language-features), you can see I color coded the critical and major issues as well as the current focus issues. I also took liberty to mark the "Needs tests" tag with a distinctive color, so people looking to be able to help with that can spot those easily. I can imagine a couple other key tags can get colors, but we should got go absolutely overboard in that. An issue board with rainbow effects is not really useful.

Technology background

The feature works with a local cache of all issues tagged with D8MI with all the information scraped from Drupal.org (given no API available) and stored in local nodes. While that is not a great long term solution, I'm focused on improving Drupal 8's multilingual capabilities, so I tried to get to good results fast. The local cache of issues is updated every hour, so drupal.org should not be hammered at all. Similar issue status overviews are likely possible on drupal.org, I'd love to work on that given resources, however that is probably not going to happen with me personally for another 1.5 years or so given my focus on Drupal 8.

Drupal 8 Initiatives

We had our first Austin Apps sprint last week and got quite a bit done. We had 12 people from Phase2 Technology, LevelTen, Four Kitchens, Mediacurrent and Pantheon all had people at the sprint. Thanks to Four Kitchens for helping us provide a space for the Sprint.

This is part 2 of Uberdrupal: from distribution to profile. Images and more references are on the way.

In Part I of this post, I wrote about the context that led me investigate ways to speedup the installation of various Drupal setups.

Just as you might grab a napkin to sketch out an idea in your favorite joint or reach out for a pad of paper to test a concept with fellow developers at work, one often needs a fresh Drupal code-base (a Drupal napkin) to test and validate ideas. Practice makes perfect. If only installing a fresh Drupal code-base was as easy as grabbing a paper napkin under the glassy gaze of a disillusioned waitress... Actually, piece of cake! As we will soon see. Sort of.

There are many reasons why you would want to grab a Drupal code-base and start playing with it within seconds. I already mentioned testing concepts or bringing ideas to life. But there's much more: checking out the latest version of a module in an isolated environment, tracking down pesky bugs, comparing the many ways to implement a photo gallery or an animated banner, validating assumptions, etc.

In my case, I was looking for a way to quickly setup a Drupal 6 Ubercart store with some pre-built generic content. As far as I know, there's only one distribution that fits this bill and it's UberDrupal. In fact, UberDrupal does exactly what I want: it creates a Home and About us page and a $10 Example product. That's great! Now then, can I use the distribution's inner workings to create the pages, menus and products I need for my own use case? Yes you can!

The first issue is that UberDrupal's magic is frozen into the distribution (hard-coded if you prefer). The second issue is that with a release date going back to 2010-Oct-19, UberDrupal is, let's face ot, getting old. It was shrink-wrapped in October 2010 with the latest versions of Drupal core & Ubercart available at that time i.e. Drupal 6.19 and Ubercart 2.4. That's not bad per se. In fact, UberDrupal 6.x-1.0-alpha8 will install without a hitch. But wouldn't it be nice if you could upgrade to today's latest versions of Drupal (6.22) and Ubercart (2.7)? Wouldn't it be great if you could add a few of your favorite modules and libraries to the list? And while we're at it, let's be greedy, wouldn't it be awesome if you could have it create the basic products, menus and pages (nodes) that you will otherwise have to generate every time you create a fresh install?

Well, thanks to Ryan Szrama (rszrama), UberDrupal does all that. All we need to do is (1) crack open the distribution, (2) extract the installation profile, (3) change it so it will do exactly what we want it to do. Sounds like we have a plan.

Requirements - Note: each one of those is worth a separate article. Look for more info in the Related posts & documentation block.

• a tested & working local development environment (e.g. MAMP, LAMP, WAMP, etc.)
• appropriate entries in etc/hosts and httpd.conf.
• a fresh MySQL database (you can use phpMyAdmin for that)
• Drush
• Drush Make

OK, here we go!

• Download a copy of Uberdrupal.
• Once unpacked, what you will see is a standard Drupal 6 directory structure. All the magic is hidden in the profiles/uberdrupal directory. Makes sense.
• The mere presence of the modules and themes directories inside profiles/uberdrupal (along with Drupal core, on the outside) tells you that this package is a distribution.
• Because we're creating an installation profile (and not a distribution), we can safely delete the modules and themes directories (as well as Drupal core) keeping only the uberdrupal directory because the profile will download fresh copies (obviously, you will need a live Internet connection for this to work).

Now in order to transform the UberDrupal distribution into a self-contained installation profile, we need to make some changes. As mentioned in Part I of this post, a basic installation profile is made up of 3 files. In the present case, these files are: uberdrupal.info, uberdrupal.make and uberdrupal.profile. As you've probably noticed, uberdrupal.info doesn't exist. So let's create it.

• Create an empty text-only file and save it as uberdrupal.info
• Add the following lines to the file, save it and close it. We're done with this one.

; Use semi-colons to add comments.
; Installation profiles are great!

name = UberDrupal
description = Installs and creates a basic Ubercart store.
core = 6.x
theme = acquia_proper

Next on our list is drupal-org.make. In this file, you can get a sense of what the original UberDrupal distribution was made of (Drupal core 6.19, etc.). The first thing we need to do is to rename this file to uberdrupal.make. Then replace its contents with what follows.

; This is the installation profile's makefile (the inner one).
core = 6.x
api = 2

; CONTRIB MODULES

;projects[name_of_project] = version_number
;projects[name_of_project][subdir] = name_of_subdir

projects[cck] = 2.9
projects[cck][subdir] = contrib

projects[imagefield] = 3.10
projects[imagefield][subdir] = contrib

projects[filefield] = 3.10
projects[filefield][subdir] = contrib

projects[imageapi] = 1.10
projects[imageapi][subdir] = contrib

projects[imagecache] = 2.0-beta12
projects[imagecache][subdir] = contrib

projects[lightbox2] = 1.11
projects[lightbox2][subdir] = contrib

projects[skinr] = 1.6
projects[skinr][subdir] = contrib

projects[token] = 1.18
projects[token][subdir] = contrib

projects[ubercart] = 2.7
projects[ubercart][subdir] = contrib

; THEMES

projects[fusion] = 1.12
projects[acquia_prosper] = 1.1

; PROFILER - 2.0-beta2
; The following are required by Profiler when you create an installation profile.
libraries[profiler][download][type] = "get"
libraries[profiler][download][url] = "http://ftp.drupal.org/files/projects/profiler-6.x-2.0-beta2.tar.gz"

Why this content you ask? And why is it formated that way? I won't answer these questions here. But if you must know, watch Dmitri's Drupalcon Chicago presentation. Not only is it informative, it's quite entertaining. He's awesome. If you're in a bit of a hurry, checkout Drush Make and Profiler - a brief overview.

Next on our list is uberdrupal.profile. Remember, this is the file that holds the installation script. We need to make one change here. Copy the following code and simply paste it at the top of the file, just below the <? php tag.

!function_exists('profiler_v2') ? require_once('libraries/profiler/profiler.inc') : FALSE;
profiler_v2('uberdrupal');

Why? Because Drush Make requires this library to generate php code from the makefile (uberdrupal.make). See Related posts for more background information. If you want to customize the script, go right ahead. It's pretty self-explanatory. For now, I'm going to leave it as is.

There is a fourth file in the uberdrupal directory named ubercart_image.pkg.inc. We don't need to change anything for this one. Just leave it as is.

We have a working installation profile. Now what? The simple answer is: we need a trigger. And then, we need to pull on that trigger. Before we move on, make a tar.gz archive of the uberdrupal directory with the 4 files in it. We will need it later.

The trigger itself is just another makefile. It is the overarching or parent makefile that we will use to call the uberdrupal installation profile.

Create a new text-only file, paste in the following lines and save it as uberdrupal_inst_profile.make. The name could be anything you fancy as long as it ends with .make.

; This is the overarching or parent makefile for the Uberdrupal installation profile.
; It will install Drupal as well as all the projects listed below.

core = 6.x
api = 2

; REMINDER: when creating an installation profile, this is the proper place to download Drupal core.
projects[] = drupal
 
; Calling the profile.
projects[uberdrupal][type] = profile
projects[uberdrupal][download][type] = get
projects[uberdrupal][download][url] = "http://path-to-dir/uberdrupal.tar.gz"

; The following modules will be downloaded into sites/all/modules
projects[admin_menu][version] = 1.8
projects[module_filter][version] = 1.6
projects[devel][version] = 1.26

Two quick comments here. First, I like to keep my installation profiles where I can access them from anywhere and from any machine. But you can also keep/store them locally. Just set the URL accordingly.

Second, you'll notice that I'm downloading the admin_menu, module_filter and devel modules. Why here you ask? And the answer is: that's just the way I like to work. See Related posts if you're curious or just ask by posting a comment.

Only one thing left and that is to pull on the trigger. Any volunteers? Assuming your is drush-make ready (see requirements above):

• open up a terminal window
• go to the root of your development environment (in MAMP, that could be htdocs)
• run the following command

drush make --prepare-install uberdrupal_inst_profile.make uberd

This command tells Drush to install UberDrupal as per the installation profile's instructions into the uberd directory. Watch the magic and smile. From here on, just do as you would normally do for a regular Drupal install (i.e. go to your website's URL, choose the profile we've just created, and so on...).

If it doesn't work at first, don't be discouraged, just backtrack a few steps and try again, slowly. A little reading always helps. You'll eventually get it right and, like me, you'll soon be jumping up and down and stretching your t-shirt in all directions. And there's nothing silly about that... or is there?

Tags:

• Drupal 6
• distribution
• installation profile
• Ubercart

References: Uberdrupal: from distribution to profile - Part 1*** Installing Drush on Mac OS XDrush Make and Profiler - a brief overviewFrom Zero to Distribution using Features, Profiler, and Drush Makesites/all/modules vs profiles, the pros and consDrush Make Files for Production Drupal sitesEvery Drupal Site is an Install Profile

During our Drupal Introduction training we show the usage statistics of Drupal core. But since there is no longer a graph of the Drupal core statistics on drupal.org, we make our own. If you like statistics, like me, there is excitement in this graph since the release of Drupal 7. Using this graph I will try to predict the Drupal 7 growth in the next month and the coming years.

Final sessions are now live for DrupalCon Denver, taking place in Denver March 19-23, 2012. 100% of DrupalCon sessions are now announced. The final 20% were voted upon and selected this week. We hope you have your ticket for DrupalCon Denver already or you’ll be missing out on over 100 sessions across 8 tracks! This year we have added tracks specifically for Non-profit, Government & Education, in addition to Community, Commerce, Mobile, Design & User Experience, Business & Strategy, Coding & Development, Site Building, and Core Conversations.

Conference Dates:

March 19 - Pre-conference trainings -- over 16 from beginners to advanced + API Hack-a-thon

March 20 - 22 - Three complete days of 104 sessions starting with Keynotes: Dries Buytaert, Founder of Drupal and Drupal Project lead, Mitchell Baker, chairperson for the Mozilla Foundation, and Luke Wroblewski, digital product leader coming to talk about mobile.

March 22 - Drupal Means Business - included with conference registration to learn how to integrate Drupal into your business.

March 23 - All day Contribution Sprint -- one of the largest anywhere!

Plus, parties, ski trips, networking, contests and more! All for $350 conference fee! Thank you to our wonderful sponsors for helping this to remain one of the lowest cost open source conferences around.

Get your ticket to DrupalCon Denver today. What are you waiting for? We want to see you in Denver!

P.S. Conference registration is $350 until February 21 or when tickets are gone! Early registration helps us to plan the conference and keep our costs low by only ordering what is needed. A limited number of 1/2 priced student tickets are still available.

Follow @drupalcon on Twitter or find us on Facebook.

Start:  2011-02-01 17:00 - 18:00 UTC Online meeting (eg. IRC meeting) Organizers:  Gábor Hojtsy

If you don't find you way through the maze of the Drupal 8 Multilingual Initiative issues, wondering where to contribute, this is your place! If you are actively contributing and need some timely feedback, make sure to be there too. We'll review current issues and shorter term plans to focus on, but we'll probably also touch on longer term todo items (still confined to Drupal 8). The meeting is in the #drupal-i18n channel on IRC. See http://drupal.org/irc for more information.

(Note time above is marked with UTC - check in your own timezone).

Drupal 8 Initiatives

Dear Chapter Three,

I recently had a project where I was tasked with selecting the "Tabs" style for a particular panels region. I clicked the cog wheel for a particular region, but all I see is "Add content". What am I doing wrong? Is there a place to enable panels styles? Do I need another module?

Cheers!
Jayson

Great Questions Jayson! At first glance you'd expect that particular functionality to come with the Stylizer module (which comes with the Chaos Tools module). It seems however that panels styles comes directly from the panels module - there's no additional module to download or enable. If all that you see is "Add content", you'd better check your permissions to make sure that you have the privileges to "Administer Panels styles".

Like at previous DrupalCon's, I'm co-organizing a Core Conversations track at DrupalCon Denver.

The Core Conversations track is a place for people actively working on Drupal or Drupal.org to meet and plan the future of Drupal. Each session is either two 15 minute or one 30 minute presentation, followed by 30 minutes of discussion.

I know a lot of you contribute to Drupal or want to start contributing. If so, Core Conversations are a unique opportunity to present in front of key Drupal contributors, and to make the case for why we need to do more of A or B (e.g. authoring experience improvements, API overhauls, etc.). We need UX conversations, performance conversations, feature conversations, etc. Please share your ideas with the world through Drupal core.

If you have ideas for Drupal core, and you are attending DrupalCon, I suggest that you submit a proposal as soon as possible. The deadline is February 1st so don't wait too long. To get your ideas flowing, here are our conversations from Drupalcon London and Drupal Chicago.

It’s been a while since we looked at Apachesolr Drupal integration.  In large part that is because it “just works.”

It's solr, in a view, with exposed filters, facets, and it brews tea!

With the recent release of new code on Apachesolr Views (Big ups to dstuart, Ravi.J and ygerasimov for the recent contributions… everything seems to be aces) it’s time to revisit the subject.

If you have struggled with theming the search-result.tpl.php file and really don’t want to learn any more about getting great faceted search results you are totlally in luck!  Note to all: we’re using views 3.x-dev, apachesolr 3.x-dev, and apachesolr_views 3.x-dev.

For those of you who are video inclined here’s a ~4 minute screencast

For the rest of you Robert Douglass called it over two years ago in his “views 3 + apachesolr + acquia drupal = the future of search” post and for the most part that’s the deal – if you want to see more screen shots go there.

We’re also us

ing ApacheSolr Custom Fields and the Batch Indexing module (thanks anarchivist)  (as mentioned previously).  Note that at this time the custom field module requires this fix to run… but still a handy module.

Learn to not code with the help of nice mods!

Custom Fields is well worth the minor effort in that it is another piece of the no-coding puzzle.  We also enjoyed having views php (a bit of coding is ok – we used it to set up displays per content type in the view)

Also using better exposed filters again to make the UI for the exposed filter better… gotta love naming conventions!

In any case the working view took about 10-15 minutes to produce, with ~5 minutes spent making tea.

 

Do you know someone who would be a great community representative on the Drupal Association board? Are you that someone yourself, but you've hesitated to put yourself forward? Now's the time!

Nominations so far for the at large positions have been, shall we say, a bit slow coming in. So we're extending the nominating period. Nominations are now open until Jan. 29th, 2012.

For background, please read the elections announcement and the nominations page.

read more

I've been experimenting with installation profiles for some time now. It all started with a Drupalcon Chicago presentation by Dmitri Gaskin (dmitrig01): From Zero to Distribution using Features, Profiler, and Drush Make. A year ago, on a bad day, setting up a fresh Drupal installation in order to test a module or try some new tricks in Views could take me as much as two hours. The possibility of installing Drupal with a custom list of contrib modules in less than a minute seemed like science-fiction at the time.

Setting up a Drupal website on a shared server or locally with MAMP, LAMP or WAMP requires a fair bit of 'prior' technical knowledge that experienced Drupal users take for granted. The lack of which inevitably stumps a newcomer into an uncontrolled rage of frustrations. I know. I've been there.

The first time I installed Drupal, I think it must of taken me a month or so. Plain ignorance, as in 'not knowing much in general', was one reason it took me so long. Ego also played its part: I thought I would skip a few 'classes' and tackle a multisite installation right off the bat. In the end, after a stubborn and somewhat senseless battle, I eventually succeeded. When I finally read 'Welcome to {Your Site Name}', I stood up in front of my computer, jumping up & down with my two arms raised above my head and then pulling on my t-shirt like I just scored the gold-medal-winning goal at the 2014 Mundial. Silly me.

Nowadays, every Drupal project I work on starts with a distribution profile. It helps me to quickly map out my goals and visualize the best way to get there.

As a side note, I've been thinking about sharing what I've learned in a mini-series of tutorials or screencasts. Maybe this post will ring the bell for round 1.

So in case I'm not making myself clear, this post is about how I modified an existing distribution into an installation profile and what I gained in doing so. The distribution I used is UberDrupal and you can download it here: http://drupal.org/project/uberdrupal.

On the UberDrupal project page, one can read the following. 'UberDrupal is an installation profile designed to help you get a Drupal site running Ubercart up as quickly as possible.' In fact, the UberDrupal distribution contains in a single download: Drupal core, Ubercart's core set of modules and an installation script that guides you through the setup of a very basic online store in one go. If all goes well, your new 'empty' site will be up before your eyes within 5 minutes. Not bad when you consider that doing it piecemeal will easily cost you a couple of hours - assuming you know what you're doing.

I should clarify one thing before I continue and that is the difference between a distribution and an installation profile.

A distribution is a package that includes all modules & files required for installing a fresh Drupal website. It includes an installation profile. A distribution cannot exist without an installation profile. When you download and install Drupal 7, you're actually downloading a distribution which offers you the choice between 3 different installation profiles: minimal, standard or testing. The UberDrupal distribution weighs in at 3.34 MB.

You can think of an installation profile as the genetic signature of a particular Drupal install or codebase. It can perfectly exist withtout modules & files. When called or invoked with an appropriate command, an installation profile will fetch all modules & libraries that appears in its internal list and build a Drupal website on the fly. The UberDrupal installation profile weighs in at just 6,267 bytes.

The makings of an installation profile are very similar to that of a module. A basic profile is made up of 3 files: a '.info' file which minimally names and describes the profile; a '.make' file which lists the required modules & libraries; and a '.profile' file that contains the script (if any) for setting up and configuring the Drupal website.

In Part II of this post, I'll drop the theory and show how easy it is to transform the UberDrupal distro into a profile, update it and customize it the way you want it.

Uberdrupal: from distribution to profile - Part II

Tags:

• Drupal 6
• distribution
• installation profile
• Ubercart

References: Uberdrupal: from distribution to profile - Part 2

Back in September, I wrote a blog post about making Mega Menus in Drupal. After publishing the post I found numerous issues with the proposed method and ended up using another method on the project that precipitated the article. After recently receiving a few comments on the original post I realized that it was time for a followup.

read more

Pantheon believes it is Drupal's destiny to run a double digital percentage of the internet and that high quality Drupal products will drive much of that adoption. Although Drupal has evolved to provide a strong technical framework for custom website development, its usefulness out of the box leaves a lot to be desired for most users. Luckily, over the last few years we have made great strides forward in extending Drupal to provide pre-packaged distributions for common use-cases and now have an increasing number of mature options available. 

As of this week, Pantheon is rolling out support for Drupal products as one click installs on our platform. Just select one of the Drupal products as part of the site creation process and experience a hassle free install complete with all required external dependencies and modules, all while maintaining the proper upstreams to take advantage of future updates and releases. 

For our inaugural offering, we are partnering with Drupal product leader Phase2 Technology to offer OpenPublish, OpenPublic, and Open Atrium on Pantheon and baking in support for the emerging Open App Standard.  Along with many others we believe that much of Drupal's future - some might say destiny - will be fueled by Drupal products hosted in the cloud and we are glad to be a part of that. 

We are just getting started here and are looking forward to working with the rest of the Drupal community to help develop better standards, frameworks, platforms, and business models for making Drupal products work for everyone. Let us know if you want to partner to make your Drupal product available on Pantheon or signup for an invitation code to test drive a Drupal product. 

Having spent an amazing few days in Austin for the Apps Sprint we came away with some even better news than expected. After a few joint development sessions with the great folks of [Pantheon] we are thrilled to announce that OpenPublic, OpenPublish and OpenAtrium are now available on the Pantheon platform via a one-click install from your Pantheon dashboard.

A glossary index is a helpful tool for our patrons to find the journals that they are looking for – building your first glossary can be a struggle so here’s a 2 minute video to walk you through the basics

Working in the arguments region in views

Once we had the block built we attached it to our view of titles using contexts.  Another way that would have been acceptable would have been Views Attach.  I wanted to use the attached views, however I wasn’t entirely certain about all possible use cases, so we just went with  a block and joined everything up using contexts.

A path, node type, and taxonomy based context

And yes, we could have added “views” conditions as well, although it is already pretty much overkilled…  in any case it’s another beautiful day with contexts & views

Installing Tomcat6 and Apache Solr

Installation procedure

While there are several ways to install Tomcat 6 and Apache Solr, we will use the repository version to gain the benefit of automatic updates.

What is needed:

1. Tomcat6 as Servlet container

   sudo apt-get install tomcat6
sudo apt-get install tomcat6-admin

2. Apache Solr Search Server

   sudo apt-get install solr-tomcat

Once everything has been correctly installed, you should see the message, “It works!” at http://localhost:8080 and “Welcome to Solr!” at http://localhost:8080/solr/

Configuring Tomcat 6

In the default Tomcat installation, no privileges are created for the Tomcat Manager, so in order to make use of the Tomcat Manager GUI, we still have to create the proper role and a corresponding user.

read more

Drupal executives clearly expressed their interest in learning about company best practices regarding software use at the 1st DrupalCXO meetup in Brussels in 2010. As an action point of the meetup, we launched a survey on ‘Software Used in Drupal Development’ and prepared a preliminary report that contains the summarized version of the aggregate data obtained last year.

The results primarily come from European and North American companies that were founded less than 10 years ago, have no more than 20 employees, and are partially or not virtual. Although 78% of the surveyed companies use agile software development, there are other popular methodologies, too (waterfall, incremental, prototyping and other approaches). The survey participants were asked about the tools they used, for example, for bug tracking, knowledge management, SLA, CRM, project management, resource planning, version control, code review and real time communication. The report sums up the responding Drupal companies’ live experiences with the various software types as well as ideas on how these tools' efficiency could be improved. The results not only show the most favored software types but also describe the tool characteristics that make Drupalers like or dislike them.

To collect more data, make a comparison and foster collaboration, we decided to re-launch the survey in the framework of the #drupalprocess meetup (Amsterdam, 27-29 January, 2012). Please tell your friends to share their experiences on the various tools, too. We will publicly share some highlights from the survey, but the more detailed full report will only be available for contributors.

Below you can find some extracts from last year results. If you want to get the full report from last year and this year, please fill in the SURVEY.

Extracts from the preliminary report on 'Software Used in Drupal Development':

[...]
1. Bug tracking

1. a) Do you use a software for bug tracking?

The most favored tools (max. 3 votes):

* Redmine (3)
Like:

• Redmine: features. (Project*: Drupal integration)
• It's simple and easy for all to understand.
• Fast, versatile, good overview.

Dislike/missing:

• Redmine: Drupal integration (Project*: redmine-level features)
• It’s too simple and do not fit our model for monitoring project progress
• Fine grained access control to certain fields.
  Automatic closing of issues after a period of time.
  Better control of sending notification emails.

* Unfuddle (3)
Like:

• Ease of use
• Integration with subversion for commits. [eg. for closing tickets].
• Hosted service was easy.
• Online tool

Dislike/missing:

• Not open source!
• No agile processes.
  UI for subtasks is missing.
  Getting expensive for larger projects.
• Integration with our development process (Scrum).
  Too difficult for our less technologically avid customers.

* Trac (3)
Like:

• fully integrated GTD methodology.

Dislike/missing:

• Drupal-like input formats.
• Mobile client.

* Mantis (3)
Like:

• Mail alerts, workflow.
• Simple, fast, clean looks.
• It works.

Dislike/missing:

• Efficient time tracking?
• Connection with other tools we use.
  Little support for agile/scrum approaches like product backlogs/sprint backlogs.
• Usability

* Open Atrium (2)
Like:

• extensible and familiar --- it's based on drupal

Dislike/missing:

• due dates, statistical analysis, time tracking/logging, custom bug categories per project

* Jira (2)
Like:

• very flexible, does what it is supposed to do
• I can't say there's any feature I really like about it; it does some things OK

Dislike/missing:

• nothing

Complete list:

• Word/Writer/Text Editor
• Spreadsheet
• assembla
• trac
• Jira
• Mantis
• Pivotal Tracker + drupal.org
• Drupal
• homebrew system
• fogbugz
• Redmine, Drupal Project modules
• tracks (getontracks.org)
• Unfuddle
• Basecamp
• Open Atrium
• Rational ClearQuest
• Open Atrium (modified)

1. b) What is your satisfaction level?

1. c) What do you like most about this software regarding the above mentioned task?

• Freeform
• Works fantastic on Google Docs with a small number of users (up to 5)
• Agile in approach and has lots of integration points with other systems such as git, svn, trac, etc.
• very flexible, does what it is supposed to do
• I can't say there's any feature I really like about it; it does some things OK
• Mail alerts, workflow
• Pivotal Tracker is integrated with feature management plus has very simple and powerful interface.
• customizability
• We can tweak it to our needs
• Fast, good email support, free
• Redmine: features.
• fully integrated GTD methodology.
• Ease of use
• Integration with subversion for commits. [eg. for closing tickets] Hosted service was easy.
• Its simple and easy for all to understand
• fast, versatile, good overview.
• Simple, fast, clean looks
• Great time tracking, great user interface.
• extensible and familiar --- it's based on drupal
• Online tool
• It Works

1. d) What is missing from this software to fit better the above mentioned purpose?

• Better interface. Integration with git.
• Integrations to source code with tracking of code sets committed to closet ticket. Trac integrates to SVN nicely for this for instance.
• It could have better segmentation for clients to review project
• nothing
• Drupal-like input formats.
• Efficient time tracking?
• love and attention
• Redmine: Drupal integration (Project*: redmine-level features)
• Mobile client.
• Not open source!
• No agile processes. UI for subtasks is missing. Getting expensive for larger projects.
• It’s too simple and do not fit our model for monitoring project progress
• fine grained access control to certain fields. automatic closing of issues after a period of time. better control of sending notification emails.
• Connection with other tools we use. Little support for agile/scrum approaches like product backlogs/sprint backlogs
• Too simplistic, no bug severity options.
• due dates, statistical analysis, time tracking/logging, custom bug categories per project
• Integration with our development process (Scrum). Too difficult for our less technologically avid customers
• Usability

[...]