New -dev release available (2011 April 18)
There's a new Commons release available; it's what's known in the Drupal world as a "-dev" release. In our case, it means that it's got a lot of new stuff in it that's pretty well locked down, but:
- There's still new capabilities intended prior to making it an -alpha or -beta candidate;
- Developers reserve the right to "break" things that are implemented in the -dev release as they add these new capabilities, with no upgrade path planned from -dev release to -dev release; and
- While it is tested by the developers, this release hasn't had real deployment-grade testing yet.
However, there's lots of new stuff in this release. You can download the release now, and read the details in the Release Notes; but the main themes of this release are:
- Simplified user experience. We've had plenty of feedback about the amount of content contained in the group home page layout. While the page designs were inspired by other social business software solutions, many found the group home pages to simply have too much information, and what was there wasn't as useful as they'd have liked. So this release reconstructs the group home pages; there are now only 2 columns, and the main column contains (primarily) the contents of the old Recent Activity block. This block uses the Heartbeat module, and we think in the coming days we can coax a bit more out of the Heartbeat module to make the information in this block increasingly useful. We've taken the old "Recent Content" block and broken it into per-content-type blocks in the sidebar. I'm not sure we're accomplishing all that's possible yet; but this new layout will reduce the complexity of the group home page, and will allow us to fine-tune the contents in coming releases.
Note that we've also rearranged the user's profile pages, following similar coments about what people wanted from the profile pages. I think the changes we include here are also only the first step to improving the usefulness of the profile pages. It's arguable that within a release or two, the profile page will have the bulk of the functionality that the Dashboard pages, and the latter should disapper. But we're not quite ready to make those go away, I think. We have a little more work to do to differentiate - or combine - the two.
- New theme. Many people inexperienced in Drupal thought that the old Acquia Commons theme was the only way that Commons could look. Those with experience knew you could have different Themes for Commons, but few were fully capable of handling the full feature set of Commons.
So we've included a new theme - Commons Connect - in this release. You'll find it has a pretty different look & feel from the first Commons theme (which still remains in the distribution). The point of this new theme is not only to give you a second choice, but demonstrate how a new theme can completely change the feel of a Commons site - yet still retain all the functionality of the underlying solution.
- Increased customizability. A foundation goal of Commons is to continue to make Commons as modular and customizable as possible, yet still retaining the important core components of a community site. This release increases the customizability aspect in an important way by including og_features. This new module enables group administrators to enable / disable (Commons) Features differently per-group. For instance, if a group does not need Blog pages, those can be turned off for that group, which removes the tab along the top of the group home page, and removes the link to create new Blog content.
Another element of customizability change is notable. Previous versions of Drupal Commons used both Panels and Context. There initially seemed to be good reasons to use both. But many people were confused about which to use when. So in this release, we've pulled out Panels and are using Context completely for page layout. If you don't know it, take the time to learn it; it's pretty powerful.
- Admin module (vs. admin toolbar). Because we switched to Context, we also needed to provide a way for people to manage page layouts using Commons - e.g. what the stacking order for sideblocks is supposed to be, etc. To do this, we really needed to include the Admin module. And since its functionality is a 100% overlap with Admin Toolbar, and since we needed Admin (module) for Context layout control, we decided to swap the two. If you haven't encountered the Admin module before, (while you're logged in as an Admin) when viewing any page, click the wrench icon on the top-right corner of the page and click on "Context editor". From there, you can edit the blocks and their layout for every page.
We're not quite done yet. There are still a handful of new things we want to add to this release. But there are good reasons to put out a -dev release before an -alpha or -beta:
- The UX changes are widespread enough that site builders that have created Commons sites already may need some time to sort out how these changes should be folded into their existing sites;
- Because of the widespread changes, we should start tracking bugs earlier than an -alpha or -beta release.
If you're interested in providing testing feedback (read "bug reports"), go download the -dev release, then request to be granted access to the Google spreadsheet the community participants are using to develop this release. The first tab in this spreadsheet gives you notes on how to test this release. NOTE: In addition to simply requesting access, please add a comment here ON THIS PAGE indicating:
- Your drupal.org user ID;
- Your experience level with Commons;
- What you expect to be able to do - e.g. point-click to test, and report bugs; or actually submit theme or code patches to fix bugs you might find.
We definitely want as many testers as possible, but we'd prefer to have those who have some Commons (or at least Drupal) experience in order to reduce the number of reported issues that are merely reporting how Drupal works (by default). Thanks in advance to all who provide input and feedback for this release.


Comments
Problem with the .tar.gz?
I'm seeing something weird in the downloaded archive: When I expand, every file and folder that's supposed to be there is duplicated with another 240-byte version of itself, pre-pended with a period and underscore. So I see "CHANGELOG.txt" but also "._CHANGELOG.txt" -- is this just the (horrible) archiving utility I'm using on Windows, or is anyone else seeing this?
This should now be fixed
Sorry. Try it again - do you still see this cruft?
Yes I do. :-(
Yes I do. :-(
Wow
I just make a quick install in my local machine, everything is ok, like the new feature to disable, enable "feature" by group, the theme is great.
I test it out and everything seems ok, i have already a commons website (http://biladi.us) and i am just launched one new today (http://biladi.ma), and i am planning to launch 2 others. Why its dev, hope i can update easily from last version. Wonder why its dev! what the risk to launch a website with dev?
Thanks a lot for your good work
I can help testing and reporting bug etc
Sincerly
Toma
Great!
It's great to see you have some experience with development of Features, etc. I think we can use your help in some code, eh? ! :-) Thanks for your initial testing.
The reason not to launch a website with a -dev release is for the reasons I explained to Gerald below: We are not finished with the functions we would like to put into Commons. And as we add more, we may change view definitions, content type definitions, etc., and we don't want to have to make the trouble of writing upgrade code for all these changes. We want to be free to make any needed changes during -dev, and then we will write code to upgrade from 1.5 > -beta when we are ready with a -beta release.
Does this make sense?
Also, thanks for the French translation stuff. We're getting ready to launch translate.commons.acquia.com, which will facilitate the translation of strings into other language packs. Watch the announcements here on this site; we'll let everybody know when we have that done. (By the way - the thing that is making this go slow is that we would prefer to have unified single-account signon between that site and this site. We were expecting to use one popular Drupal technique for this; but our operations team just finished doing this on some other big Acquia activities, and are now hesitant to use this technique without a LOT of thinking before deployment. We're working on this now.)
Error 503 Service Unavailable
I've been getting errors trying to download the file since last night.
Sorry about the inability to download, but..
.. the download site is hosted at Amazon Web Sevices, which experienced a fairly significant failure this week. . You can read more here, and many other places (use Google.)
Service has been restored.
Page does not exist
This is what I get after I tried as @Tempster and got also
Error 503 Service Unavailable some hours ago
service unavailable
yep, me too...I ended up downloading it from github.
Migration path?
Hi!
Thx good new feature approach.
Is there any documented migration path from older version.
It is difficult to overview all neccecary changes for views and other changes.
Question: Why do you quit the use of panels?
Wr
Gerald
dev Release vs. products from vendors
A few days ago Dries ask about the differences between Drupal/Commons and products/solutions from other vendors like Open Text oder EMC.
ONE difference is important: None of this vendors change the tech roadmap and implementation approach so quickly like this was done with Commons so far.
It is very difficult to follow the steps and decisions and to choose the right decisions and plans for individualy projects. It' hard to plan short- and midterm.
Please support us with more:
- documentation about future plans and implementation decisions
- describe the changes to current versions in detail
- give recommendations about the individualy neccessary changes and customization approaches
- develop patterns for Commons
- dev always migration features
This is only a simply idea about what to do that Commons can be equal to a pro product from a vendor.
Wr
Gerald
PS: Our consultancy company knows the ECM and WCM market since 1992 in detail. But we are newbies with Drupal and Commons.
-
Gerald -
Thanks for your feedback. We'll see if we can address more along the way.
Many of your suggestions - recommendations about customization approaches, etc. - are good ones. I'm not sure we have the answers to them; "distributions" as complex as Commons is are fairly new to the Drupal community. Frankly, we're really pushing boundaries here that are new for Drupal & Drupal distributions. So in some ways, we as a community - not just Acquia - need to discover the answers to these questions together, and use this site as a community site to document all we learn.
For example, we (this week) discovered that there will be a better way to implement Themes for Commons. In the next -dev release, we'll be splitting the "old" Commons theme into two parts: One that contains as much of the "code" as possible - which whould become the basis of new themes for Commons - and the other containing the "Chrome." The new theme will also then use this underlying code and simply re-chrome Commons. This is a good - but new-this-week - practice about how best to customize Commons' Themes. And so we're really inventing all this in real-time. (And note that the code for this split theme will just be finished Friday (today) and we may not have documentation for it before the code itsels if available; but maybe it's better to make this tool available to themers ASAP and then write docs for it as soon as we can, yes?)
Also note that, as I said above, the current release is a -dev release. In Drupal-speak, this means that the release is akin to being mid-development on a website, or on a software solution. There's finished components, but there are also things planned for the final release that are NOT included, and much of the "supporting stuff" isn't even started (e.g. documentation, upgrade/migration code, etc.). Please note that the Release Notes for this version indicate these things, and strongly suggest that you do NOT begin a new Commons site with the -dev version. Upcoming -dev releases may change schemas, views, content type definitions, or other things and NOT provide any kind of upgrade / change path for these - because that's what -dev versions reserve the right to do.
Thanks for your good comments, though. We'll work on filling all this in as Commons matures.
Answers
a) We'll have documentation in general (including migration documentation) when we have a -beta candidate. This is not a -beta; it's a -dev, which means it's still in development, so there's no sense in writing docs until we stabilize the release.
b) We stopped using Panels because we got a few more features we wanted from Context, and having both Context & Panels as confusing to implementers, so we needed to select one or the other. Context seemed to provide more solutions like what we needed for now.
thx for your answers. More questions :-)
Hi Jay!
Thx for your quick response.
ad a.) Ok. Accepted.
Further questions:
- What are the plans for this "dev release"? New features? New modules? Removed modules? Changed views,...?
It would be very helpful to know this! Or is this a dynamic dev process? Every day a new idea? (Sorry, but we are in production ;-)
ad b.) Ok. Accepted.
Is there any documentation out there to compare Panels and Context? There are a lot of features of Panels we don't know to solve this with Context.
wr
Gerald
PS: We try to dev a commons clone based an D7 (with the help of Drupal developers). Currently it is not possible to dev the same feature set. We will write an article about our activities in the next days.
Any screenshots available?
Hi Jay,
could you publish some screenshots of this new "Commons Connect" theme?
Great work!
We have a few screenshots in a blog post
http://brightlemon.com/blog/new-dev-version-drupal-commons-released
Delivery Date for the Dev Release
Hi,
Love the new theme and Context.
Any thoughts on when this release will go live?
Thanks,
Erik
Some usability issues
Hia, tried out the dev to see if we could use it as a basis for a community project we are developing. It's looking promising, and I really like the switch to Context only, og_features and the new theme.
However, when trying to implement a custom theme I found some usability roadblocks that I don't really know how to deal with:
1. The title of a group is just the $title variable, so you can't place it freely. For this project I would like a header where we had "community name: group title" at the top of each group. This works at some pages (feature front pages), but if you're at a node view you would get "community name: node title" instead, losing the group name in the title. I imagine I could solve this quite easily in a theme preprocess function so it's not that a big deal, but still would prefer a unique variable with the group title to use in my templates.
2. The more serious roadblock for me is that the feature menu is printed in $tabs, not in it's own menu. This has two effects: a) you mix navigation for the node (view / edit) with navigation of the group tools, and b) tabs cannot be set as an active item for anything that falls beneath it.
For example, I click the "events" tab, then I click an event that is listed. What happens now is that the events tab dissapears completely from my page, and you lose your sense of place. Imagine you come to an event listing or blog post via a a search result: you would never see that you are in the "blog section" of a group, because the tabs are gone, and the only way you would find the name of the group would be from the breadcrumbs or the $links at the bottom.
If we used a menu for this we could use modules like Menu Trails or Context to solve it, but this is not possible with tabs. I tried to change the group_tab_* views where the tabs are set, to place the links in a menu instead, but this is not allowed when you have variables in the path (%), so it seems that this is baked to deeply in to the architecture that we easily can solve it?